"Program to an interface, not an implementation." Erstes Prinzip des objektorientierten Entwurfs, [GOF1995].In den vorangehenden Blogartikeln wurden Interfaces zunächst in vier Kategorien eingeteilt. Anschließend wurde für jede dieser Kategorien besprochen, worin die Motivation für deren Einsatz besteht, welche Alternativen es gibt und wann ggf. von einem Einsatz abzusehen ist:
- totale 1:1-Interfaces
- totale 1:n-Interfaces
- freiwillig partielle Interfaces
- notwendig partielle Interfaces
Fazit: Bedingungen für den Einsatz eines Interfaces
Die klarsten Bedingungen, die für den Einsatz eines Interfaces sprechen, fanden wir bei totalen 1:n-Interfaces und bei notwendig partiellen Interfaces vor. Zusätzlich sind in diesen Konstellationen keine nennenswerten Nachteile durch den Interface-Einsatz erkennbar, die nicht auch in alternativen Lösungsansätzen auftreten können.- Totale 1:n-Interfaces bieten durch den Einsatz von Polymorphie und dynamischer Bindung eine einfache und elegante Möglichkeit, die Austauschbarkeit und Auswählbarkeit von Implementierungsteilen herzustellen (Single Choice Prinzip) und die Offenheit für weitere Implementierungsteile (Open-Closed Prinzip) zu gewährleisten.
- Notwendig partielle Interfaces stellen eine in statisch typisierten objektorientierten Programmiersprachen natürliche und leistungsfähige Möglichkeit dar, als Platzhalter in der Implementierung eines Aufrufers verwendet zu werden.
Diejenige Interface-Kategorie, die in der Praxis am häufigsten vermieden werden dürfte, sind die totalen 1:1-Interfaces. Das einzige Argument für diese Interface-Kategorie besteht in der Entkopplung der Aufrufer von der Implementierung. Insofern durch diese Entkopplung kein arbeitsteiliger Entwicklungsprozess unterstützt wird, kein modellgetriebener Entwicklungsansatz besteht und keine Entkopplung des Deployments erforderlich ist, haben wir die erforderliche Abwägung mittels der Formel
Kosten für das Interface < Erwartete Austauschkosten
ausgedrückt. Sind sowohl die Austauschwahrscheinlichkeit als auch die Austauschkosten im Falle eines Austauschs gering, so ist die Einführung eines Interfaces hier eher zu vermeiden.
Typische Beispiele für sinnvollen Verzicht auf Interfaces
Verzicht bei enger KopplungBesteht zwischen zwei Klassen inhaltlich eine sehr enge Kopplung, so erscheint die Einführung eines Interfaces (insbesondere wenn es sich um ein 1:1-Interface handelt, also nur genau eine Implementierung existiert), als überflüssiger Mehraufwand. Wenn es beispielsweise keinen Sinn ergibt, den Aufrufer ohne den Aufgerufenen zu testen, so ist dies ein klarer Hinweis auf eine solche enge Kopplung.
Klassen des Domänenmodells
Für die Klassen eines Domänenmodells (insbesondere wenn es sich um persistente Entitäten ohne Verhalten handelt) kann die Nutzung von Interfaces überflüssig sein. Das Domänenmodell einer Anwendung ist oftmals sehr stabil, und falls die Entitäten nicht über eigenes Verhalten verfügen, so ist der künftige Austausch einer Implementierung praktisch auszuschließen.
Stabile Hilfsklassen
In jeder Anwendung existiert eine Anzahl relativ stabiler Hilfsklassen, die oftmals als Singleton oder über statische Methoden genutzt werden. Die Art dieser Hilfsdienste kann z. T. so konkret sein, dass ein künftiger Austausch der Implementierung sehr unwahrscheinlich ist. Stellen wir uns beispielsweise eine Klasse mit Validierungsmethoden für Benutzereingaben vor. Derartige Methoden nehmen oft simple Musterprüfungen oder Prüfungen von Wertebereichen vor, für die nur schwer vorstellbar ist, dass sie als gesamte Implementierung einmal ausgetauscht werden müssen.
Performance-Gründe
Gerade im Umfeld der Entwicklung für mobile Endgeräte, wo Performance immernoch ein zentrales Entwurfsziel ist, trifft man gelegentlich auf die Empfehlung zum Verzicht auf Interfaces. Gemäß [Alpern2001] sind drei Gründe zu identifizieren, die eine potentielle Performance-Verschlechterung durch die Nutzung von Interfaces bewirken können:
- ein Overhead durch Typprüfung
- der komplexere Dispatching-Mechanismus für Interface-Methoden
- fehlende Optimierungen
Hinweis: Für die Schilderung weiterer Konstellationen, in denen ein Verzicht auf die Nutzung von Interfaces sinnvoll sein könnte, wäre ich sehr dankbar. Ich würde die hier vorgestellte Beispiel-Liste gerne entsprechend erweitern.
Siehe auch
Alle Artikel der Serie "Program to an Interface ...":Quellen
[Alpern2001] - Efficient Implementation of Java Interfaces - Invokeinterface considered harmless, B. Alpern, A. Cocchi, S. Fink, D. Grove, D. Lieber, OOPSLA '01 Proceedings of the 16th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, Seiten 108-124 (2001)[GOF1995] - Design Patterns - Elements of Reusable Software, E. Gamma, R. Helm, R. Johnson, J. Vlissides, (Addison‐Wesley, 1995)
