Argumente für Objekt orientierte Programmierung

[Peter Mössinger]

Hallo,

ich habe einen Kollegen, der einer der qualifiziertesten Mitarbeiter bei uns ist. Er ist aber ein Verfechter der prozeduralen Programmierung mit z.B. Perl oder der funktionalen Programmierung mit z.B. Lisp.

Welches sind die stichhaltigsten Argumente um die Vorteile von OOP in der Diskussion mit solch einem Kollegen herauszustellen?
Ich höre von ihm immer: Dafür brauche ich keine Objekte, das kann ich in Perl auch auslagern.

Gibt es sowas irgendwo im Internet?

[Der_Unwissende]

Hi,
ich muss ehrlich sagen, dass es keine großartigen Argumente gibt, die für (oder eben gegen OOP) sprechen. Ob du etwas mittels OOP löst oder funktional, prozedural, logisch, sonst wie hängt sehr sehr stark von der eigentlichen Problematik ab.
Zudem sind die einzelnen Herangehensweisen nicht völlig disjunkt zueinander.

Wenn er einer der herausragenden Kollegen ist, dann hat dass sicherlich seinen Grund.

Die Vorteile der OOP liegen in den Regeln der OOP, aber dabei kommt es dann auch wirklich auf die Einhaltung an. Es heißt auch nicht, dass es nicht anders geht, der Aufwand ist nur unterschiedlich groß.
Wenn du bei Wikipedia (oder den google Treffern) nach OOP schaust, sollte eigentlich ganz gut erklärt werden wo die Vorteile von Kapselungen, Vererbungen und vorallem Abstraktion liegen.
Das imho Schönste ist, dass du halt sehr gut "komponentenartig" mit Objekten arbeiten kannst. Ist nur ihre Schnittstelle bekannt, so kannst du das konkrete Objekt leicht gegen ein anderes (z.B. effizienteres oder robusteres) austauschen ohne etwas am restlichen Code verändern zu müssen. Somit verdankst du der Abstraktion von einem konkreten Objekt die Wiederverwendbarkeit.

Wichtig ist halt, dass nicht jeder Code der OOP ist auch gleich alle Vorteile bietet (oder im gleichen Maße). Wichtig ist es halt immer, dass der jenige der den Code erzeugt überhaupt weiß was er tut.

Gruß Der Unwissende

[Luckie]

Zitat von Der_Unwissende:

ich muss ehrlich sagen, dass es keine großartigen Argumente gibt, die für (oder eben gegen OOP) sprechen.

Na dann viel Spass bei größeren Projekten ohne OOP.

Argumente sind:
Wiederverwendbarkeit
Ich haeb hier eine Log-Klasse von einem Kollegen, die er in einem anderen projekt schon mal benutzt hat. Einfach die Klasse eingebunden und benutzt, fertig.

höhere Übersichtlichkeit
Prozedurale Programmierung resultiert in Spaghetti Code und somit geht die Übersichtlichkeit schenll verloren.

einfachheres Refactoring
Muss etwas geändert werden, kann ich die entsprechende Methode ändern. Und so lange die Schnittstellen sich nicht ändern, muss ich an keiner anderen Stelle etwas ändern. Optimiert der Kollege seine Log-Klasse, kann ich einfach die neue Klasse einbinden und fertig. Ich muss nicht an zich Stellen im Code was ändern. Bzw. ich habe sie erweitert und er könnte sie jetzt einfach in alten Projekten einbinden ohne dass er etwas am Code in den alten Projekten ändern muss und er hat trotzdem die neue Funktionalität

verstecken von Funktionalität
Ich als Endanwneder der Klasse muss mich nicht darum kümmern, wie etwas gemacht wird. Ich stecke vorne was rein und bekomme hinten das gewünschte Ergebnis raus. Was die Klasse macht oder wie sie das Ergebnis produziert sehe ich nicht und muss mich auch nicht interessieren, so lange ich die Klasse nicht verbessere oder erweitere.

[Der_Unwissende]

Zitat von Luckie:

Zitat von Der_Unwissende:

ich muss ehrlich sagen, dass es keine großartigen Argumente gibt, die für (oder eben gegen OOP) sprechen.

Na dann viel Spass bei größeren Projekten ohne OOP.

