Object-Oriented Programming is Bad

Hey, Danke für die Videoempfehlung, ich werde mir das ansehen.

Erstmal ne Vorbemerkung: Gut möglich, dass ich das Video zu positiv interpretiere. Das meinte ich mit "verdächtig" oben: Was er predigt ist verdammt nah an dem Punkt, an den ich auch gelangt bin. Zumindest nach meinem Verständnis, dann finde ich da ganz viel wieder was ich auch versuche umzusetzen. Ähnliche Einflüsse? Natürlich mach ich das selten radikal, aber die Richtung stimmt. Von daher werde ich im Zweifel auf der Seite "Das passt und deckt sich mit meinem Grundsatz" landen und könnte mich dabei täuschen.

> Den Grundsatz, dass in einem reinen OO-System Nachrichten keine Objekt-Referenzen enthalten, habe ich bisher noch nie gehört.

Doch, das stimmt schon. Message passinge ist das Stichwort, http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html spricht darüber beispielsweise. Zugegeben, ich bin nicht 100% sicher dass damit immer gemeint ist, dass in den Nachrichten keine Objekte oder Referenzen enthalten sind. Aber zumindest habe auch ich das so verstanden gehabt. Wenn er sich da vertut ist er damit nicht alleine.

Ich finde das schon etwas lustig und erwähnenswert. Da werden Predigten über möglichst saubere OO-Architektur gehalten, und dann verpassen diese Leitgeber was damit überhaupt ursprünglich gemeint war.

> Wenn man so programmieren will, um verteilten State zu verhindern, dann muss man tatsächlich wie von ihm beschrieben Handstände machen, Umwege gehen und Orchestrierungs-Objekte einfügen, da stimme ich ihm zu.

Ich glaube, da versteht du ihn miss. Diese Managerklassen und Umwege hast du jetzt schon in jedem typischen objektorientierten Programm. Message passing wäre nur eine weitere Komplexität.

> Wenn man die Klassen weglässt und stattdessen wie von ihm propagiert "nur" prozedural-strukturiert programmiert, muss man exakt die gleichen Aufruf-Hierarchie-Spielchen betreiben.

Den Punkt verstehe ich nicht. Jetzt mal davon abgesehen, dass im Idealstil des Videos Objekte nicht komplett verbannt werden - wie sollte man in einem prozedural-strukturierten Programm Aufruf-Hierarchie-Spielchen betreiben können? Das ginge doch gar nicht ohne eine ausufernde Objekthierarchie. Da hast du höchstens Scope.

> Vor allem, weil er danach noch Tricks aus der Tüte zieht (anonyme Lambdas in verschachtelten Blöcken), um irgendwie doch noch auf die Vorteile von extrahierten Funktionen zu komme

Ich finds sauber motiviert. Es geht darum, dass der Programmcode klar verständlich ist. Er wendet sich ja ausdrücklich gegen einen Programmstil, in dem der Flow des Programms nicht nachvollziehbar ist, weil alles über zehntausend Objekte und Funktionen verteilt ist. Mit den gekapselten Lambdas erreichst du benötigte Struktur, aber der Code ist immer noch an einer Stelle und der Flow des Programms ist durch die Funktionsnamen klar nachzuvollziehen. Ich mache das nicht oft, aber schon manchmal und es ist meist ne gute Lösung.

Wo du recht hast: Wenn das Ergebnis seitenlange Funktionen sind, ist dieses Prinzip zu weit getragen worden. Aber irgendwo muss der Kern der Logik sein, den nicht unnötig (!) zu verteilen ist ein guter Grundsatz. Wenn es zu lang wird zum Verstehen oder er besser in Funktionen passt weil an mehreren Stellen aufgerufen, dann ist es eben auch nötig.

> Blackbox-Tests sind zwar blöd, aber manchmal ist es gut, einen Test auf eine so extrahierte kleinere Methode machen zu können. Testet der nicht? Einige Kommentare seinerseits klangen danach.

Es gibt Extreme beim Testen. Wie keine Objekte in Objekten zu bauen, nur damit man beim Test Mock-Klassen injecten kann, obwohl das Unmengen an Komplexität schafft. Da gehts zu weit. Bei den Funktionen: Wenn man wirklich eine einzelne Lambdafunktion testen muss, dann passt das Prinzip oder der Test an der Stelle eben nicht.

> Hat er keine IDE? Code-Navigation ist deutlich einfacher, wenn man direkt die Funktionen anspringen kann, statt sich durch die Kommentare "hier Daten laden", "hier sortieren", "hier filtern" zu scrollen.

