Der richtige Grad an Schnittstellengranularität

Question

Ich arbeite zur Zeit an einem API-Design, das die Spezifikation einer Reihe von Schnittstellen als Abstraktionen beinhaltet, die später von verschiedenen konkreten Klassen implementiert werden sollen.

Zufälligerweise verwende ich Java, aber ich denke, die Frage ist für jede Sprache relevant, die ein ähnliches Schnittstellenkonzept unterstützt.

Ich habe festgestellt, dass es oft eine Option dazwischen gibt:

• Erstellung einer großen Schnittstelle mit einer Vielzahl von Methoden
• Erstellung mehrerer Schnittstellen, die jeweils eine Teilmenge der gesamten Methodenpalette enthalten (eine einzige konkrete Klasse müsste wahrscheinlich mehrere oder alle dieser Schnittstellen implementieren)

Was sind die Vor- und Nachteile der einzelnen Ansätze?

Answer 1

Der Vorteil der Aufteilung der Schnittstelle besteht darin, dass Sie die Methoden in Gruppen von Aufgaben unterteilen können, die sinnvollerweise zusammengehören. Der Nachteil ist, dass Ihre Schnittstelle jetzt in eine Reihe kleinerer Methoden aufgeteilt ist, die von einer Klasse implementiert werden könnten.

Ich würde empfehlen, die Schnittstelle dort aufzuteilen, wo es der Lesbarkeit dient, und nicht weiter. Wenn Sie eine Klasse haben, die 10 Schnittstellen implementiert, müssen entweder diese Schnittstellen zu einer zusammengefasst werden, oder die Klasse übernimmt zu viel Verantwortung und es müssen wirklich zwei oder mehr Klassen sein.

Answer 2

In Bezug auf Anti-Muster würde ich sagen, dass zu viele Schnittstellen zu dem so genannten Jo-Jo-Problem führen können:

http://en.wikipedia.org/wiki/Yo-yo_problem

Und wenn man alles in eine einzige Schnittstelle packt, entsteht vielleicht das Objekt Gott:

http://en.wikipedia.org/wiki/God_object

Sie sollten Ihren Platz irgendwo dazwischen finden :)

Viel Glück!

Answer 3

Ein Punkt, der noch nicht erwähnt wurde: Schnittstellen, die Elemente in eine Sammlung aufnehmen, sollten von denen, die Elemente herausnehmen, getrennt sein; eine kombinierte Schnittstelle sollte von beiden erben. Die Trennung der Schnittstellen auf diese Weise ermöglicht Kovarianz und Kontravarianz. Zum Beispiel kann ein ReadableBunch(Of ToyotaPrius) sicher an eine Routine übergeben werden, die ein ReadableBunch(Of Car) erwartet [da ein Objekt, das Instanzen von ToyotaPrius ausgibt, dabei auch Instanzen von Car ausgibt], und eine WritableQueue(Of Car) kann sicher an eine Routine übergeben werden, die eine WriteableQueue(Of HondaCivic) erwartet [da ein Objekt, das ein Car akzeptieren kann, per Definition auch ein HondaCivic akzeptiert].

Ich weiß nicht, ob diese Art von Kovarianz und Kontravarianz in Java etwas bedeuten, aber da die Frage als sprachunabhängig gekennzeichnet wurde, sollte das Problem von jedem berücksichtigt werden, der für Plattformen programmiert, die Kovarianz und Kontravarianz unterstützen (z. B. .net)

Answer 4

Ich würde nicht für eine Schnittstelle mit zu vielen Methoden plädieren, wie ich es auch nicht für eine Klasse tun würde. Der Programmierer, der solche Schnittstellen oder die abgeleiteten Klassen verwenden muss, hätte Schwierigkeiten zu verstehen, wie sie zusammenhängen; außerdem ist der Versuch, sich zu merken, was sie sind und wann sie zu verwenden sind, wie das Jonglieren mit zu vielen Bällen.

Für mich sind im Allgemeinen mehr als 1000 Zeilen in einem Modul zu viel; auch mehr als 100 Zeilen in einer Methode; auch mehr als 15 Methoden oder so in einer Klasse oder Schnittstelle. Es kann natürlich Ausnahmen geben, aber ich versuche, sie zu vermeiden.

Ich würde definieren, welche Schnittstellen Sie haben, bevor Sie darüber nachdenken, welche Methoden in sie hineingehen. Überlegen Sie, was die "atomaren Verhaltensweisen" für jede abstrakte Entität in Ihrem System sind, und machen Sie aus jeder Entität eine Schnittstelle, die Sie bei Bedarf durch Vererbung zusammensetzen. Dann entscheiden Sie über die Methoden - danach wird es wahrscheinlich nicht mehr viele in jeder Schnittstelle geben.

Answer 5

Erstellung mehrerer Schnittstellen, die jeweils eine Teilmenge der gesamten Methodenpalette enthalten

Dieser Ansatz würde eher mit dem Gestaltungsprinzip der " Komposition der Vererbung vorziehen ", da verschiedene Klassen jeweils eine (oder mehrere) der Schnittstellen implementieren können.