Danke, hab ich. Möchte hier aber auch kurz sagen, dass ich OOP verwende und alles andere als ein Feind von ihr bin.
Aber wenn du dir Teile des amerikanischen Militärs nimmst (die Entwickeln auch mal größere Projekte), siehst du dass es ebend auch anders geht. Dort wurde wohl mal eine Raketensteuerung funktional programmiert (gut, die Rakete stürzte wegen einem Stackoverflow ab).

Wie gesagt, es gibt Dinge die man mit OOP besser machen kann. Wenn ich aber keine Schnittstellen definiere oder wenigstens abstrakte Klassen, dann ist einfach nichts mit austauschen und alles läuft.
Zudem gibt es mehr als Prozedural vs OOP, was ist mit der erwähnten funktionalen bzw. logischen Programmierung? Ich denke nicht dass es Konzepte gibt, die einfach nur der Vielfalt wegen existieren (ok, einige schon). Aber die die sich länger halten, werden sicherlich ihre Rechtfertigung haben (und dafür muss sie mir nicht bekannt sein)

[Peter Mössinger]

Zitat von Luckie:

Argumente sind:

Wiederverwendbarkeit
höhere Übersichtlichkeit
einfachheres Refactoring
verstecken von Funktionalität

Ich sehe dies genauso. Vor allem in größeren Projekten kann man dann Profit aus vorher geschaffenen Strukturen ziehen.
Wenn man nicht nur Daten von A nach B schieben muss sondern in einem größeren Projekt mit vielen Mitarbeitern zusammenarbeitet bemerkt man auch, dass die Komponenten-Strukur der Klassen die Zusammenarbeit erleichtert.

Ausserdem kann man sich in der Objektorientierung auf eine höhere logische Ebene begeben. Man macht nicht mehr etwas mit Daten, sondern man deligiert Aufgaben an Objekte, die Ihren eigenen Status kennen und die Aufgaben verrichten können.

Aber:
* Man muß mehr kommunizieren (Schnittstellen spezifizieren, modellieren, ..)
* Durch die benötigte Programm-Struktur wird die Programmierung komplexer (wer bräuchte sich sonst Gedanken über private, protected, override oder Vererbung zu machen)
* Die erforderliche Qualifikation der Mitarbeiter ist höher

[Jasocul]

Früher wurde alles ohne OOP programmiert und das funktionierte auch.
Es ist also nicht so, dass es Dinge gibt, die man ohne OOP nicht programmieren kann.
Das das Raketenprogramm mit einem Stackoverflow abgestürzt ist, kann auch mit OOP passieren.

Was ich persönlich bei OOP mag, ist die Vererbung.
Man hat ein schickes Basis-Objekt, dass alles wichtige mitbringt. Davon leite ich ab und muss mich nur noch um die Spezialfunktionen kümmern. Alles andere funktioniert ja schon.
Bemerke ich einen Fehler im Basis-Objekt, kann ich das korrigieren und die Kinder bekommen die Änderung gleich mit.
Sowas kann man auch prozedural lösen, ist aber meistens viel aufwändiger.

Die Argumente deines Kollegen sind typisch für Programmierer, die "schon immer so" programmiert haben und nichts Neues lernen wollen.

Auch ich habe eine Funktionen-Sammlung, bei denen sich ein Objekt nicht lohnt, aber ein großes Projekt ohne OOP kann ich mir heute nicht mehr vorstellen und möchte ich auch nicht mehr machen.

Solche Kollegen kann man nur überzeugen, wenn man denen zeigt, dass man Projekte schneller und besser entwickeln kann, als er, wenn man OOP einsetzt. Aber es gibt auch die ewig unbelehrbaren.

[PMM]

