ActivityMapper di GWT viola il principio di sostituzione di Liskov?

Question

Nella mia applicazione GWT, ho una lezione come così:

public class AppActivityMapper implements ActivityMapper {

    @Override public Activity getActivity(Place place) {

        if(place instanceof ThisPlace) {
            return new ThisActivity((ThisPlace)place);
        }
        if(place instanceof ThatPlace) {
            return new ThatActivity((ThatPlace)place);
        }
        if(place instanceof AnotherPlace) {
            return new AnotherActivity((AnotherPlace)place);
        }
        // you get the idea
    }
}

Gli oggetti ActivityMapper, Activity e Place fanno parte del framework e l'interfaccia implica che è così che doveva essere utilizzato.

Tuttavia, secondo il Principio di sostituzione di Liskov, un metodo che accetta un tipo ma esegue un tipo di controllo per le sottoclassi per dedurre quale azione intraprendere è una violazione del principio.

L'interfaccia ActivityMapper di GWT sta per natura incoraggia una violazione dell'LSP? O esiste un altro modo conforme a LSP per codificare quel metodo a cui non ho pensato?

Answer 1

Il ruolo del ActivityMapper è mappare a Place ad Activity, dove le regole per la mappatura sono lasciate completamente libere.
Ciò che rende quel tipo di cascata If/Else è che Java non supporta spedizione multipla, ma secondo me non significa che stia violando l'LSP (o almeno, beh, non hai altra scelta in Java, quindi non è un problema; potresti usare un modello di visitatore-questo è ciò che Spring Roo genera-ma Ciò non cambia molte cose).