前回はもっとも簡単なSimple Factoryパターンを案内しましたが、
今回のFactory MethodパターンはSimple Factoryパターンを拡張した内容と言えるでしょうか。
Factory Methodパターンはそのオブジェクトを生成するかを各サブクラスに決定させる抽象クラスを定義します。
言葉での前置きよりさっそく実例を見ていきましょうか。
以下はクラス図になります。
ソースコードで実装するとこんな感じでしょうか。
// Factory Method抽象クラス
public abstract class Creator {
public abstract Product factoryMethod();
}
// Factory Method具象クラス
public class ConcreteCreator extends Creator {
public Product factoryMethod(){
return new ConcreteProduct();
}
}
// 製品抽象クラス
public abstract class Product {
public abstract void hell();
}
// 製品具象クラス
public class ConcreateProduct extends Product {
public void hello() {
System.out.println("Hello World");
}}
// メインクラス
public class FactoryMethodMain {
public static void main(String args[]) {
// 引数args[0]には「ConcreateCreator」が設定されていること
Creator creator = Class.forName(args[0]).newInstance();
Product product = creator.factoryMethod();
product.hello();
}
}
では、どういう場合にFactory Methodを使うべきでしょうか?
考えられる状況として
・これはSimple Factoryパターンにも言えますが、
生成すべきオブジェクトのクラスが予測できない場合。
・生成すべきオブジェクトをサブクラスによって特定する場合。
・どのクラスのオブジェクトを生成すべきかに関する知識を局所化したい場合。
デメリットとしては、生成するオブジェクトが増えるごとにファクトリーメソッドを持ったクラスが増えてしまうことではないでしょうか。
その問題もDIコンテナを導入することで解決出来ますが、DIコンテナが考えられた背景を学ぶのは損ではないと思います。
人気ブログランキングへ
0 件のコメント:
コメントを投稿