Verschachtelte Klassen

[1UnitedPower]

Hakuna matata!

Code wird sehr viel öfter gelesen als geschrieben und ich persönlich lese lieber prägnanten als aufgedunsenen Code.

Was du leider vergisst: wenn dein Konfigurations-Hash rumgereicht wird an Orte, die weit weg sind von dem Ort, wo er definiert ist, musst du immer nachschauen, wie deine Keys heißen, wie die genaue Struktur aussieht usw.

Das muss man auch, wenn man die Konfiguration mit Klassen implementiert. Aber das muss man nicht unbedingt im Quellcode machen, dafür ist eine Dokumentation der sehr viel bessere Ort. Moderne IDEs bieten inzwischen vermehrt sehr gute Möglichkeiten, um Dokumentationen verschiedener Arten, schnell zugriffsbereit zu machen.

Auch ist die Lösung fehleranfällig, z.B. gegenüber Tippfehlern bei Keys. Bei der Klassenlösung steht es im Vertrag der Klasse und niemand (korrekte Sichtbarkeit der Attribute vorausgesetzt) kann dagegen verstossen.

Wenn ich mit PHP eine Eigenschaft von einem Objekt lese, und diese Eigenschaft nicht exisitiert, dann wirft PHP eine E_NOTICE, und das völlig unabhängig davon, ob das Objekt die Instanz einer Klasse ist, oder ob es sich dabei um ein planes Objekt handelt.

Wenn ich eine Eigenschaft auf einem Objekt setzen möchte, und die Eigenschaft existiert noch nicht, dann wird die Eigenschaft ohne Fehlermeldung trotzdem angelegt, auch unabhängig davon, ob das Objekt die Instanz einer Klasse ist oder nicht. Das ist das DuckTyping-Prinzip.

Es gibt zur Laufzeit also keine zusätzliche Sicherheit gegen Tippfehler, wenn man Klassen einsetzt. Was dagegen wirklich gegen Tippfehler hilft, ist die Autovervollständigung des Editors, die dedlfix bereits erwähnt hat, und der Einsatz von Code-Quality-Tools aka. Linter, Hinter.

Eine allgemeingültige Lösung für die Frage "statische/dynamische Typisierung" gibt es IMHO nicht. Bei großen, komplexen Systemen mit vielen Entwicklern kann statische Typisierung (auch in Verbindung mit DDD) viele Vorteile bringen. Und gleichzeitig kann es zu viel Boilerplate in kleinen Projekten führen, bei denen man die Komplexität nicht braucht.

Eine allgemeingültige Lösung gibt es nicht, da stimme ich dir zu. Aber die Grenzen verlaufen nicht zwischen großen und kleinen Projekten, auch wenn die Anhänger von statischer Typisierung das gerne so darstellen. Aber es gibt ein entscheidenes Gegenargument: Es werden erfolgreich sehr große Projekte in dynamisch typisierten Sprachen geschrieben. Eric Elliott greift diese Thematik in seinem Talk übrigens auch auf.