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.