Große JS-Dateien

[Rolf B]

Hallo fischlak,

Aber so weit wollte ich gar nicht gehen. Ich wollte mich eigentlich über Erfahrungen bezüglich der Folding-Implementation heutiger Editoren austauschen und keine Grundsatzdiskussion Prozedual vs. OOP anreißen.

Das hast Du aber getan. Weil Du deine Methode damit verteidigst, dass OOP nichts taugt. Okay - genauer gesagt: für Dich nichts taugt. Aber hier bringst Du einen OO-Hammer nach dem anderen.

Für Solo-Entwickler (...) kann ein prozeduraler/funktionaler/modularer Ansatz deutlich effizienter sein (als OOP).

OOP-Code (ist) im Vergleich zu rein prozeduralen Ansätzen etwa 17 % bis 38 % umfangreicher

Ja. Beides ist richtig. Und zumeist ist die OO-Variante auch etwas langsamer.

Hingegen ist

Allein die Definition von Klassen fügt oft eine zusätzliche "Einrückungsebene" hinzu, was die Lesbarkeit bei kleineren Skripten erschweren kann.

ein schwaches Argument. Programmierst Du auf dem Smartphone oder rückst Du mit achtstelligen Tabs ein, dass Dich ein bis zwei Einrückungsstufen stören? Im übrigen bescheren Dir deine Folding-Funktionen ebenfalls weitere Einrückung.

Anstatt Daten direkt zu verarbeiten, werden sie in Objekten gekapselt.

Was definitiv ein Vorteil ist. Zusammengehörige Daten liegen beisammen, und der Code, der für sie zuständig ist, auch. Ohne diese Kapselung musst Du den Code, der eine bestimmte Variable ändert, im ganzen Programm suchen. Darüber hinaus haben Setter den Vorteil, dass Du darin einen Breakpoint setzen oder Log-Aufrufe einbauen und damit den Ablauf beim Debuggen gut tracen kannst. JA, das erscheint langsamer. Ich hatte in den 90er Jahren, als man unsere Abteilung mit SmallTalk beglückt hat, dazu heiße Diskussionen, weil ich es damals auch nicht einsehen wollte. Mittlerweile bin ich kuriert (von Smalltalk und von der Abneigung gegen Getter und Setter).

"Du wolltest eine Banane, aber was du bekamst, war ein Gorilla, der die Banane hält, und den gesamten Dschungel dazu"

ist hingegen aus dem Zusammenhang gerissen. Das Zitat kritisiert ein Problem der Wiederverwendbarkeit von OO-Code. Wenn die Banane tatsächlich genießbar ist, ohne dass der Gorilla sie hält (oder sich in seinem Dschungel befindet), die Klasse aber so erstellt wurde, dass man sie unbedingt nur im Dschungel essen kann, dann taugt entweder das Klassendesign nichts. Oder der Wiederverwender, denn Joe Armstrong fährt so fort:

"If you have referentially transparent code, if you have pure functions-all the data comes in its input arguments and everything goes out and leaves no state behind-it's incredibly reusable. You can just reuse it here, there, and everywhere. When you want to use it in a different project, you just cut and paste this code into your new project."

Er spricht also nicht von Klassenbibliotheken, sondern von Sourcecode-Übernahme. Klassen neigen zu Kohärenz, d.h. die Methoden einer Klasse hängen inhaltlich zusammen und bearbeiten gemeinsame Daten. Wenn ich die Banane (eine Methode aus einer Klasse) nicht aus ihrer Klasse herauskopieren kann, um sie wiederzuverwenden, dann hat das bei ordentlichem Design wohl den Grund, dass diese Banane nicht wiederverwendbar ist.

Allerdings muss man auch sehen, dass das Zitat von jemandem stammt, der stolz von dem Loch in der Wand erzählt, dass das C++-Buch hinterließ, als er es angewidert weggeschmissen hat, und der Jahrzehnte an FORTRAN auf dem Buckel hat^[1]

OOP entfaltet seine Stärken erst, wenn Teams an komplexen Systemen arbeiten, bei denen Kapselung wichtiger ist als Code-Schlankheit.

ignoriert die Vorteile dieser Kapselung, die auch bei kleinen Projekten relevant sind. Oder bei größeren Einzelentwicklerprojekten Du erwähntest den Testaufwand. Unit-Tests können diesen Testaufwand deutlich verringern, vor allem bei der Weiterentwicklung, weil sie Dir die Sicherheit geben können, dass sich dein Code immer noch alle vorherigen Spezifikationen erfüllt. Sie machen natürlich im Vorfeld mehr Aufwand und man braucht den Toolstack dafür. Beim Bau einer einfachen Anwendung scheut man das, aber sehr viele komplexe Anwendungen sind aus einfachen Anwendungen entstanden und stecken am Ende im Sumpf ihrer unauflösbaren Abhängigkeiten fest.

Das ist das Ziel von OO: Code-Abhängigkeiten reduzieren bzw. sie sichtbar zu machen, wo sie bestehen. Und Softwareschichten lose zu koppeln. Ein kleines Programm lässt sich mit der VHIG^[2]-Methode erstellen. 3500 Zeilen sind noch halbwegs klein.

Wenn ich alleine arbeite, erreiche ich mit OOP nur noch mehr Fragmentierung.

Diese „Fragmentierung“ nennt sich Separierung von Zuständigkeiten. Wenn Du deren Vorteile nicht erkennst, ist dein Code vielleicht noch nicht durch genug Iterationen gelaufen. Oder nicht sehr komplex. Viele Zeilen können den Code kompliziert machen, aber komplex und kompliziert sind unterschiedliche Achsen im Koordinatensystem des Coding-Wahns.

Rolf

---

1. Quelle: https://erlang.org/pipermail/erlang-questions/2013-January/071944.html ↩︎

2. Vom Hirn Ins Gerät ↩︎