Hallo P.,
Interfaces sind ein Tool. Du würdest auch nicht einen Hammer zum Eindrehen einer Schraube verwenden, oder? Also mußt Du zunächst verstehen, wozu Interfaces gut sind.
Wir alle schreiben Code. Viel Code. Das Problem dabei ist, dass wir - wie Du mit deinem Langzeitprojekt auch - den Code immer und immer wieder über lange Zeiträume verändern und an die geänderten Anforderungen und Einsichten anpassen
müssen. Ändern wir an der einen Stelle was (eben mal schnell), geht an vielen anderen Stellen was kaputt.
Man könnte sich jetzt an die ersten OOP-Stunden erinnern und an die Kapselungsfunktion von Klassen denken (hast Du auch getan, wie ich sehe). Durch diese sollte erreicht werden, dass Interna einer Klasse nicht nach außen, öffentlich sichtbar und damit
verändert werden können. Bringt uns das unserem Ziel näher, sauberen Code zu schreiben? Nur einen kleinen Schritt.
Denn außer der Kapselung müssen wir dafür sorgen, dass die Klassen untereinander lose gekoppelt sind. Wenn ich z.B. an den Konstruktor einer Klasse A eine Instanz der Klasse B als Parameter übergebe, dann mache ich die Klasse B von der Klasse A abhängig.
Besser ist es statt der Instanzvariablen - und jetzt kommen die Schnittstellen dran - eine Schnittstelle zu übergeben.
Damit macht sich Klasse A unabhängig von Klasse B. Das geht nun so weit, dass Klasse A die Klasse B gar nicht mehr braucht, sondern stattdessen eine beliebige Klasse, die die übergebene Schnittstelle implementiert. Die Implementationdetails sind nicht wichtig,
wichtig ist dass der vereinbarte Vertrag eingehalten wird.
Jede IDbConnection-Schnittstelle z.B. muss eine Open() und eine Close()-Methode bereitstellen. Das reicht mir schon um beliebige Verbindungen (zu SQL Server-/Oracle-/SQLite-Datenbanken) datenbank-agnostisch zu öffnen. Würde ich keine Schnittstelle verwenden,
müßten meine Methoden OpenSqlServerDb() und OpenOracleDb() heißen. Das würde zu Code-Duplizierung führen und die Wartung des Codes sehr erschweren und kostspielig machen.
Wie Peter das schon schrieb, macht es nicht viel Sinn, Schnittstellen zu verwenden, wenn Du nicht zumindest erwartest, dass in Zukunft auch andere Klassen diese Schnittstelle implementieren werden. Aber das ist mit der Kapselung in Klassen genauso: Wenn
eine bestimmte Klasse A exklusiv in Zusammenhang mit einer anderen Klasse B verwendet werden wird, dann wäre es besser die Klasse A in B zu deklarieren (einzubetten). Selbst interne Sichtbarkeit wäre für eine solche Klasse fehl am Platz, da viel zu weit.
Du hast die Open/Closed- bzw. Single Responsibility-Prinzipien kurz erwähnt. Interfaces helfen vor allem bei der Implementierung des ersten Prinzips weiter, da man die Angriffsfläche reduziert und die Abhängigkeit von äußerem Code reduziert.
Sollte man dann alle Abhängigkeiten als Interfaces formulieren? Nein. Genauso wie man nur das einkapseln soll, was sich in seinem Zustand ändert, sollte man nur das als Schnittstelle übergeben, von dem man erwartet, dass es sich in Zukunft ändern könnte
und von vielen Implementierern implementiert wird.
Eine Schnittstelle ist ein Vertrag. Es wäre schrecklich, wenn wir im Alltag alles vertragsmäßig (d.h. ohne Vertrauen) regeln müßten. Wenn Du eine Library schreibst, die von hunderten Entwicklern verwendet wird, oder wenn Du im allgemeinen wiederverwendbare
Klassen schreibst, sind Schnittstellen hiflreicher, als wenn Du eine nicht-erweiterbare Insel-Anwendung hast, die zwar hunderte verwenden, aber ein einzelner Entwickler schreibt.
Gruß
Marcel
