Die SOLID-Prinzipien zielen darauf ab, objektorientierte Software langfristig wartbarer zu machen. In meinem Blog widme ich jedem der fünf Prinzipien einen eigenen Beitrag.
- Single Responsibility Principle
- Open-Closed Principle
- Liskov-Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
Das Interface Segregation Principle (ISP) ist ein Entwurfsprinzip von Robert C. Martin. Es bildet zusammen mit vier anderen Prinzipien das Akronym SOLID und steht für dessen vierten Buchstaben. Es hat folgende Aussage:
Clients should not be forced to depend upon interfaces that they do not use.
Robert C. Martin
Beziehung zu anderen SOLID-Prinzipien
Das ISP ist eng mit dem Single Responsibility Principle (SRP) verwandt. Auf die gleiche Weise wie das SRP für Klassen gilt, gilt das ISP für Interfaces. Das SRP besagt, dass eine Klasse nur einen Grund haben sollte, sich zu ändern. Anders ausgedrückt sollte eine Klasse genau eine Verantwortlichkeit haben. Damit das SRP für eine Klasse, die ein Interface implementiert, eingehalten werden kann, muss das Interface auch das ISP einhalten.
Das ISP hat auch im entfernteren Sinne eine Beziehung zum Liskov Substitution Principle (LSP). Das LSP besagt unter anderem, dass die Nachbedingungen und Invarianten nach dem Aufruf einer Methode beibehalten werden müssen. Ist ein Interface sehr groß und verstößt gegen das ISP, erhöht sich auch die Wahrscheinlichkeit, dass diese beiden Aspekte des LSP verletzt werden.
Kohäsion
Ein ISP-konformes Interface sollte kohäsiv sein. Kohäsion in der Informatik beschreibt, wie gut eine Programmeinheit eine logische Einheit abbildet. Bildet ein Interface eine logische Einheit gut ab, so werden implementierende Klassen auch alle Methoden des Interfaces umsetzen. Das bedeutet aber nicht, dass eine Klasse auf die Methoden eines Interfaces reduziert werden muss. Eine Klasse kann als Einheit auch mehrere ISP-konforme Interfaces implementieren. Dazu ein interessantes Zitat von Robert C. Martin:
The ISP acknowledges that there are objects that require non-cohesive interfaces; however it suggests that clients should not know about them as a single class.
RoleInterface, Fat Interface und Interface Pollution
Martin Fowler hat für Interfaces, die genau einen Zwecke verfolgen, den Begriff RoleInterface eingeführt.
Der Name eines Interfaces sollte mit Bedacht gewählt werden und angemessen spezifisch sein. Nehmen wir als Beispiel ein Interface Bird mit einer Methode fly(). Das Interface ist mit nur einer Methode sehr schlank, aber früher oder später stolpern wir über das Problem, dass nicht jeder Vogel fliegen kann. Ein besserer Name für das Interface ist Flyable. Dieser Name kommuniziert sehr gut die Rolle des Interfaces.
Beim Namen Bird hingegen ist erstmal nicht ersichtlich, was überhaupt einen Vogel ausmacht. Kann er fliegen? Hat er Federn? Legt er Eier? Und warum sollte man diese drei völlig unterschiedlichen Attribute in einem gemeinsamen Interface definieren, wenn es auch andere Lebewesen gibt, die fliegen können, Federn haben oder Eier legen?
Hat ein Interface zu viele Methoden (und ist damit inkohärent), spricht man von einem Fat Interface. Fat Interfaces führen früher oder später dazu, dass eine implementierende Klasse nicht alle ihre Methoden implementieren möchte. Ist dies passiert, so spricht man von Interface Pollution.
Fat Interfaces und Interface Pollution können auch nachträglich entstehen, wenn eine Software weiter wächst und neue Methoden an bestehenden Interfaces ergänzt werden. Es ist essentiell, sich bei der Weiterentwicklung und Pflege einer Software gut zu überlegen, wie Erweiterungen in das bestehende Modell integriert werden sollen, damit es später nicht zu Interface Pollution kommt.
- Beitrag zum ISP von Robert C. Martin - Blogbeitrag zum RoleInterface von Martin Fowler