Mittwoch, 14. Mai 2014

Program to an Interface - Einführung

"Program to an interface, not an implementation." Erstes Prinzip des objektorientierten Entwurfs, [GOF1995].
Als 1995 der Entwurfsmuster-Katalog der Gang of Four erschien, war die finale Version von Java 1.0 noch nicht einmal veröffentlicht. Im Kapitel "Klassen- versus Schnittstellenvererbung" findet Java keinerlei Erwähnung, wohl aber Smalltalk, Eiffel und C++, und das obwohl die gemeinte Schnittstellenvererbung exakt so beschrieben ist, wie sie von Java nur wenig später realisiert wurde, während in Smalltalk, Eiffel und C++ Interfaces als syntaktisches Konstrukt gar nicht vorhanden waren.

Das macht deutlich, dass das Interface-als-Typ-Konzept zur damaligen Zeit gewissermaßen "in der Luft lag". Die beiden Prinzipien Program to an interface, not an implementation und Favour composition over interitance können als die beiden Haupt-Fundamente des Entwurfsmuster-Katalogs betrachtet werden. Bis auf zwei Entwurfsmuster (Singleton und Memento) basieren alle Muster auf abstrakten Typen.

Während allerdings Entwurfsmuster in kürzester Zeit auch in der Praxis umfassende Verbreitung fanden, galt dies für Interfaces-als-Typen keineswegs. [Steimann2005] zeigt dies an Hand der Historie der Verwendung von Interfaces im JDK selbst: Enthielt Java 1.0.2 noch ca. 0,3 Interface-Implementierungen pro Klasse, so stieg dieses Verhältnis in Version 1.1.6 (April 1998) auf 0,8 und in Version 1.2.1 (März 1999) bereits auf 1,8. Und auch das Verhältnis der Interface-typisierten Variablen gegenüber Klassen-typisierten Variablen verschob sich erst mit Version 1.2.1 von ca. 1:9 in Version 1.0.2 auf ca. 1:5.

Heute kann "interfacebasierte Programmierung" als etabliert gelten, wenn sie auch weiterhin sehr viel weniger angewandt wird als es sinnvoll wäre. Die Formulierung des Prinzips "Program to an interface, not an implementation" suggeriert eine Absolutheit, die vermutlich nicht förderlich war - kann es doch kaum angebracht sein, für jede Klasse ein Interface einzuführen und jede Variable mit einem Interface-Typen zu deklarieren. Der Umkehrschluss, dann lieber ganz auf Interfaces zu verzichten, ist freilich genauso unplausibel. Dann aber muss es Kriterien geben, die das Prinzip unterstützen und Entscheidungshilfe leisten, wann der Einsatz von Interfaces angeraten ist und wann nicht. Mit diesen Fragestellungen beschäftigen sich die folgenden Artikel. Zu diesem Zweck müssen zunächst einige Eigenschaften und verschiedene Einsatzzwecke von Interfaces erläutert werden.

Siehe auch

Alle Artikel der Serie "Program to an Interface ...":

Einführung
Kategorisierung von Interfaces
Totale 1:n-Interfaces
Totale 1:1-Interfaces
Freiwillig partielle Interfaces
Notwendig partielle Interfaces
Fazit und Gegenbeispiele
Interface oder abstrakte Klasse?
Werkzeugunterstützung
Das Prinzip

Quellen

[GOF1995] - Design Patterns - Elements of Reusable Software, E. Gamma, R. Helm, R. Johnson, J. Vlissides, (Addison‐Wesley, 1995).
[Steimann2005] - Patterns of interface‐based programming, F. Steimann, P. Mayer, Journal of
Object Technology 4:5,
75–94 (2005).

Keine Kommentare:

Kommentar veröffentlichen