|
|
Ähnlich wie Entwurfsmuster ist ein Framework ein Begriff, der insbesondere in den letzten Jahren im Kontext von Java-Programmen oft verwendet wurde. In der Fachliteratur stößt man häufig auf den Begriff Framework. Genau wie bei Entwurfsmustern sind die Vorstellungen, was eigentlich ein Framework ist, häufig unklar. Nachfolgend werden einige wesentliche Züge von Framework dargestellt. In der Literatur existieren verschiedene Definitionen des Begriffs Framework, die sich oft überschneiden. Michael Mattson definiert in [Matt96] das objektorientierte Framework folgendermaßen: „A (generative) architecture designed for maximum reuse, represented as a collective set of abstract and concrete classes; encapsulated potential behaviour for subclassed specializations." Die grundlegenden Ziele, die durch die Verwendung von Frameworks angestrebt werden, sind in dieser Definition enthalten. Mit Frameworks soll eine maximale Wiederverwendbarkeit von Software erreicht werden. Da bereits ein „Rahmen" vorgegeben ist, der die Verwendung vordefinierter Klassen ermöglicht (bzw. erzwingt), kann tatsächlich auf bereits erstellten Code zurückgegriffen werden. Für die Implementierung einer Anwendung müssen nur noch (Sub-)Klassen erstellt werden, die für das Problem relevant sind. Ein Großteil der Lösung ist bereits im Framework enthalten, das sich somit prägend auf die Realisierung der Implementierung auswirkt. In einem Framework wird also nicht alleine Programm-Code wiederverwendet, sondern auch dessen Design. Daraus ergibt sich, dass ein Framework auch einschränkend wirkt, da es immer auf bestimmte Problembereiche ausgelegt ist. Hier liegt eine grundlegende Schwierigkeit bei der Entwicklung eines Frameworks. Sind die Einschränkungen zu groß, so ist es womöglich nur für wenige (schlimmstenfalls für gar keine) Problemlösungen geeignet. Andererseits ist ein Framework, das fast alles zulässt, keine Unterstützung bei konkreten Problemstellungen. Eine übliche Vorgehensweise [Matt96] bei der Entwicklung von Frameworks besteht darin, zunächst einige Anwendungen aus einem zuvor festgelegten Problembereich zu erstellen. Anschließend überprüft man die Anwendungen auf Gemeinsamkeiten, die dann den ersten Ansatz für das Framework darstellen. Mit Hilfe dieses Frameworks werden die Anwendungen erneut erstellt, was unter Umständen eine Korrektur des Frameworks nach sich zieht. Anschließend werden weitere Anwendungen auf Grundlage des Frameworks erstellt, so dass dieses durch die damit gewonnenen Erfahrungen noch erweitert und verbessert werden kann. Diese Entwicklungsmethode ist schematisch in Abb. 2-2 dargestellt. Folgende Anwendungen werden auf der Grundlage des Frameworks erstellt, wobei dieses durch die damit gewonnenen Erfahrungen noch erweitert und verbessert werden kann.
Abb. 2.2: Entwicklungsprozess eines Frameworks Eine andere Betrachtungsweise der Entwicklung von Frameworks beinhaltet zusätzlich die Analyse des Problembereichs und die Festlegung von Design-Patterns (siehe Abb. 2-2). Vor dem Erstellen der ersten Anwendung wird bereits versucht, wichtige Aspekte zu formulieren, die im Framework integriert werden sollen. Wichtige Eigenschaften, die Anwendungen enthalten sollen, die mit dem Framework entwickelt wurden, werden als Design-Patterns formuliert. Diese Vorgaben unterstützen den Entwickler bei der Implementierung. Im Gegensatz zu Schnittstellen, die für die Implementierung verbindlich sind, handelt es sich dabei um Empfehlungen, die eingehalten werden sollten, aber nicht eingehalten werden müssen. Im Folgenden wird eine Framework-Definition verwendet, die eine Ergänzung der obigen Definition darstellt: „Ein Framework ist eine Sammlung von Regeln, Schnittstellen und Klassen. Es vereinfacht die Entwicklung durch die Unterstützung der Code-Wiederverwendung, die Vorgabe von Patterns (Mustern) und durch die bereits eingeflossene Fachkenntnis." Frameworks können in sog. White-Box- und Black-Box-Frameworks unterschieden werden, wobei die Begriffe White-Box und Black-Box auch in der OOP verwendet werden. Die Bezeichnungen repräsentieren eine unterschiedliche Transparenz. Ein White-Box-Framework gewährt Einblicke in die Implementierung, wodurch ein Benutzer durch besseres Verstehen des Frameworks seine Anwendungen unter Umständen effizienter implementieren kann. Ist aber außer der Kenntnis der Schnittstellen (Interfaces) dieses Verständnis zur Implementierung zwingend erforderlich, so wird die Arbeit dadurch eher erschwert. Basieren Anwendungen auf sichtbaren inneren Details, so wird eine Weiterentwicklung des Frameworks trotz unveränderter Schnittstellen problematisch [Szyp97]. White-Box-Frameworks werden deswegen lediglich als Zwischenstufe in der Entwicklung eines Frameworks betrachtet [Matt96]. Black-Box-Frameworks verbergen hingegen ihr Inneres. Lediglich die Schnittstelle ist nach außen sichtbar. Eine Anwendung stützt sich folglich auf diese Schnittstelle, was eine Veränderung der Implementierung des Frameworks erleichtert. Da nach außen hin immer noch die gleiche Schnittstelle sichtbar ist, „spürt" die auf dem Framework basierende Anwendungen nichts von der Veränderung. Black-Box-Frameworks sind deshalb bezüglich einer Wiederverwendbarkeit von Vorteil. Ein Beispiel für eine Black-Box-Abstraktion in der OOP sind die Application Programming Interfaces (APIs) vieler Programmiersprachen. Ein Programmierer kann ein API verwenden, ohne eine exakte Kenntnis über die Implementierung der Klassen zu haben. Auch das API von Java verbirgt sein Innenleben. Lediglich die Methoden und Variablen sind sichtbar, die für die Programmierung wichtig sind. Das Beispiel der APIs zeigt, wie komplex Frameworks werden können. In vielen Fällen, z. B. bei Einzelanwendungen, wird sich deshalb die Entwicklung eines Frameworks kaum lohnen. Bei größeren Projekten, in die viele Entwickler involviert sind, kann sich ein Framework durch schnellere und stabilere Entwicklung auszahlen. Zur Abwägung sollte man Vor- und Nachteile von Frameworks gegenüberstellen. Als Vorteile von Frameworks gelten [Matt96]:
Demgegenüber stehen die folgenden Nachteile Trotz der möglichen Nachteile bieten Frameworks gerade in größeren Projekten große Vorteile, bspw. die effiziente und vereinfachte Erstellung von Anwendungen. |
|
|
