Sign up to save your podcasts
Or
Share Interface Segregation Principle (ISP) – Wissenshäppchen #6
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Interface Segregation Principle (ISP) – Wissenshäppchen #6
Das sechste Wissenshäppchen hat das Interface Segregation Principle als Thema.
Inhalt
Das ISP ist das vierte SOLID-Prinzip.
The dependency of one class to another one should depend on the smallest possible interface.
Im Prinzip kann man das ISP so zusammenfassen: Verwende immer nur die kleinstmögliche Schnittstelle zu deinen Abhängigkeiten. Je mehr Funktionen eine Komponente an ihren Abhängigkeiten aufrufen kann, desto abhängiger wird sie von ihr. Wenn sich diese Funktionen nämlich ändern (z.B. die Signatur einer Methode), muss die nutzende Komponente neu kompiliert werden. Außerdem können Funktionen aufgerufen werden, die die nutzende Komponente weder benötigt, noch anwenden soll, z.B. die clear()-Methode einer Liste, die sie eigentlich nur durchlaufen soll. Zuletzt müssen auch implementierende Klassen von zu großen Interfaces für sie unnötige Methoden implementieren, nur um der Schnittstelle zu entsprechen.
Erklärung
Beispiel
Die Methode printEmployees() im folgenden Beispiel erwartet eine List, obwohl sie diese lediglich durchlaufen können muss. Durch das „zu große“ Interface kann sie darüber hinaus jetzt auch die Liste leeren, was für den Aufrufer unschöne Konsequenzen hat.
public class ISP
{
public static void main(String[] args)
{
List employees = new ArrayList<>();
employees.add(new Employee("Stefan", "Macke"));
employees.add(new Employee("Karl", "Meier"));
employees.add(new Employee("Hans", "Georg"));
printEmployees(employees);
System.out.println(employees.size());
}
private static void printEmployees(List employees)
{
for (var employee : employees)
{
System.out.println(employee);
}
employees.clear();
}
}
// Ausgabe:
// Stefan Macke
// Karl Meier
// Hans Georg
// 0
Die Methode sollte stattdessen das kleinstmögliche Interface benutzen, das sie braucht, um ihre Aufgabe erfüllen zu können. In Java wäre das z.B. ´Iterable´:
private static void printEmployees(Iterable employees)
{
for (var employee : employees)
{
System.out.println(employee);
}
}
Der restliche Code funktioniert wie vorher, aber es sind nun keine modifizierenden Aufrufe mehr möglich, da das kleinere Interface die Methoden nicht anbietet.
Dynamisch typisierte Sprachen haben hier einen Vorteil, da sie dank Duck-Typing ohnehin kaum Basisklassen oder gar Interfaces benötigen. Sie rufen einfach nur die Methoden auf, die sie brauchen. Das kann allerdings auch zu impliziten Abhängigkeiten führen, die nicht vom Compiler geprüft werden, da der Zugriff auf die Klasse nicht durch ein Interface „geschützt“ ist.
Vorteile
Nachteile
Literaturempfehlungen
Es wird schon langweilig: Auch beim vierten SOLID-Prinzip empfehle ich wieder Uncle Bobs Clean Code*.
*
Links
View all episodes
By Stefan Macke
5
11 ratings
Das sechste Wissenshäppchen hat das Interface Segregation Principle als Thema.
Inhalt
Das ISP ist das vierte SOLID-Prinzip.
The dependency of one class to another one should depend on the smallest possible interface.
Im Prinzip kann man das ISP so zusammenfassen: Verwende immer nur die kleinstmögliche Schnittstelle zu deinen Abhängigkeiten. Je mehr Funktionen eine Komponente an ihren Abhängigkeiten aufrufen kann, desto abhängiger wird sie von ihr. Wenn sich diese Funktionen nämlich ändern (z.B. die Signatur einer Methode), muss die nutzende Komponente neu kompiliert werden. Außerdem können Funktionen aufgerufen werden, die die nutzende Komponente weder benötigt, noch anwenden soll, z.B. die clear()-Methode einer Liste, die sie eigentlich nur durchlaufen soll. Zuletzt müssen auch implementierende Klassen von zu großen Interfaces für sie unnötige Methoden implementieren, nur um der Schnittstelle zu entsprechen.
Erklärung
Beispiel
Die Methode printEmployees() im folgenden Beispiel erwartet eine List, obwohl sie diese lediglich durchlaufen können muss. Durch das „zu große“ Interface kann sie darüber hinaus jetzt auch die Liste leeren, was für den Aufrufer unschöne Konsequenzen hat.
public class ISP
{
public static void main(String[] args)
{
List employees = new ArrayList<>();
employees.add(new Employee("Stefan", "Macke"));
employees.add(new Employee("Karl", "Meier"));
employees.add(new Employee("Hans", "Georg"));
printEmployees(employees);
System.out.println(employees.size());
}
private static void printEmployees(List employees)
{
for (var employee : employees)
{
System.out.println(employee);
}
employees.clear();
}
}
// Ausgabe:
// Stefan Macke
// Karl Meier
// Hans Georg
// 0
Die Methode sollte stattdessen das kleinstmögliche Interface benutzen, das sie braucht, um ihre Aufgabe erfüllen zu können. In Java wäre das z.B. ´Iterable´:
private static void printEmployees(Iterable employees)
{
for (var employee : employees)
{
System.out.println(employee);
}
}
Der restliche Code funktioniert wie vorher, aber es sind nun keine modifizierenden Aufrufe mehr möglich, da das kleinere Interface die Methoden nicht anbietet.
Dynamisch typisierte Sprachen haben hier einen Vorteil, da sie dank Duck-Typing ohnehin kaum Basisklassen oder gar Interfaces benötigen. Sie rufen einfach nur die Methoden auf, die sie brauchen. Das kann allerdings auch zu impliziten Abhängigkeiten führen, die nicht vom Compiler geprüft werden, da der Zugriff auf die Klasse nicht durch ein Interface „geschützt“ ist.
Vorteile
Nachteile
Literaturempfehlungen
Es wird schon langweilig: Auch beim vierten SOLID-Prinzip empfehle ich wieder Uncle Bobs Clean Code*.
*
Links
More shows like IT-Berufe-Podcast
View all
Streitkräfte und Strategien
45 Listeners
Sternengeschichten
45 Listeners
Geschichten aus der Geschichte
196 Listeners
c’t uplink - der IT-Podcast aus Nerdistan
6 Listeners
MORD AUF EX
128 Listeners
{ungeskriptet} - Gespräche, die dich weiter bringen
23 Listeners