2

クラス階層が存在し、最上位の基本クラスが抽象クラスであるいくつかの場所では、抽象クラスに静的な getInstance() メソッドがあります。これは、正しいサブクラスを作成し、それを呼び出し元に返す責任があります。たとえば、以下のコードを考えてみましょう。

public class abstract Product {

   public static Product getInstance(String aCode) {
       if ("a".equals(aCode) {
          return new ProductA();
       }
       return ProductDefault();
   }
   // product behaviour methods
}

public class ProductA extends Product {}

public class ProductDefault extends Product {}

Java では、java.util.Calendar.getInstance() がこのパターンに従っている場所の 1 つです。ただし、これは、新しいサブクラスが導入されるたびに、基本クラスを変更する必要があることを意味します。つまり、上記の例では製品クラスを変更する必要があります。これはocpの原則に違反しているようです。また、基本クラスは、やはり疑わしいサブクラスの詳細を認識しています。

私の質問は...

  1. 上記のパターンはアンチパターンですか?
  2. 上記のパターンを使用することの欠点は何ですか?
  3. 代わりにどのような代替案に従うことができますか?
4

4 に答える 4

2

いいえ、ちがいます。factory method pattern http://en.wikipedia.org/wiki/Factory_method_patternのようなものです。例Calendar.getInstance();。JDK には、そのような例がたくさんあります。また、Effective Java を思い出させるItem 1: Consider static factory methods instead of constructors

于 2013-05-04T05:54:41.840 に答える
0

フィードバックに基づいて、正しい製品を作成する新しい ProductFactory クラスを導入しました。私の場合、正しい製品インスタンスの作成は外部コンテキストに依存します (簡単にするために製品コードを配置しました。実際のケースでは、いくつかのパラメーターに基づいている可能性があります。これらは時間の経過とともに変化する可能性があります)。したがって、質問で概説されている理由により、 Product.getInstance() メソッドを持つことはあまり適していません。また、別の ProductFactory を持つということは、将来的には.. Product クラスは、必要に応じてインターフェースになることができます。拡張性が増すだけです。

オブジェクトの作成が外部コンテキストに依存しない場合.. Calendar.getInstance() の場合のように、そのようなメソッドを使用してもまったく問題ないと思います。このような状況では、正しいインスタンスを見つけるロジックは、その特定のモジュール/クラスの内部にあり、外部から提供される情報には依存しません..

于 2013-05-11T07:51:03.703 に答える