Der Ansatz für die OO-Technologien lag und liegt gar nicht so sehr bei der OO-Programmierung, als in der OO-Analyse bzw. im Design. Die Erfahrung ist die, dass die Funktionlität eines Projekts sich im Laufe der Zeit sehr grundsätzlich ändern kann. Es ist offensichtlich, dass damit das Fundament eines Systems kippen kann, wenn dieses an den Funktionen (->prozedural) aufgehängt ist. Ein an den "Main playern" (deusches Wort fällt mir gerade nicht ein), orientiertes Design ist dagegen oft robuster, da diese "Objekte" sich nicht so rasch ändern. So oder so ähnlich waren die Kerngedanken, die dann zur Abkehr von den prozeduralen und der Entwicklung von objekt orientierten Systemen geführt hat.
Es ist dann natürlich nur folgerichtig, wenn ein OO Design auch imt OO Programmierung umgesetzt wird.
Vieleicht helfen diese Gedanken ja weiter. Ansonsten gilt natürlich: Lesen bildet! (Ad hoc fällt mir G.Booch: "Object orientated design with applications" ein)
Gruß PMM

[Frickeldrecktuxer_TM]

Zitat von Luckie:

Na dann viel Spass bei größeren Projekten ohne OOP.

Existiert und geht bei entsprechender Dokumentation des Quellcodes auch. Die Menschheit hat lange Zeit ohne objektorientierte Sprachen gelebt und jetzt tun alle so, als sei es ohne Objektorientierung gar nicht möglich, ein Problem zu lösen...

Zitat von Luckie:

Wiederverwendbarkeit
Ich haeb hier eine Log-Klasse von einem Kollegen, die er in einem anderen projekt schon mal benutzt hat. Einfach die Klasse eingebunden und benutzt, fertig.

Das geht auch prozedural. Einfach die Funktionen aufrufen, fertig.

Zitat von Luckie:

höhere Übersichtlichkeit
Prozedurale Programmierung resultiert in Spaghetti Code und somit geht die Übersichtlichkeit schenll verloren.

Bedingt. Kommt auf den Entwickler an, der den Code fabriziert hat. Wenn ich mir das anschaue, woran ich gegenwärtig arbeite, muss ich dir leider Recht geben. Aber so, wie der Code aussieht, wäre er auch nicht sehr viel übersichtlicher, wenn er objektorientiert aufgebaut wäre, anstatt prozedural. Übersichtlichkeit hängt von exakt zwei Faktoren ab: dem Autor des Codes und dem Leser des Codes. Kein Faktor mehr, kein Faktor weniger.

Zitat von Luckie:

Optimiert der Kollege seine Log-Klasse, kann ich einfach die neue Klasse einbinden und fertig. Ich muss nicht an zich Stellen im Code was ändern.

Auch das geht prozedural. Wenn du wüsstest, was manche einer schon an prozeduralen APIs optimiert hat. Und die Programme lauen trotzdem noch

Zitat von Luckie:

Ich als Endanwneder der Klasse muss mich nicht darum kümmern, wie etwas gemacht wird. Ich stecke vorne was rein und bekomme hinten das gewünschte Ergebnis raus. Was die Klasse macht oder wie sie das Ergebnis produziert sehe ich nicht und muss mich auch nicht interessieren, so lange ich die Klasse nicht verbessere oder erweitere.

Wenn der Code gescheit dokumentiert ist, geht auch das mit prozeduraler Programmierung. Ich erwarte von einer Funktion ein Ergebnis, rufe sie auf und interessiere mich nicht dafür, wie sie das Ergebnis erreicht. Design by Contract nennt sich übrigens eine Entwicklungsmethode, die exakt das bis ins letzte Detail festschreibt. Die Implementierung ist dann egal, solange der Contract eingehalten wird.

Zitat von Peter Mössinger:

ich habe einen Kollegen, der einer der qualifiziertesten Mitarbeiter bei uns ist. Er ist aber ein Verfechter der prozeduralen Programmierung mit z.B. Perl oder der funktionalen Programmierung mit z.B. Lisp.

Welches sind die stichhaltigsten Argumente um die Vorteile von OOP in der Diskussion mit solch einem Kollegen herauszustellen?

Wenn er sein Handwerk wirklich versteht, gibt es keins. Er wird jedes Argument, das du lieferst, widerlegen können, so wie ich es oben mit Luckies Argumenten gemacht habe.
Ich könnte weitere Argumente nennen, die nicht so einfach zu wiederlegen sind, zum Beispiel ein vereinfachtes Error-Handling, über das parallel ein Thread läuft, oder die garantierte Typsicherheit aller Variablen, während bei prozeduraler Programmierung man bei einigen Strukturen typecasten muss, beispielsweise um wiederverwendbare verkettete Listen zu implementieren, ohne jedesmal die Knoten-Struktur und Teile des Interfaces auszutauschen.
In eine objektorientierten Sprache mit Templates (in .NET: Generics) kann man beispielsweise sowas schreiben:

