LessCode

Beim Entwickeln von komplexen Systemen, die typischerweise aus verschiedenen Schichten bestehen, also z.B. Client-Interface <-> Server-API-Implementierung <-> Datenbankzugriffsschicht <-> ORM, kommt es oft vor (z.B. beim Einsatz klassischer Technologien wie Java/Spring/Hibernate),  dass sehr explizit Aufrufe durch die einzelnen Schichten geschehen. Beim Hinzufügen neuer oder der Änderung vorhandener Funktionen müssen dann mehrere Teile des Codes an unterschiedlichen Stellen erweitert/geändert werden. Meist wird der Aufruf jedoch nur an die nächste Schicht weiterdelegiert. Gerade in Kombination mit typisierten Sprachen wie Java bläht sich der Code dann erheblich auf: Dies wiederspricht dem DRY-Prinzip.

In der Vergangenheit wurde oftmals versucht, diesem Problem durch Codegenerierung Herr zu werden. MDSD (Model-Driven Software-Development) ist zwar eine gute Sache, um aus architektonischer Sicht das System zu definieren und zu begreifen, aber meist kommt nur Anfangs Freude auf, wenn nach einer oft recht aufwendigen Einführungsphase möglichst viel Code generiert wird. Langfristig zeigt die Praxis jedoch oftmals, dass das Prinzip zwar in der Tat nützlich ist (bezogen auf den Code, den man manuell schreiben muss), aber nicht wirklich beliebt in der Anwendung. Der Umgang mit den diversen Tools ist und bleibt ein komplexes Thema: Definition der diversen Modelle, Pflege der Templates und der Codegenerierungsinfrastruktur, Wahrung der Kompatibilität zum manuell geschriebenen Code usw.

Deshalb verzichtet der LessCoder lieber auf all den Overhead und nutzt ein System, das solche Aufrufe dynamisch vornimmt. Wichtig dabei ist, dass er an jeder Stelle eingreifen kann, wenn er muss, z.B. um DB-Transaktionen öffnen, Datenzugriffe über einen Cache beschleunigen, Businesslogik hinzufügen oder bestimmte Aufrufe nach außen anders anbieten möchte als sie intern funktionieren. Typische Frameworks bieten für diese typischen Arten der Konfiguration des Verhaltens meist einfache Mittel.

Der LessCoder ist sich bewusst, dass damit die Datenkapselung der jeweils darunter liegenden Schicht aufgebrochen wird. Allerdings kommt er für anfängliches Prototyping sehr direkt „von ganz vorne nach ganz hinten durch“. Was diesen Ansatz mächtig macht, ist, dass sobald Bedarf besteht, sich in diesen Automatismus eingreifen und der Datenzugriff z.B. über Deklaration oder expliziter Programmierung evolutionär immer feiner ausdefinieren lässt.

Genaugenommen ist dieser Punkt ein Spezialisierung von Konvention über Konfiguration und im Großen das, was der Artikel „Statische vs. Dynamische Typisierung: Overengineering im Kleinen?“ beschreibt

Durch automatisierte Tests wird gewährleistet, dass das System nach einem Refactoring immer noch funktioniert. Je dynamischer ein solches System ist, um so wichtiger sind automatisierte Tests.