Wednesday, April 05, 2006

Was macht ein gutes Framework aus?

Die richtige Abstraktion
Ein Framework ist für mich nur brauchbar, wenn die Abstraktionen "in meine Richtung" gehen. Beispielsweise kommt für mich z.B. Hibernate natürlich nur in Betracht, wenn ich Objektdaten in einer relationalen Datenbank speichern will.

Der richtige Abstraktionsgrad
Wenn Frameworks zu viel abstrahieren, sind sie nicht flexibel genug (CASE Problematik). Wird zu wenig abstrahiert, hab ich noch zu viel zu tun, weil ich den Rest selbst abstrahieren muss.

Don't Repeat Yourself
Ich "füttere" ein Framework ja sozusagen mit Informationen, in dem ich die Konfigurationssprachen und APIs verwende, mit anderen Worten in dem ich das Programmiermodell verwende.
Hier haben fast alle Frameworks Probleme. Es ist oft relativ schwierig ein Programmiermodel zu schaffen, dass mich nicht dazu zwingt Informationen zu wiederholen. Jedenfalls wenn man das API mit einer bestehenden Sprache (z.B. Java oder Ruby) definiert. Dynamisch getypte Sprachen (z.B. Python, Smalltalk, Ruby, Lisp) haben hier aber eindeutig ganz erhebliche Vorteile gegnüber statisch getypter Sprachen (C#, Java). Aber selbst das umjubelte Ruby on Rails definiert z.B. das domänenmodell noch nicht annähernd so kompakt, wie ich es mir wünsche.

Configuration/Programming by Exception
Hierbei geht es darum, die am häufigsten vorhandenen Sachverhalte als default anzunehmen, so dass nur in Ausnahmefällen (Exception) eine explizite Konfiguration angegeben werden muss.
Java ist da z.B. ein schlechtes Vorbild:
Die Access Modifier (public, private, protected, default), sind für Klassen member so definiert, dass die Modifier, die am häufigsten verwendet werden (public, private), immer angegeben werden müssen. Der Default (ohne keyword) wird hingegen sehr selten benötigt.

Configuration/Programming by Convention
Mit 'Programming by Convention' ist die Verwendung von Konventionen statt der Beschreibung expliziter Informationen gemeint.
Beispielsweise gibt es bei Rails die Konvention, dass der Name des domain objects (DO) der Singular des Namens der Datenbanktabelle ist.
Somit muss bei der Programmierung des DO nicht explizit angegeben werden, auf welche Datenbanktabelle es gemapped ist. Diese Information kann aus dem Namen abgeleitet werden. In Ausnahmefällen (Programming by Exception) kann der Name natürlich auch explizit angegeben werden.


Neben der Abstraktion und dem Programmiermodell sind natürlich noch andere Dinge wie z.B. klare, orthogonale Konzepte und hohe Testabdeckung wichtig.