Mateusz Wajnberger
Interface Segregation Principle
Zasada mówi, że nie powinno tworzyć się interfejsów z metodami, które nie będą wykorzystywane przez poszczególne klasy. Powinno się je tworzyć w ten sposób, aby miały jedną odpowiedzialność (Single Responsibility Principle). Nie można zmuszać klas implementujących interfejs, aby implementowały funkcjonalności, których nie potrzebują.
Przykład
Żeby lepiej zobrazować daną zasadę przyjmiemy, że mamy do dyspozycji jeden interfejs z kilkoma metodami. Jako przykład sportowca weźmiemy Pawła Korzeniowskiego, wielokrotnego olimpijczyka w pływaniu.
public interface Athlete {
void compete();
void swim();
void run();
}
public class PawełKorzeniowski implements Athlete {
@Override
public void compete() {
System.out.println("Paweł Korzeniowski started competing");
}
@Override
public void swim() {
System.out.println("Paweł Korzeniowski started swimming");
}
@Override
public void run() {
}
}
Zastosowanie Interface Segregation Principle
W powyższym przykładzie widzimy, że implementując interfejs „Athlete”, jesteśmy zmuszeni do zaimportowania metody „run”, która w danym przypadku nie jest nam kompletnie potrzebna (nie mamy do czynienia z daną dyscypliną sportu). Stosując omawianą w tym artykule zasadę, powinniśmy rozdzielić jeden interfejs z kilkoma metodami, na kilka mniejszych interfejsów. W ten sposób nie będziemy zmuszeni do implementacji funkcjonalności, których nie potrzebujemy.
public interface Athlete {
void compete();
}
public interface SwimmingAthlete extends Athlete {
void swim();
}
public interface RunningAthlete extends Athlete {
void run();
}
public class PawełKorzeniowski implements SwimmingAthlete {
@Override
public void compete() {
System.out.println("Paweł Korzeniowski started competing");
}
@Override
public void swim() {
System.out.println("Paweł Korzeniowski started swimming");
}
}