1

私の GWT アプリケーションには、次のようなクラスがあります。

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

ActivityMapper、Activity、および Place オブジェクトはフレームワークの一部であり、インターフェイスは、これが意図された使用方法であることを暗示しています。

ただし、Liskov Substitution Principleによると、型を受け入れるが、サブクラスの型チェックを行って、実行するアクションを推測するメソッドは、原則に違反しています。

GWT の ActivityMapper インターフェースは、本質的に LSP の違反を助長していますか? または、私が考えもしなかった方法をコーディングする別の LSP 準拠の方法はありますか?

4

1 に答える 1

1

の役割は、ActivityMapperをにマップするPlaceことActivityです。ここで、マッピングのルールは完全に自由になります。
そのようなif/elseカスケードを作るのは、Javaが多重ディスパッチをサポートしていないということですが、私の意見では、それがLSPに違反しているという意味ではありません（または、少なくとも、Javaで他の選択肢がないので、問題ではありません。訪問者パターンを使用できます。これはSpringRooが生成するものですが、それほど大きな変化はありません）。

于 2011-12-03T16:59:32.427 に答える