Hallo,

in letzter Zeit verstricke ich mich immer wieder mit ein paar Kollegen in die Diskussion wie viele Interfaces in einer z.B. Web-Applikation genug sind.

Hintergrund:
Ein kleines Startup-Projekt. Web-UI, Geschäftslogik, Persistenz (JPA + Hibernate) also alles in Java.

Die gute alte Schule sagt: "Trenne die Schichten z.B. mit Schnittstellen".

DAO-Interfaces
Also gut. Führen wir also DAOs ein so gibt es ein IXyzDAO und eine XyzJpaDAO Implementierung.
Schön.
Somit haben wir die JPA Technologie vor dem Rest der Anwendung versteckt. Will man auf JDO umsteigen so kann man einfach eine andere Implementierung der Anwendung unterschieben. Die Geschäftslogik arbeitet ja nur mit dem IXyzDAO. Oder ich gehe mal auf XML oder sonst etwas. Mir scheint bei DAOs ja gerade ein muss für Interfaces.

Fassaden-Interfaces
Nun gut. Wie spricht das Web-UI nun mit der Geschäftslogik.
Da sagt die gute alte Schule: "Fassaden sind was gutes".
Also gut. Führen wir Fassaden ein. Hier gibt es vielleicht eine Fassade für einfache Aufgaben die vielleicht nur an die DAOs weitergeleitet werden oder Fassaden für einzelne UseCases usw.
Hier handelt sich es aber doch um zwei Schichten die miteinander reden. Also führen wir auch noch IFassaden ein.
Hm, Tauschen wir die Fassaden Implementierungen mal aus? Wohl nicht. Erweitern vielleicht - aber komplett austauschen. Warum also dann die Interfaces...
Nun ja. Wie sieht es denn mit Testen aus. Die Gui ist schnell mal hingecoded und will vielleicht schon was anzeigen. FassadenMocks sind da was schönes. Die Gui arbeitet schon mit den Interfaces also kann ich die schön für Tests verwenden und der Gui ggf. Mock-Implementierungen unterschieben.

Entitäten-Interfaces
Einige Entitäten gibt es natürlich. Die müssen natürlich die Persistenz und die DAOs kennen. Soll hier vor jede Entität ein Interface... wohl kaum. Hm Sekunde. In meinen Entitäten stehen ja Annotationen von JPA so was wie @Entity, @Column, @Id. Somit entscheide ich mich bei der Implementierung der Entitäten ja für die Persistenz-Technologie. Was ist wenn ich doch auf JDO wechseln will. Wenn ich die Entitäten hinter einem Interface verstecke, dann kann ich jederzeit andere Implementierungen hinterlegen. z.B. Auch Lösungen für Caching wenn ich die Referenzen entlang laufe usw. Vielleicht doch keine schlechte Idee interfaces vor die Entitäten zu machen?

Service-Interfaces
Die Gui sollte doch nicht direkt mit den DAOs sprechen oder? Die Daos können doch nicht so viel. Vielleicht gerade mal CRUD für die jeweilige Entität. Vielleicht gibt es ja Geschäftsregeln auf die geachtet werden sollen. Die sollten weder in die Gui noch in die Persistenz.
In die Fassaden?
Nun ja. Die sollten doch eigentlich hauptsächlich nur Delegieren.
Also führen wir noch eine Schicht zwischen Fassaden und DAOs ein. Ich nenne sie mal Service-Schicht. Da kommt nun die Hard-Core Geschäftslogik hin. Da kann es also nun sowas wie eine XyzVerwaltung usw. geben.
Wie sieht es jetzt mit einer IXyzVerwaltung aus?
Diese XyzVerwaltungen sind doch so was wie Geschäftskomponenten und sind immer auf eine bestimmte Geschäftslogik spezialisiert. Tausch man die mal aus?
Hm... vielleicht mal durch bessere, Ressourcen schonendere Implementierungen?
Im Team ist das vielleicht doch nicht so schlecht. So kann man wieder Mocks einführen und muss nicht immer mit der gesamten Anwendung testen...

Also gut... hm... nun ja... jetzt haben wir schön langsam für so gut wie alles ein Interface gemacht. Ist das nicht etwas viel? Wenn ich jetzt eine neue Methode irgendwo hinzufüge muss ich somit immer auch im Interface etwas ändern. Das ist doch ein Mehraufwand bei der eh schon so teuren Wartung. Ich kann aber natürlich auch Implementierungen schnell austauschen und verringere somit die Wartungskosten.

Eure Meinung
Was meint ihr so dieser Thematik. Wieviele Interfaces sind genug? Braucht es wirklich vor jeder Entität die gespeichert wird noch ein Interface? Blähen die Interfaces nicht nur den Source-Code unnötig auf? Verbraucht man nicht viel zu viel Zeit bei der Implementierung wegen den ganzen Interfaces? Sind Projekte die von Anfang an darauf achten alles hinter Interfaces zu verstecken und somit viele Interfaces haben agiler oder vielleicht sogar weniger agil als andere? Stört das nicht beim Implementieren alles? Ist das nicht gerade wichtig, wenn man in einem Team implementiert? Ist das mit den Interfaces nicht eh der falsche Weg zur Erlösung?

Würd mich freuen wenn ich mit diesem Artikel eine rege Diskussion provoziere.

Schöne Grüße,
Sebastian K.