Operiert man in bestimmten Branchen mit sich in Funktionalität überlappenden Lösungen stellt sich oft die Frage nach der Erstellung oder Verwendung eines Frameworks. Nachfolgend soll kurz beschrieben werden, was Frameworks sind und wie man sie unterscheiden kann.
Definition Framework
Im Design Patterns Buch von Gamma et al. wird ein Framework als eine Menge von kooperierenden Klassen definiert, welche ein wiederverwendbares Design für eine bestimmte Kategorie definiert. Andere haben Frameworks allgemein als eine Menge von abstrakten Klassen definiert, je eine für jede grössere Komponente.
Wir lehnen uns an Gamma et al. an und definieren ein Framework als
"ein unvollständiges, jedoch konkretes und lösungsorientiertes Gerüst für eine verallgemeinerte Problemstellung."
Konkretisierung
Das Gerüst besteht nicht nur auf Papier oder als Idee, sondern als konkrete Implementierung, typischerweise verfügbar als Quelle oder binäre Library.
Unvollständigkeit
Das Gerüst enthält noch Löcher, die es vom Entwickler einer Endlösung zu füllen gilt. Dieses Ausfüllen wird vom Framework unterstützt. In etlichen Bereichen enthält das Framework Standard- oder Dummy-Implementierungen, die der Entwickler erweitern und an seine Situation anpassen kann.
Lösungsorientierung
Die Fertigstellung einer fertigen Lösung steht immer im Vordergrund des Gerüsts. Der Entwickler soll mit möglichst wenig Aufwand eine oder mehrere Lösungen mit Hilfe des Frameworks erstellen können.
Problemstellung
Das Gerüst zielt auf eine bestimmte Problemstellung und operiert innerhalb dieses Kontextes. Diese kann technischer oder funktionaler Natur sein. Sie ist jedoch abstrakt klar umrissen (z.B. Branche). Der Einsatz des Frameworks für eine andere Problemstelllung ist normalerweise nicht angezeigt.
Abgrenzungen
Frameworks können weiter unterschieden werden zwischen black- und white-box Frameworks. Diese werden auch called und calling Frameworks genannt. Bei letzteren ruft das Framework den Applikationscode auf, welcher dazu lediglich eine Klasse ableiten muss. Hier spielt die sogenannte inversion-of-control mit: Das Framework kontrolliert den ganzen Ablauf und ruft bei Bedarf diejenigen Klassen auf, die speziell implementiert wurden. Nachfolgende Abbildung illustriert dies im Gegensatz zu normalen Libraries (Funktions-Bibliotheken):
(a) traditionelle Bibliothek, (b) called (black-box) Framework, (c) calling (white-box) Framework. Entnommen aus Sparks et al. 1996
Frameworks sind selten klar einer der beiden Kategorien zuweisbar. Normalerweise kommen beide Muster zum Zuge, wobei eines überwiegt. White-box Ansätze sind einfach im ASP.Net Code-Behind zu erkennen, welches die implementierten Methoden im Lebenszyklus einer Seite aufruft. Die Kontrolle über den Zyklus bleibt weiterhin in den Händen des Frameworks, der Entwickler der Partikularlösung muss sich darum nicht kümmern.
Mittel zur Entwicklung eines Frameworks sind sicherlich Design Patterns und auch andere Frameworks, welche Teillösungen erlauben. Beim Einsatz von letzteren werden häufig Adapter verwendet, damit diese relativ einfach ausgetauscht werden können.
Ziele und Problem von Frameworks
Die folgenden Vorteile beim Einsatz von Frameworks werden genannt:
- Wiederverwendbarkeit von Design und Code.
- Einfachere Pflege laufender Anwendungen, da die Funktionalität des Frameworks nicht gewartet werden muss.
- Höhere Entwicklerproduktivität, da der Applikationsentwickler sich auf die domänenspezifischen Probleme konzentrieren kann.
- Kürzeres Time-to-market.
- Tendenz, weniger anfällig auf Fehler zu sein, da das Framework im Laufe der Zeit immer robuster wird.
- Präsentation und Systemdesigns verschiedener auf dem gleichen Framework basierenden Anwendungen homogener.
- Bessere Portabilität, wenn das Framework auf verschiedenen Plattformen verfügbar ist.
Aber auch Probleme können auftreten:
- Lernkurve bis der der Applikationsentwickler mit dem Framework arbeitet, kann hoch sein.
- Frameworks verändern sich im Laufe der Zeit, da sich auch die angesprochene Problemdomäne ändert.
Fazit
Der Einsatz von Frameworks macht fast immer Sinn, da mittlerweise eine Fülle von verschiedenen Produkten für sämtliche Ebenen existiert. Ob man selber ein eigenes Framework erstellt, hängt hauptsächlich davon ab, ob sich der Aufwand rechnet, d.h. ob eine hinreichend grosse Anzahl von Applikationen damit schneller erstellt werden kann.