0

教会/モスク/シナゴーグなどで礼拝する私たち。オブジェクト指向設計の多くは、instanceof. 私の質問は、別の開発者に、予想される型の可変個の混合物を 1 つのエントリ ポイント関数 ( foo) に渡して、コードをより簡潔にする (別名ファサード):

   // a lightweight demo of the integral idea behind the Facade DP...

public void foo(Object... objs){

 for(Object o : objs){
        if(o instanceof Integer) bar((Integer)o); 
        else if(o instanceof MyCustomType) bar((MyCustomType)o); 
        else if(o instanceof String) bar((String)o);
        //else{...} ignore? report exception?
    }

}


private void bar(int i){
  System.out.println("integer overload invoked");

}

private void bar(String s){
  System.out.println("String overload invoked");

}

private void bar(MyCustomType instance){
  System.out.println("MyCustomType overload invoked");

}

はい、これは間違いなく少しばかげていますが、オブジェクトとして表示される以外に 3 つの型 (Integer、String、MyCustomType) 間にポリモーフィズムがないと仮定するinstanceofと、予想される型ごとに補助ラッパー オブジェクトを記述するのとは対照的に、使用するのは簡単ではありません。

private abstract class Wrapper<T>{

  abstract void meth(T t);
}

private class StringWrapper extends Wrapper<String>{

   @Override
   void meth(String s){

       System.out.println("String overload invoked");
   }
}


// etc...

これは OO の観点からは確かに優れた設計ですが、常にラッパー アプローチを使用する必要がありますか?

それとも、効率やメモリの点で、このアプローチにマイナス面があるのでしょうか? の使用はinstanceofFacade によって隠されているいくつかのメソッドの呼び出しに限定されているため、このスタイルを推奨することさえできますか? 結局のところ、このシナリオでは、純粋に親クラスのスコープがあるため、ラッパー クラスの再利用スコープは制限されています。

この特定のコンテキストでの両方のアプローチの長所と短所は何ですか?

4

0 に答える 0