私はファクトリデザインパターンをJavaで実装しています

Question

私は抽象クラスで1つのオーバーロードされたメソッドを保持したいと思うjavaのファクトリデザインパターンを実装しています。それは工場パターンのコンセプトに違反しますか？ これが工場設計パターンを実装する正しい方法であるかどうかをご提案ください。

abstract class A{ 
    void meth(int a); 
    void meth(int a,int b); 
} 

class Factory{ 
    public static A factoryMethod(int a){ 
     if(a==1){ 
      return new Ob1(); 
     }else{ 
      return new Ob2(); 
     } 
    } 
} 

class Ob1 extends A{ 

void meth(int a){} 
void meth(int a,int b){} 
} 

Answer 1

あなたはFactoryが生成されるかを検討する必要がありFactory Pattern最初のを実装します。 Vehiclesを作りましょう。

public VehicleFactory { 
    public Vehicle newVehicle(String type) { 
     ... 
    } 
} 

これは、下のクラス階層に従ってVehiclesを生成します。

public interface Vehicle { 
    public List<Door> getDoors(); 
} 

public class Motorcycle implements Vehicle { 
    public List<Door> getDoors() { 
     return Collections.<Door>emptyList(); 
    } 
} 

public class SportsCar implements Vehicle { 
    public List<Door> getDoors() { 
     return Collections.<Door>unmodifiableList(Arrays.asList(new Door("driver"), new Door("passenger")); 
    } 
} 

public class Hatchback implements Vehicle { 
     public List<Door> getDoors() { 
     return Collections.<Door>unmodifiableList(Arrays.asList(new Door("driver"), new Door("passenger"), new Door("back")); 
    } 
} 

その後

public Vehicle newVehicle(String type) { 
    if ("motorcycle".equals(type)) { return new Motorcycle(); } 
    if ("sports car".equals(type)) { return new SportsCar(); } 
    if ("hatchback".equals(type)) { return new Hatchback(); } 
    return null; 
} 

ように見えるかもしれませんあなたVehicleFactory方法は今のメインの質問は、「なぜ、あなたはこれを行うにしたいですか？」され

多くの場合、 関連項目を構築するためのきれいなインターフェイスが必要です。関連項目にInterfaceとFactory を作成してそれらを作成します。これにより、ソフトウェアのこの部分を使用している誰かがInterfaceクラスとItemFactoryを単に引き出すことができます。 彼らは 個々の詳細を参照してください、そのコードを簡素化します。あなたはプログラミングエラーがあった場合は、上記のコードでVehiclesのすべての実装の詳細を隠した（または何かを追加したい）、あなたはVehiclesの1を修正（または新規Vehicleを追加する）ことができるので

工場に戻し、VehicleFactoryを含むライブラリ（JARファイル）を再リリースします。

他の人がVehicleFactoryメソッドを使用していることがわかっているので、コンパイル時にコードが破損する心配はありません。また、あなたが不注意でない限り、実行時に確実に動作することを保証することもできます。

これは、動作が変更されないということと同じではありません。 Vehicleの新しい実装が返されます。うまくいけば、埋め込まれたバグは少なくなります。また、彼らはnewVehicle("station wagon")かそのようなものを呼び出すまで、あなたが追加したかもしれない "新車"を求めなかったので、彼らはそれらを見ないでしょう。

また、Vehiclesのビルド方法を変更することもできます。後であなたが単純な実装スタイル「ただ一つのパスでそれを構築」したくないと判断した場合たとえば、あなたは

public Vehicle newVehicle(String type) { 
    Chassis chassis; 
    if ("motorcycle".equals(type)) { 
     chassis = new TwoWheelChassis(); 
    } else { 
     chassis = new FourWheelChassis(); 
    } 
    return new ComponentVehicle(chassis, getDoorCount(type)); 
} 

ので

のような場所 ComponentVehicle道具「newVehicle（...）」を変えることができ Vehicleなんらかの理由で明示的な Chassisオブジェクトが必要です。

コメント欄に質問「メソッドの数を」見

---更新---

Factory patternは、多くの方法については、実際にはありませんが、およそ1の方法は、アウト抽象的なものを構築する能力を有します1つ以上の具体的なものの

したがって、上記の例では、私が

public VehicleFactory { 
    public Vehicle newVehicle(String type) { ... } 
    public Vehicle newRedVehicle(String type) { ... } 
    public Vehicle newBlackVehicle(String type) { ... } 
} 

を持っている可能性があり、それらはすべてVehicleの種類に関してacceptibleファクトリメソッドになりますが、彼らは、色に関しては、工場指向の方法ではないでしょうVehicleの

同時に種類と色を処理できるファクトリメソッドを取得するには、ファクトリメソッド

public Vehicle newVehicle(String type, String color) { ... } 

が追加される可能性があります。場合によっては組み合わせが意味をなさないことがあるので、すべてのファクトリメソッドを単一のファクトリメソッドにパックする価値があるかもしれません。

ファクトリオブジェクトのメソッドは、インターフェイスの複数の基本型を返す可能性がない限り、ファクトリメソッドではありません。同様に、メソッド外にオブジェクトを構築する方法を指定する必要がある場合は、ファクトリメソッドではありません。

Vehicleをビルドする方法の制御を、ファクトリで使用していたときに「工場だっただろう」という方法でクライアントに渡す必要がある場合は、Builder patternが必要です。どのようBuilder Pattern異なった例はありません、あいまいな用語である

VehicleBuilder builder = new VehicleBuilder(); 
builder.addDoor("driver"); 
builder.addDoor("passenger"); 
builder.paintVehicle("red"); 
Vehicle vehicle = builder.getVehicle(); 

Answer 2

Factoryパターン下のクライアントコードで見ることができますか？単純なファクトリ、ファクトリメソッド、および抽象ファクトリがあります。シンプルファクトリーについてお話していると思います。 https://www.codeproject.com/Articles/1131770/Factory-Patterns-Simple-Factory-Pattern