Dienstag, 3. Juni 2014

Program to an Interface - das Prinzip


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,
Trenne Schnittstelle und Implementierung,
Trenne Verhalten und Implementierung
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 Programmierung
Das 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.

Beispiel(e) Siehe die oben genannten Blogartikel.
Historie
  • Als früher Vorläufer des Interface-als-Typ-Konzepts kann vermutlich die Programmiersprache CLU gelten, die bereits in den siebziger Jahren von Barbara Liskov und anderen entwickelt wurde. In CLU war es möglich, einer Klasse und ihrem Interface zwei separate Typen zuzuordnen. Auch wenn dies in CLU primär der Schaffung zweier separater Kompilier-Einheiten diente, so wäre doch auch eine Substitution verschiedener Implementierungen zur Laufzeit möglich gewesen, wie in "Abstraction mechanisms in CLU" [Liskov1977] erwähnt wird.
  • Die ersten detaillierteren Ausarbeitungen des Interface-als-Typ-Konzepts für objektorientierte Programmiersprachen sind vermutlich in den Veröffentlichungen Interfaces for strongly-typed object-oriented programming[Canning1989] sowie „Mixin-based Inheritance“ [Bracha1990] zu finden. Gilad Bracha setzte das Konzept der Mixins auch innerhalb des Typsystems von Strongtalk um, welches seit Frühjahr 1994 entwickelt wurde. Größere Verbreitung fand das Konzept allerdings erst mit der Einführung von Java, welches seit den frühen 1990er Jahren bei Sun entstand und 1995 in Version 1.0 erschien.
  • Die erste Formulierung des Prinzips in seiner heutigen Form erfolgte schließlich im allseits bekannten Buch „Design Patterns - Elements of Reusable Software“ der Gang of Four [GOF1995].
Art des Prinzips
  • Grundlegende Einteilung: Produkt.
  • Technologiebezug: Spezifisch (Objektorientierung).
  • Entwurfsgüte: Strukturprinzip.
  • Handlungsbezug: Erleichterung von Änderung, Wiederverwendung, Überprüfung und Verteilung.
  • Kognitionsbezug: Abstraktion.
(Siehe Kategorisierung der Prinzipien.)
Grad der formalen Spezifikation Als allgemeines Prinzip gering, kann aber für konkrete Anwendungen vergleichsweise gut sichergestellt oder überprüft werden, z. B. durch
  • die Nutzung von Audit-Prüfregeln wie „Declare as Interface“ in CodePro AnalytiX, siehe auch den Blogartikel zur Werkzeugunterstützung
  • eine Metrik-Suite, wie sie z. B. in [Meyer2003] für Java vorgeschlagen wird
  • die Nutzung expliziter Interfaceimplementierungen in C#.
Vorteile
  • Breiter Anwendungsbereich innerhalb statisch typisierter objektorientierter Programmiersprachen.
  • Fördert zahlreiche Qualitätsmerkmale.
  • In der Praxis umfangreich erprobt.
Nachteile
  • Im Einzelfall kann der Einsatz überflüssig sein.
  • Es werden daher zusätzliche Kriterien benötigt, um in Abwägungsfällen über den Einsatz von Interfaces zu entscheiden.
  • Einige Gegenbeispiele werden mitunter herangezogen, um das Prinzip als Ganzes in Frage zu stellen (z. B. Reused Abstractions Prinzip).
Übergeordnete Prinzipien Abstraktionsprinzip, Geheimnisprinzip, Prinzip der losen Kopplung
Abgleitete Prinzipien
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 

Keine Kommentare:

Kommentar veröffentlichen