1
在我的GWT應用程序,我有一個類,像這樣:GWT的ActivityMapper是否違反了Liskov替換原則?
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,活動和地點對象是框架的一部分,接口意味着,這是它是怎樣來使用。
但是,根據Liskov Substitution Principle,一種方法接受一個類型但檢查子類來推斷要採取的操作違反了該原則。
GWT的ActivityMapper接口本質上是否鼓勵違反LSP?還是有另一種符合LSP標準的方法來編寫我沒有想到的方法?
更多閱讀,我想違反LSP取決於你是否可以通過與子類調用此方法來破壞客戶端。這似乎實際上是映射方法的意圖,因此在這種情況下,instanceof's的if/else級聯可能不會自動違反LSP。感謝提到訪問者模式...似乎有更多關於此方法的實現的討論[這裏](http://stackoverflow.com/questions/5802747/eliminating-gwt-activitymapper-boilerplate)。 – Jay