Code:

SomeListClass<int> myList;
myList.Add(42);

SomeListClass<float> myOtherList;
myOtherList.Add(2.4);

Und das ohne Typecasting und ohne überladene Funktionen. Sogar folgendes ist möglich:

Code:

SomeListClass<SomeOtherClass*> yetAnotherList;
SomeOtherClass *someObject = new SomeOtherClass();
yetAnotherList.Add(someObject);

Das wird ihm mit Perl nicht so leicht gelingen, ohne Typecasts, bei denen er sich selbst um die Typsicherheit kümmern muss. In meinen Beispielen *garantiert* dir der Compiler, daß *du* nichts falsches machst.

Zitat von Peter Mössinger:

Ich höre von ihm immer: Dafür brauche ich keine Objekte, das kann ich in Perl auch auslagern.

Und damit hat er vollkommen Recht. Insbesondere die Standardargumente lassen sich damit sehr leicht wiederlegen, weil die Standardargumente das sind, was sie sind: Standard. Derartige Probleme tauchen ständig auf und wurde auch vor objektorientierten Sprachen ständig gelöst. Mit solchen Argumenten zu kommen ist sinnlos. Aber prinzipiell wurden schon immer Probleme irgendwie gelöst, auch ohne .NET, Java und hastenichgesehn. Es mag für einige Probleme eine elegante und eine weniger elegante Lösung geben, aber Eleganz liegt meist im Auge des Betrachters.
Wenn es bei euch nur darum geht, von A nach B zu kommen, wirst du immer den kürzeren ziehen. Umgekehrt wird einer, der versucht, dir prozedurale Programmierung einzuflößen, ebenfalls immer den kürzeren ziehen.

Zitat von Peter Mössinger:

Ausserdem kann man sich in der Objektorientierung auf eine höhere logische Ebene begeben.

Schau dir ruhig mal große prozedurale APIs an. Das sauberste, was mir da auf Anhieb einfällt, ist die GObject/GLib-API. Rein prozedural, aber dennoch so konzipiert, daß du genauso denken kannst wie bei einer objektorientierten API. Die Win32-API macht es aber genauso. Deine "Objekte" sind hier deine Fenster-IDs, und anstatt Fenster.Methode(Parameter) aufzurufen, rufst du Funktion(Fenster, Parameter) auf. Zugegeben, die Win32-API hat ein ziemlich ekliges Kommunikationsprinzip, weshalb alles hässlich aussieht, was mit mehr als einem Fenster zu tun hat, aber andere APIs machen das besser. Man begibt sich nicht auf eine höhere logische Problemlösungsebene, wenn man objektorientiert programmiert. Oder besser, man denkt nicht auf einer niedrigeren Ebene, wenn man prozedural programmiert, mit einer Ausnahme: man macht etwas falsch.

Zitat von Peter Mössinger:

Man muß mehr kommunizieren (Schnittstellen spezifizieren, modellieren, ..)

Das musst du bei prozeduraler Programmierung genauso, wenn man's richtig macht. Schließlich willst du auch bei prozeduralen Programmen wissen, wie du an welche Informationen von diesen und jenen Datensätzen rankommst oder welche Funktion du aufrufen musst, um TaskX zu erledigen.

Zitat von Peter Mössinger:

Die erforderliche Qualifikation der Mitarbeiter ist höher

Ich behaupte, daß das Gegenteil der Fall ist. IMHO ist es eine deutlich höhere Kunst, mit einer prozeduralen Sprache eine genauso elegante Lösung zu finden, als dies mit einer objektorientierten Sprache. Man muss sein Werkzeug (die Sprache) besser kennen, weil das Werkzeug anders denkt, als der Arbeiter. Ich habe großen Respekt vor den Gtk+-Programmierern, die eine erweiterbare, abwärtskompatible und übersichtliche API in C geschaffen haben. In C++ oder DelphiLanguage hätte das jeder Hinz und Kunz geschafft.