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

Ich habe keine schöne Antwort auf Ihre Frage. API-Design ist eine Kunst für sich. Wenn Sie sich mitten in einem großen Entwurfsprojekt befinden, empfehle ich Ihnen, sich ein Exemplar von Praktischer API-Entwurf von Jaroslav Tulach, der durch NetBeans bekannt wurde.

Ich denke, er würde von zu vielen Methoden abraten, von denen einige vielleicht nur Hilfsmethoden sind. Sie sollten nur das Minimum offenlegen, das für die Arbeit mit der API erforderlich ist. Je weniger ausführlich, desto besser.

Answer 2

Die Anzahl der Methoden in einer Schnittstelle sollte nur durch die bekannte (oder erwartete) Verwendung bestimmt werden. Wenn Aufrufer typischerweise drei verschiedene (aber sich überschneidende) Mitglieder der sechs Mitglieder einer Schnittstelle verwenden, dann sind es eben sechs!

Eine große Anzahl von Methoden deutet oft auf eine schlechte Kohäsion hin, und ein gutes Objektdesign sollte dieser Anzahl ohnehin eine natürliche Grenze setzen. Sie sollten jedoch niemals eine Schnittstelle aufteilen, nur um die Anzahl der darin enthaltenen Methoden zu verringern.