Est-ce que ActivityMapper de GWT violent le principe de substitution Liskov?

Question

Dans ma demande GWT, j'ai une classe comme ceci:

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

Les objets ActivityMapper, l'activité et place font partie du cadre, et l'interface implique que c'est la façon dont il a été conçu pour être utilisé.

Cependant, selon le Liskov principe de substitution , un procédé qui accepte un type, mais effectue une vérification de type pour les sous-classes de déduire des mesures à prendre est une violation du principe.

L'interface ActivityMapper Is GWT, par nature, en encourageant une violation du LSP? Ou est-il un autre moyen LSP conforme au code cette méthode que je ne l'ai pas pensé?

Answer 1

Le rôle du ActivityMapper est de mapper un Place à un Activity, où les règles de cartographie sont laissés entièrement libres.
Ce qui fait ce genre de if / else cascade est que Java ne supporte pas les multiples expédition , mais à mon avis, cela ne signifie pas qu'il ne respecte pas le LSP (ou au moins, eh bien, vous avez pas d'autre choix en Java, il est donc pas un problème, vous pouvez utiliser un modèle de visiteur -c'est ce que Spring Roo generates- mais doesn « t changent les choses beaucoup).