“Programmiere auf eine Schnittstelle hin, nicht auf eine Implementierung”, heißt es im GOF Design-Pattern Buch auf Seite 18. Das Buch ist von 1995. Wird von einer Schnittstelle gesprochen, so sind die öffentlichen Methoden eines Objekts gemeint. Der Begriff Klasse wird grundsätzlich als konkretes Implementierungskonzept aufgefasst. Auf Modellierungsebene betrachtet man lediglich die Schnittstelle.
Soweit ist der Ratschlag, immer auf eine Schnittstelle hinzuprogrammieren, immer noch Implementierungsneutral. Die Schnittstelle eines Objekts wird ja noch als dessen öffentliche Methoden beschrieben. Die Implementierung des Modells könnte durch einfache Klassen erfolgen. Doch leider folgt im Buch eine Klarstellung, die in Ihrer Absolutheit, in einem Lehrbuch dieser Bedeutung, zu viel unnötigem Quelltext in vielen Softwareprojekten geführt hat: „Verwenden Sie Variablen nicht als Exemplare konkreter Klassen. Verwenden Sie stattdessen, durch abstrakte Klassen definierte Schnittstellen“.
In einer der extremsten Varianten dieser Denkweise, werden Schnittstellen als Kontrakte physisch separiert. Zunächst sei festgestellt: Projekte die diesen Leitfäden folgen sind meist guter Qualität, denn wer solchen Regeln folgt, hat sich mit Architektur auseinandergesetzt. Der Code ist meist gut strukturiert und durchdacht, Entwurfsmuster werden angewendet, es gibt eine bewusste entwickelte Architektur.
Doch hat das ausschließliche programmieren gegen explizit deklarierte Schnittstellen seine Probleme, denn werden diese Schnittstellen nicht zum Mocken benötigt, weil die Tests klassizistisch durchgeführt werden (s. Mockist vs. Klassizist) oder werden Schnittstellen nicht für Polymorphismus, meist innerhalb eines Entwurfsmusters, verwendet, dann sind Schnittstellen YAGNI, potentieller Ballast, der sich dadurch zeigt, dass für die Schnittstellendeklaration immer nur eine Implementierung existiert.
Im Gegensatz zu 1995 ist heute „Extrakt Inteface“ eine toolgestützte Refaktorisierung, bei der auch alle Verwendungen des extrahierten Schnittstellen Typens ausgetauscht werden. In einem testgetriebenen Entwicklungsprozess, ist also der Wandel einer normalen Schnittstelle (alle öffentlichen Methoden und Properties einer Klassendeklaration) zu einer Schnittstellendeklaration, ein Schritt, der erst notwendig ist, wenn er benötigt wird.
Viele der wesentlichen Trends der letzten Jahre, probieren Entscheidungen nach hinten zu verschieben und nicht vorzeitig zu fällen. Vorzeitige Optimierung (premature optimization) ist nicht grundlos eines der ältesten Anti-Muster, oft ist es möglich, dass die Verwendung von Schnittstellendeklarationen in dieses Anti-Muster verfällt, hier lohnt es zu hinterfragen.
