Zastąpić warunkowo polimorfizmem w odpowiedni sposób?

Rozważ dwie klasy Dogi Catobie zgodne z Animalprotokołem (pod względem języka programowania Swift. Byłby to interfejs w Javie / C #).

Mamy ekran wyświetlający mieszaną listę psów i kotów. Istnieje Interactorklasa, która obsługuje logikę za kulisami.

Teraz chcemy przedstawić użytkownikowi powiadomienie o potwierdzeniu, gdy chce usunąć kota. Psy należy jednak natychmiast usunąć bez żadnych powiadomień. Metoda z warunkami warunkowymi wyglądałaby następująco:

func tryToDeleteModel(model: Animal) {
    if let model = model as? Cat {
        tellSceneToShowConfirmationAlert()
    } else if let model = model as? Dog {
        deleteModel(model: model)
    }
}

Jak można refaktoryzować ten kod? To oczywiście pachnie

Pozwalasz samemu typowi protokołu określać zachowanie. Chcesz traktować wszystkie protokoły tak samo w całym programie, z wyjątkiem samej klasy implementującej. Robi to w ten sposób przestrzega Liskov za Zmiana zasadę, która mówi, że powinieneś być w stanie przejść albo Catalbo Dog(lub jakichkolwiek innych protokołów można w końcu mieć pod Animalpotencjalnie) i mają działać obojętnie.

Przypuszczalnie dodajesz isCriticalfunc, który Animalma być zaimplementowany zarówno przez, jak Dogi przez Cat. Cokolwiek implementujące Dogzwróci fałsz, a cokolwiek implementujące Catzwróci prawdę.

W tym momencie musisz tylko zrobić (przepraszam, jeśli składnia jest nieprawidłowa. Nie jest użytkownikiem Swift):

func tryToDeleteModel(model: Animal) {
    if model.isCritical() {
        tellSceneToShowConfirmationAlert()
    } else {
        deleteModel(model: model)
    }
}

Jest z tym tylko niewielki problem, i to jest to, Dogi Catsą to protokoły, co oznacza, że ​​same w sobie nie określają, co isCriticalzwraca, pozostawiając to każdej klasie implementującej, która sama decyduje. Jeśli masz wiele implementacji, prawdopodobnie warto poświęcić trochę czasu na utworzenie rozszerzalnej klasy Catlub Dogktóra już poprawnie implementuje isCriticali skutecznie usuwa wszystkie klasy implementujące z konieczności zastąpienia isCritical.

Jeśli to nie odpowiada na twoje pytanie, napisz w komentarzach, a odpowiednio poszerzę swoją odpowiedź!

Tell vs. Ask

Podejście warunkowe, które pokazujemy, nazwalibyśmy „ zapytać ”. W tym miejscu klient konsumujący pyta „jaki jesteś?” i odpowiednio dostosowuje ich zachowanie i interakcję z obiektami.

Kontrastuje to z alternatywą, którą nazywamy „ powiedz ”. Korzystając z tell , wkładasz więcej pracy w polimorficzne implementacje, dzięki czemu kod klienta jest prostszy, bez warunków i wspólny, niezależnie od możliwych implementacji.

Ponieważ chcesz użyć alertu potwierdzającego, możesz uczynić to jawną funkcją interfejsu. Tak więc możesz mieć metodę logiczną, która opcjonalnie sprawdza u użytkownika i zwraca wartość logiczną potwierdzenia. W klasach, które nie chcą potwierdzić, po prostu zastępują return true;. Inne implementacje mogą dynamicznie określać, czy chcą użyć potwierdzenia.

Klient używający zawsze używałby metody potwierdzenia, niezależnie od konkretnej podklasy, z którą współpracuje, co powoduje, że interakcja mówi zamiast pytać .

(Innym podejściem byłoby przesunięcie potwierdzenia do usunięcia, ale zaskoczyłoby to konsumentów, którzy oczekują, że operacja usunięcia powiedzie się.)

Określenie, czy konieczne jest potwierdzenie, jest obowiązkiem Catklasy, więc pozwól jej wykonać tę akcję. Nie znam Kotlina, więc wyrażę rzeczy w języku C #. Mamy nadzieję, że pomysły te zostaną następnie przekazane Kotlinowi.

interface Animal
{
    bool IsOkToDelete();
}

class Cat : Animal
{
    private readonly Func<bool> _confirmation;

    public Cat (Func<bool> confirmation) => _confirmation = confirmation;

    public bool IsOkToDelete() => _confirmation();
}

class Dog : Animal
{
    public bool IsOkToDelete() => true;
}

Następnie, tworząc Catinstancję, dostarczasz ją TellSceneToShowConfirmationAlert, która będzie musiała wrócić, truejeśli OK, aby usunąć:

var model = new Cat(TellSceneToShowConfirmationAlert);

A potem twoja funkcja staje się:

void TryToDeleteModel(Animal model) 
{
    if (model.IsOKToDelete())
    {
        DeleteModel(model)
    }
}

Radziłbym wybrać wzór dla odwiedzających. Zrobiłem małą implementację w Javie. Nie znam Swift, ale możesz go łatwo dostosować.

Gość

public interface AnimalVisitor<R>{
    R visitCat();
    R visitDog();
}

Twój model

abstract class Animal { // can also be an interface like VisitableAnimal
    abstract <R> R accept(AnimalVisitor<R> visitor);
}

class Cat extends Animal {
    public <R> R accept(AnimalVisitor<R> visitor) {
         return visitor.visitCat();
     }
}

class Dog extends Animal {
    public <R> R accept(AnimalVisitor<R> visitor) {
         return visitor.visitDog();
     }
}

Dzwonię do gościa

public void tryToDelete(Animal animal) {
    animal.accept( new AnimalVisitor<Void>() {
        public Void visitCat() {
            tellSceneToShowConfirmation();
            return null;
        }

        public Void visitDog() {
            deleteModel(animal);
            return null;
        }
    });
}

Możesz mieć tyle implementacji AnimalVisitor, ile chcesz.

Przykład:

public void isColorValid(Color color) {
    animal.accept( new AnimalVisitor<Boolean>() {
        public Boolean visitCat() {
            return Color.BLUE.equals(color);
        }

        public Boolean visitDog() {
            return true;
        }
    });
}