Ich habe jahrelang ohne IDE programmiert, mache es immer noch. Guter Code braucht keine IDE. Auch mit IDE sind gute Kommentare hilfreich. Nein, nicht "Daten laden", sondern die Funktion DatenLaden() mit dem Kommentar "Wir müssen die Daten hier schon laden weil X", wenn er denn nötig ist.

> "Ich weiß keinen guten Namen für diese Klasse, also programmiere ich ohne Klassen."

:) Nein, das ist wirklich nicht der Punkt. Es geht darum, dass diese -er Klassen ein Hinweis auf Abstraktheit und damit Komplexität sind. Dahinter steckt nahezu immer Funktionalität, die entweder in die vermeintlich verwalteten Klassen gehört. Oder es ist kein Manager, sondern einfach ein Domainobjekt und sollte entsprechend heißen. Peter Coad, wenn ich es richtig zuordne - oder war genau das auch im Video? So oder so, absolut mächtiges und wichtiges Prinzip, selbst wenn man weiterhin objektorientiert programmieren will.

> Das mit dem "OO-Nachrichten nur ohne Referenzen" sollte sich ganz von alleine lösen, wenn man seine Objekte immutable macht.

Ich glaube, das hätte auf das Problem gar keinen Einfluss. Man würde ja nicht die Objekte in den Nachrichten verschicken. Vll ist die Referenzproblematik da irreführend oder meint etwas anderes, was ich jetzt nicht mehr parat habe.

Andererseits: Klar. Mit den immutablen Objekten hat man auf einen Schlag eine Stelle mit schwer einsehbarem (da sich änderndem) Zustand weniger. Aber wenn es schlecht gemacht ist kommt er dann auf anderem Wege wieder. Ich sehe da den Vorteil mehr auf der Ebene der Speicherverwaltung, also für den Compiler, ähnlich wie bei Rust das Owner-Prinzip auch nur dem dient.

> "Wir lernen seit 20 Jahren dazu, wie man OO besser machen kann."

Sehr optimistisch. Wenn man sich anschaut, welche Art Code gerade in vermeintlich modernen Programmieruniversen produziert wird glaube ich das nicht. Ich hatte zu oft schon den Effekt, dass ich Software aufmache und es nicht nachvollziehbar ist was überhaupt passiert. Eben weil alles in Objekten ist, die durch Magie andere Objekte aufrufen die ebenfalls Magie für andere Objekte haben - aber nirgends ist echter Code. Laut der Packungsbeilage eine ganz saubere und gute Enterprise-Objektarchitektur, ist klar. Nur dass nichts verständlich oder gar anpassbar ist.

> Informatik ist nun mal ein paar hundert Jahre jünger als Brücken- oder Ackerbau, da kommt noch viel Wissen dazu.

Definitiv. Eine derzeit starke Strömung in Frage zu stellen ist aber einfach Teil des Prozesses. So wie die starke Strömung selbst da auch dazugehört, selbst wenn sie in die Irre führt.

Gute Position :)

> Ich würde jetzt gerne mal bei einem Bier aktuelle und zurückliegende von mir bespielte Anwendungsarchitekturen vorstellen und mir anhören, wie das anderswo ist.

Das fände ich auch cool.

Ich denke, wenn du bei euch nicht das Problem hast, dass man sich in den Programmcodes nicht zurechtfinden kann, dann ist das hier diagnostizierte Problem bei euch einfach kein Thema. Kleine Services sind ja praktisch ein Rezept gegen solche Probleme (kommt dann nur um Ganzen evtl wieder). GUI - vll ist das wirklich gut gemacht? Klingt erstmal so.

> Habe ich bisher einfach eine schöne Nische bewohnt und die ganzen State-Probleme sind an mir vorbeigezogen?

Es sind allerdings nicht nur State-Probleme, sondern Komplexität durch Objekthierarchien beim Versuch State zu verwalten. Mapper, Validatoren, .. können da auch so kritisch werden. Das schönste Beispiel das ich dafür kenne ist leider nicht Open Source, sonst würde ich gerne drauf verweisen :/ https://github.com/elgg/elgg ist aber auch ein Kandidat für eine nicht nachvollziehbare Architektur (wobei, um fair zu sein müsse ich mit Elgg erstmal versuchen etwas zu bauen um wirklich bewerten zu können ob sie nicht trotzdem funktioniert).

Hi mitch

> (Ich habe zufällig gerade einen Tag vorher https://www.youtube.com/watch?v=SFv8Wm2HdNM geguckt, das war auch interessant.)

Ich kam endlich dazu, das fertigzuschauen! Hatte die erste Hälfte fast sofort, aber die zweite erste jetzt gesehen.

Ich fand das auch interessant, cool zu sehen wie alt die Konzepte sind und was woher kommt. Aber etwas mitnehmbares in die Praxis? Ich sah nichts... Konntest du etwas daraus gewinnen?