Frameworkers Dilemma
Advanced Patterns and Frameworks
Advanced Patterns and Frameworks
Frameworkers Dilemma
Die Schwierigkeit an der Entwicklung eines Frameworks ist es, dass definierte Schnittstellen nur noch schwer geändert werden können. Der Grund hierfür ist, dass Anwendungs-Code Framework-Interfaces implementiert oder Klassen ableitet. Bei der Ableitung entsteht eine der höchsten Kopplungen die in der Objektorientierten Programmierung möglich ist.
Lock-In
Durch die Verwendung eines Frameworks besteht die Gefahr, dass ein Vendor-Lockin erfolgt. Das heisst, dass die Anwendung nachher zu sehr von einem spezifischen Framework abhängig ist. Ein Beispiel hierfür ist Visual Basic, wo sogar das UI-Framework vorgegeben wurde.
Auswege aus Framework Dilemma
- Think very hard
- Don’t care about users
- Community
- Technologie
Think very hard
Bei diesem Ansatz wird sehr viel Zeit in das Designen neuer Komponenten investiert. Hierfür werden sehr erfahrene und talentierte Architekten benötigt. Die Erfahrung hat jedoch gezeigt, dass diese ohne konkrete Anwendungen sehr schwer ist und zu einem zu abstrakten und allgemeinen Framework führt.
Frameworks wie Java oder .NET wurden so entwickelt, wobei diese auf Erfahrungen aus anderen Sprachen zurückgreifen konnten.
Don’t care about users
Der Framework Entwickler kann die Benutzer dazu zwingen, dass diese beim Versionswechsel die notwendigen Migrationen durchführen. Bei der Portierung sollte eine Guideline wie wenn möglich Tools bereitgestellt werden, welche den Wechsel vereinfachen.
Die Gefahr bei diesem Ansatz ist, dass die Entwickler ihre Anwendung entweder nicht migrieren oder sich nach Alternativen umschauen.
Community
Der soziale Prozess erlaubt es, dass sich die Benutzer selbst mit einbringen können. Benutzer können durch das Markieren der Schnittstellen als deprecated zu einer Migration aufgefordert werden.
Eine Community hat jedoch meist die Tendenz eine ewige Rückwärtskompatibilität zu unterstützen. Dies kann dank einer starken community auch möglich sein. Zudem neigen diese Architekturen meist zu overgineerten Lösungen, da die Lösung es sämtlichen beteiligten Personen recht machen muss.
Technologie
Durch das Anwenden von Patterns und guten Prinzipien können relativ stabile Frameworks gebaut werden. Beim Entwurf sollte auf folgendes geachtet werden:
- Einfache Interfaces mit wenigen Funktionen und wenig Parameter, sind generell stabiler.
- flexible Interfaces: Beispiel readfile welches das Lesen von Daten mittels einem Handle erlaubt, wobei das Handle sowohl auf eine Datei wie auch auf einen Socket zeigen kann.
- Konfigurierbarkeit: Durch die Konfiguration verringert sich die direkte Kopplung innerhalb des Codes. Durch eine Umkonfiguration können neue Anwendungsfälle unterstützt werden.
- Patterns: Patterns wie das Extension Interface oder allgemein führen zu einer geringeren Kopplung.
- TDD: TDD kann zur Evaluation eines Designs verwendet werden und zeigt häufig früh unangenehme APIs auf.
-
- 1 / 7
-
Cartes-fiches
Frameworkers Dilemma
Die Schwierigkeit an der Entwicklung eines Frameworks ist es, dass definierte Schnittstellen nur noch schwer geändert werden können. Der Grund hierfür ist, dass Anwendungs-Code Framework-Interfaces implementiert oder Klassen ableitet. Bei der Ableitung entsteht eine der höchsten Kopplungen die in der Objektorientierten Programmierung möglich ist.
Lock-In
Durch die Verwendung eines Frameworks besteht die Gefahr, dass ein Vendor-Lockin erfolgt. Das heisst, dass die Anwendung nachher zu sehr von einem spezifischen Framework abhängig ist. Ein Beispiel hierfür ist Visual Basic, wo sogar das UI-Framework vorgegeben wurde.
Auswege aus Framework Dilemma
- Think very hard
- Don’t care about users
- Community
- Technologie
Think very hard
Bei diesem Ansatz wird sehr viel Zeit in das Designen neuer Komponenten investiert. Hierfür werden sehr erfahrene und talentierte Architekten benötigt. Die Erfahrung hat jedoch gezeigt, dass diese ohne konkrete Anwendungen sehr schwer ist und zu einem zu abstrakten und allgemeinen Framework führt.
Frameworks wie Java oder .NET wurden so entwickelt, wobei diese auf Erfahrungen aus anderen Sprachen zurückgreifen konnten.
Don’t care about users
Der Framework Entwickler kann die Benutzer dazu zwingen, dass diese beim Versionswechsel die notwendigen Migrationen durchführen. Bei der Portierung sollte eine Guideline wie wenn möglich Tools bereitgestellt werden, welche den Wechsel vereinfachen.
Die Gefahr bei diesem Ansatz ist, dass die Entwickler ihre Anwendung entweder nicht migrieren oder sich nach Alternativen umschauen.
Community
Der soziale Prozess erlaubt es, dass sich die Benutzer selbst mit einbringen können. Benutzer können durch das Markieren der Schnittstellen als deprecated zu einer Migration aufgefordert werden.
Eine Community hat jedoch meist die Tendenz eine ewige Rückwärtskompatibilität zu unterstützen. Dies kann dank einer starken community auch möglich sein. Zudem neigen diese Architekturen meist zu overgineerten Lösungen, da die Lösung es sämtlichen beteiligten Personen recht machen muss.
Technologie
Durch das Anwenden von Patterns und guten Prinzipien können relativ stabile Frameworks gebaut werden. Beim Entwurf sollte auf folgendes geachtet werden:
- Einfache Interfaces mit wenigen Funktionen und wenig Parameter, sind generell stabiler.
- flexible Interfaces: Beispiel readfile welches das Lesen von Daten mittels einem Handle erlaubt, wobei das Handle sowohl auf eine Datei wie auch auf einen Socket zeigen kann.
- Konfigurierbarkeit: Durch die Konfiguration verringert sich die direkte Kopplung innerhalb des Codes. Durch eine Umkonfiguration können neue Anwendungsfälle unterstützt werden.
- Patterns: Patterns wie das Extension Interface oder allgemein führen zu einer geringeren Kopplung.
- TDD: TDD kann zur Evaluation eines Designs verwendet werden und zeigt häufig früh unangenehme APIs auf.
