Sostituire il condizionale con il polimorfismo in modo corretto?

Considera due classi Doged Catentrambe conformi al Animalprotocollo (in termini di linguaggio di programmazione Swift. Sarebbe un'interfaccia in Java / C #).

Abbiamo uno schermo che mostra un elenco misto di cani e gatti. C'è una Interactorclasse che gestisce la logica dietro le quinte.

Ora vogliamo presentare un avviso di conferma all'utente quando desidera eliminare un gatto. Tuttavia, i cani devono essere eliminati immediatamente senza alcun avviso. Il metodo con i condizionali sarebbe simile al seguente:

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

Come può essere refactored questo codice? Ovviamente odora

Stai lasciando che il tipo di protocollo stesso determini il comportamento. Volete trattare tutti i protocolli allo stesso modo in tutto il programma, tranne nella classe di implementazione stessa. Farlo in questo modo è rispettare il Principio di sostituzione di Liskov, che dice che dovresti essere in grado di passare uno Cato Dog(o qualsiasi altro protocollo che potresti eventualmente avere sotto Animalpotenzialmente), e farlo funzionare indifferentemente.

Quindi presumibilmente aggiungeresti una isCriticalfunzione Animalper essere implementata da entrambi Doge Cat. Qualsiasi implementazione Dogsarebbe restituita falsa e qualsiasi implementazione Catsarebbe vera.

A quel punto, dovrai solo fare (Le mie scuse se la sintassi non è corretta. Non un utente di Swift):

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

C'è solo un piccolo problema con questo, e cioè quello Doge Catsono i protocolli, nel senso che essi stessi non determinano ciò che isCriticalritorna, lasciando questo a ogni classe di implementazione di decidere autonomamente. Se hai molte implementazioni, probabilmente varrebbe la pena creare una classe estensibile Cato Dogche già implementa correttamente isCriticaled eliminare efficacemente tutte le classi di implementazione dalla necessità di scavalcare isCritical.

Se questo non risponde alla tua domanda, ti preghiamo di scrivere nei commenti e amplierò la mia risposta di conseguenza!

Tell vs. Ask

L'approccio condizionale che stai mostrando vorremmo chiamare " chiedi ". Qui è dove il cliente consumatore chiede "che tipo sei?" e personalizza di conseguenza il loro comportamento e l'interazione con gli oggetti.

Ciò contrasta con l'alternativa che chiamiamo " raccontare ". Usando tell , spingi più lavoro nelle implementazioni polimorfiche, in modo che il consumo del codice client sia più semplice, senza condizionali e comune indipendentemente dalle possibili implementazioni.

Dal momento che si desidera utilizzare un avviso di conferma, è possibile rendere esplicita questa funzionalità dell'interfaccia. Quindi, potresti avere un metodo booleano che controlla facoltativamente con l'utente e restituisce il valore booleano di conferma. Nelle classi che non vogliono confermare, hanno semplicemente la precedenza return true;. Altre implementazioni potrebbero determinare dinamicamente se vogliono usare la conferma.

Il cliente utilizzatore userebbe sempre il metodo di conferma indipendentemente dalla particolare sottoclasse con cui sta lavorando, il che fa sì che l'interazione dica invece di chiedere .

(Un altro approccio sarebbe quello di spingere la conferma nell'eliminazione, ma ciò sorprenderebbe i clienti consumatori che si aspettano che un'operazione di eliminazione abbia successo.)

Determinare se è necessaria una conferma è la responsabilità della Catclasse, quindi abilitala a compiere quell'azione. Non conosco Kotlin, quindi esprimerò le cose in C #. Spero che le idee siano poi trasferibili anche a Kotlin.

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;
}

Quindi, quando crei Catun'istanza, la fornisci TellSceneToShowConfirmationAlert, che dovrà essere restituita truese OK per eliminare:

var model = new Cat(TellSceneToShowConfirmationAlert);

E poi la tua funzione diventa:

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

Consiglierei di scegliere un modello Visitatore. Ho fatto una piccola implementazione in Java. Non ho familiarità con Swift, ma puoi adattarlo facilmente.

Il visitatore

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

Il tuo modello

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();
     }
}

Chiamare il visitatore

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

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

Puoi avere tutte le implementazioni di AnimalVisitor che desideri.

Esempio:

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

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