Interface Segregation in der Praxis

Interface Segregation in der Praxis

Jürgen Lampe


Ein Interface hilft, Implementierungsdetails einer aufgerufenen Methode, dem Service, vor der rufenden Klasse, dem Client, zu verbergen. Ein Interface ist eine interne Schnittstelle, durch deren Benutzung Systeme mit weniger fest gekoppelten Elementen gebaut werden können. Es reicht jedoch nicht, nur irgendwelche Schnittstellen zu definieren. Der Kerngedanke des ISPs (Kasten: „SOLID“) besagt, dass jedes Interface aus eng zusammenhängenden Elementen bestehen soll. Im Gegensatz dazu stehen umfangreiche „fat“ Interfaces, die logisch nicht zusammenhängende Funktionen enthalten, d. h. wenig kohäsiv sind, und dadurch unnötige Kopplungen verursachen.

Umfangreiche Interfaces erhöhen überdies die Gefahr, dass in den implementierenden Klassen das „Don’t Repeat Yourself“-Prinzip (DRY) verletzt wird, weil beispielsweise der Code für eine Methode aus einer anderen Implementierung einfach kopiert wird.

Nicht zu unterschätzen ist der Gewinn, den kleine Interfaces beim Unit Test bringen. Weniger Methoden haben weniger mögliche Interaktionen und erfordern damit weniger Testfälle. Gleichermaßen vereinfacht sich das Anlegen von Mock-Objekten.

SOLIDMit der Abkürzung SOLID wird eine Gruppe von fünf wichtigen Prinzipien der objektorientierten Programmierung beschrieben. Kurz gefasst lauten sie:Single Responsibility Principle (SRP): Eine Klasse sollte genau eine Aufgabe lösen.Open Close Principle (OCP): Funktionserweiterungen sollten nur durch Vererbung, nicht durch Codemodifika­tion erfolgen.Liskov Substitution Principle (LSP): Unterklassen dürfen die Kontrakte ihrer Basisklassen nicht verletzen.Interface Segregation Principle (ISP): Interfaces sollten kompakt und kohäsiv sein.Dependency Inversion Principle: Abhängigkeiten sollten immer von detaillierteren (niedrigeren) Klassen zu abstrakteren (höheren) gerichtet sein.Die Zusammenstellung dieser Regeln geht auf Robert Martins Buch „Agile Software Development: Principles, Patterns and Practices“ [1] zurück. Es gibt weitere Regeln, die sich teilweise untereinander und mit den SOLID-Prinzipien überschneiden. Wie alle Regeln sollten auch diese nicht blind befolgt, sondern mit Augenmaß und Überlegung angewendet werden.

Interfacedesign

Wie sollte ein gutes Interface aussehen? Der wichtigste Punkt wurde schon genannt: Die Methoden eines Interface sollten inhaltlich und funktional zusammengehören. Dass alle Bezeichner sprechend und treffend zu wählen sind, sollte selbstverständlich sein. Da dies aber nicht oft genug wiederholt werden kan...

Interface Segregation in der Praxis

Interface Segregation in der Praxis

Jürgen Lampe


Ein Interface hilft, Implementierungsdetails einer aufgerufenen Methode, dem Service, vor der rufenden Klasse, dem Client, zu verbergen. Ein Interface ist eine interne Schnittstelle, durch deren Benutzung Systeme mit weniger fest gekoppelten Elementen gebaut werden können. Es reicht jedoch nicht, nur irgendwelche Schnittstellen zu definieren. Der Kerngedanke des ISPs (Kasten: „SOLID“) besagt, dass jedes Interface aus eng zusammenhängenden Elementen bestehen soll. Im Gegensatz dazu stehen umfangreiche „fat“ Interfaces, die logisch nicht zusammenhängende Funktionen enthalten, d. h. wenig kohäsiv sind, und dadurch unnötige Kopplungen verursachen.

Umfangreiche Interfaces erhöhen überdies die Gefahr, dass in den implementierenden Klassen das „Don’t Repeat Yourself“-Prinzip (DRY) verletzt wird, weil beispielsweise der Code für eine Methode aus einer anderen Implementierung einfach kopiert wird.

Nicht zu unterschätzen ist der Gewinn, den kleine Interfaces beim Unit Test bringen. Weniger Methoden haben weniger mögliche Interaktionen und erfordern damit weniger Testfälle. Gleichermaßen vereinfacht sich das Anlegen von Mock-Objekten.

SOLIDMit der Abkürzung SOLID wird eine Gruppe von fünf wichtigen Prinzipien der objektorientierten Programmierung beschrieben. Kurz gefasst lauten sie:Single Responsibility Principle (SRP): Eine Klasse sollte genau eine Aufgabe lösen.Open Close Principle (OCP): Funktionserweiterungen sollten nur durch Vererbung, nicht durch Codemodifika­tion erfolgen.Liskov Substitution Principle (LSP): Unterklassen dürfen die Kontrakte ihrer Basisklassen nicht verletzen.Interface Segregation Principle (ISP): Interfaces sollten kompakt und kohäsiv sein.Dependency Inversion Principle: Abhängigkeiten sollten immer von detaillierteren (niedrigeren) Klassen zu abstrakteren (höheren) gerichtet sein.Die Zusammenstellung dieser Regeln geht auf Robert Martins Buch „Agile Software Development: Principles, Patterns and Practices“ [1] zurück. Es gibt weitere Regeln, die sich teilweise untereinander und mit den SOLID-Prinzipien überschneiden. Wie alle Regeln sollten auch diese nicht blind befolgt, sondern mit Augenmaß und Überlegung angewendet werden.

Interfacedesign

Wie sollte ein gutes Interface aussehen? Der wichtigste Punkt wurde schon genannt: Die Methoden eines Interface sollten inhaltlich und funktional zusammengehören. Dass alle Bezeichner sprechend und treffend zu wählen sind, sollte selbstverständlich sein. Da dies aber nicht oft genug wiederholt werden kan...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang