Interface Segregation Principle

Wyobraźmy sobie, że korzystamy z aplikacji restauracji, gdzie mamy możliwość wybrania różnych metod złożenia zamówienia – możemy przyjść osobiście, wypełniając formularz w aplikacji lub zadzwonić pod podany numer telefonu.

Teraz, za pomocą fragmentu uproszczonej wersji takiej aplikacji, zaprezentuję jak można złamać powyższą zasadę SOLID:

public interface AcceptAnOrder {
    public String acceptOrderOnline();
    public String acceptOrderInPerson();
    public String acceptOrderOnThePhone();
}

public class OnlineOrder implements AcceptAnOrder{
    public String acceptOrderOnline(){
        return "Your order accepted.";
    }

    public String acceptOrderInPerson(){
        throw new UnsupportedOperationException();
    }

    public String acceptOrderOnThePhone(){
        throw new UnsupportedOperationException();
    }
}

Mamy tutaj taki problem, że w klasie OnlineOrder nie odwołuję się jedynie do metody związaej tylko z zamówieniami online, ale skoro w interfejsie mamy też inne metody, to powinny byc równiez zaimplementowane. Niestety tutaj pojawia się błąd i konflikt, bo nie są one związane z zamówieniami online.

Poniżej prezentuję jak zmodyfikować ten kod, żeby tym razem był zgodny z przedstawioną zasadą:

Zmieniony interfejs:

public interface AcceptAnOrder {
    public String acceptOrder();
}

public class InPersonOrder implements AcceptAnOrder{
    @Override
    public String acceptOrder() {
        return "Your in-store order has been accepted.";
    }
}

public class OnlineOrder implements AcceptAnOrder{
    public String acceptOrder(){
        return "Your online order accepted.";
    }
}

public class OnThePhoneOrder implements AcceptAnOrder{
    public String acceptOrder(){
        return "Your on the phone order accepted.";
    }
}

Teraz każda klasa obsługuje wyłącznie metodę związaną ze swoim rodzajem zamóweinia.