Name, Kurzform | Program to an Interface, not an implementation. |
Synonyme | Es gibt einige Bezeichnungen des Prinzips, die es aber leider alle nicht besonders gut treffen: Prinzip der Abtrennung von Schnittstellen,Auch die Übersetzung der deutschen Version von [GOF1995] taugt nichts: "Programmiere auf eine Schnittstelle hin, nicht auf eine Implementierung." [Deutsch:GOF1996][Steimann2005] gibt dem Kind einen Namen, der eher an ein Paradigma erinnert als ein Prinzip: Interfacebasierte ProgrammierungDas ist zwar etwas übertrieben, scheint aber als Kurzform im Deutschen noch am passendsten zu sein. |
Beschreibung | „Program to an Interface, not an implementation.“ [GOF1995] |
Erläuterung |
Interfacebasierte
Programmierung ist im Wesentlichen dadurch gekennzeichnet, dass
möglichst überall dort, wo zur Deklaration von Feldern oder Methoden ein
Typ angegeben werden muss, nicht der Typ einer konkreten Klasse, sondern ein Interface-Typ verwendet wird. Zu
diesem Zweck ist freilich ein entsprechendes Interface zu
deklarieren, und die zugehörige(n) Klasse(n) müssen
dieses Interface implementieren. In Sprachen, die nicht über ein separates Interface-Konstrukt verfügen, können je nach Verfügbarkeit abstrakte Klassen oder Traits im Sinne des Interface-als-Typ-Konzepts verwendet werden. (Siehe Interfaces und abstrakte Klassen - Vergleich einiger Programmiersprachen.)
Das
Prinzip hat keinen absoluten Charakter, d. h. es kann nicht so
verstanden werden, dass für ausnahmslos alle konkreten Klassen
ein zugehöriges Interface zu deklarieren ist. Es ist aber als
eine nachhaltige Empfehlung zu verstehen. Wenn man von der Nutzung
eines Interfaces absieht, sollten im Einzelfall konkrete Gründe
gegen diese Nutzung sprechen.
Die
Motivation des Prinzips und eventuelle Gegenanzeigen wurden in
folgenden Blogartikeln ausführlich besprochen:
|
Beispiel(e) | Siehe die oben genannten Blogartikel. |
Historie |
|
Art des Prinzips |
|
Grad der formalen Spezifikation | Als
allgemeines Prinzip gering, kann aber für konkrete Anwendungen
vergleichsweise gut sichergestellt oder überprüft werden, z. B.
durch
|
Vorteile |
|
Nachteile |
|
Übergeordnete Prinzipien | Abstraktionsprinzip, Geheimnisprinzip, Prinzip der losen Kopplung |
Abgleitete Prinzipien |
Interfacebezogen: Interface
Segregation Prinzip
Häufiges Zusammenspiel: Dependency Inversion Prinzip
Gegenprinzip:
Reused Abstractions Prinzip |
Qualitätsmerkmale | Änderbarkeit (+), Testbarkeit (+), Wiederverwendbarkeit (+) |
Quellen
[Bracha1990] - Mixin-based Inheritance, Gilad Bracha, William R. Cook (1990), siehe http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.128.8192&rep=rep1&type=pdf
[Canning1989]
- Interfaces for strongly-typed
object-oriented programming, Peter
S. Canning, William R. Cook, Walter L. Hill, Walter G. Olthoff
(Hewlett-Packard Laboratories, 1989), siehe
http://www.cs.utexas.edu/~wcook/papers/OOPSLA89/interfaces.pdf
[Deutsch:GOF1996] - Entwurfsmuster - Elemente wiederverwendbarer objektorientierter Software, E. Gamma, R. Helm, R. Johnson, J. Vlissides, (Addison‐Wesley, 1996)
[GOF1995] - Design Patterns - Elements of Reusable Software, E. Gamma, R. Helm, R. Johnson, J. Vlissides, (Addison‐Wesley, 1995)
[Liskov1977] - Abstraction mechanisms in CLU, B. Liskov, A. Snyder, R. Atkinson, C. Schaffert (1977), siehe https://www.splint.org/~weimer/2006-655/reading/liskov-clu-abstraction.pdf
[Meyer2003] – Eine Metrik-Suite zur Analyse des Einsatzes von Interfaces in Java, Philip Mayer (2003), siehe http://www.pst.ifi.lmu.de/~mayer/papers/2003_02_Bachelor_Thesis.pdf
[Steimann2005] - Patterns of interface‐based programming, F. Steimann, P. Mayer, Journal of Object Technology 4:5, 75–94 (2005), http://www.jot.fm/issues/issue_2005_07/article1.pdf