Der Martin: Objektorientierung - Eine Fehlentwicklung der Informatik?

Beitrag lesen

Hallo,

der vermischt da Sachen, die so nicht direkt was miteinander zu tun haben und er verallgemeinert Erfahrungen, die ich so nicht bestätigen kann.

er vermischt vor allem das Prinzip und den Zweck der Objektorientierung mit der realen Implementierung großer objektorientierter Applikationen oder Frameworks. Ich stimme mit ihm überein, dass ein komplexes objektorientiert geschriebenes Framework oft schwieriger zu durchschauen ist als eine klassische Bibliothek einzelner Funktionen, die klar voneinander abgegrenzt sind. Solche Frameworks wirken, wenn sie fertig sind, wie ein riesiges Wollknäuel mit Tausenden von Schlaufen, Ösen und Knoten.

Dabei ist die Absicht doch eher, überschaubare Module (eben Objekte bzw. Klassen) mit klar definierter Funktionalität zu haben.

Klar hat er recht damit, dass sich in viele Softwareprojekten zu Tode geplant wird und nachher ein zu großes zu unflexibles Sytem heraus kommt, was der Kunde so gar nicht will und was nicht rechtzeitig fertig wird.

Ja, leider ist das oft so.

Daraus aber zu schiessen, man müsste nur das programmieren, was allgemein als  "quick and dirty" bezeichnet wird und alles wäre gut, ist in meinen Augen Humbug.

Klar, das ist völliger Unsinn.

Das Problem ist auch gar nicht mal "quick and dirty" eine Software zu entwickeln, die irgendwie funktioniert

Kommt auf die Zielsetzung an. Wenn ich irgendein Script, eine kleine Anwendung nur für den Eigenbedarf und nur für eine klar umrissene Aufgabe brauche, ist "quick & dirty" schon ab und zu okay.

In der Embeddedentwicklung hat sich Objektorientierung größtenteils noch nicht durchgesetzt und ich sehe die Nachteile jeden Tag. Zudem finde ich es geradezu lachhaft, es als Alternative zu betrachten, ganze Softwarepakete mal eben(?) neu zu schreiben, wenn sie so verwarzt sind, dass man nichts mehr daran ändern kann.

Kommt drauf an[tm]. Ich habe auch schon mehrmals erlebt, dass ich Stunden investiert habe, um den Code meines Vorgängers nachzuvollziehen, und dann habe ich's irgendwann aufgegeben und das Modul anhand der Spezifikationen und Anforderungen sauber neu geschrieben. Oder dass ich viel Zeit darauf verwendet habe, mich in die Klassenbibliothek einzuarbeiten, die jemand anders mir empfohlen hat, das Zusammenspiel der einzelnen Komponenten anhand der oft unbrauchbaren Dokumentation zu begreifen, die Beispiele nachzuvollziehen, bei deren Erklärung oft der entscheidene Schritt fehlt.
Das sind dann Situationen, wo das Neuschreiben eines übersichtlichen, leicht nachvollziehbaren Moduls günstiger sein kann, als den vorhandenen, aber konfusen Code um jeden Preis weiter zu verwenden.

Auch bei Neuentwicklungen kann die Wiederverwendbarkeit von bestehenden Modulen genau die Zeiteinsparung bringen, die die Nase eine Handbreit vor die des Konkurrenten bringt.

Ja. Setzt aber voraus, dass diese Module sauber gekapselt und dokumentiert sind. Da hapert's in der Praxis leider oft.

Nein, Software muss nicht generell leicht änderbar sein - sie sollte nur leicht erweiterbar sein. Und das liefert ein Objektorientierter Ansatz.

Einspruch: Leicht änderbar ist für mich ebenso wichtig wie leicht erweiterbar, das geht Hand in Hand. Wie oft hat man nicht Anforderungen "so ähnlich wie xyz, nur mit dem kleinen Unterschied, dass ..." Dann muss es möglich sein, das Modul xyz zu nehmen und die gewünschten Änderungen zielstrebig vorzunehmen und das Ganze nach entsprechender Verifikation vielleicht sogar als Variante von xyz für den Nächsten wieder ins Archiv zu legen.

Interessiert hätte mich auch noch, wie er mit "quick and dirty" eine ähnlich gute Testabdeckung erreichen will, aber vielleicht wird er ja in seinem Buch konkreter.

Ich glaube nicht.

Sein Bild eines Softwareentwicklers der alleine in seiner Bude hockt und über Nacht eine innovativ funktionierende Software zaubert, ist mir allerdings ein Graus.

Bis zu einem gewissen Grad passe ich auf dieses Schema, aber ...

Keine Teamarbeit, keine Kommunikation, keinen Plan [...] durch deren Software nie wieder jemand durchsteigt und die einem richtig fiese und schwer zu findende (und manchmal auch richtig gefährliche) Fehler bescheren.

... genau das darf nicht sein. Schnittstellen und Funktionsanforderungen müssen klar festgelegt sein; der resultierende Code leicht durchschaubar und wartbar, die Dokumentation für jeden mit entsprechendem Fachwissen verständlich.

Und um auf Andreas Orlik zurückzukommen: Mir scheint, er kritisiert (zu Recht) die herrschende Praxis objektorientierter Programmierung, ohne die zugrundeliegende (idealisierte) Theorie zu kennen.

So long,
 Martin

--
Um die Wahrheit zu erfahren, muss man den Menschen widersprechen.
  (George Bernhard Shaw)