第二回 デザインパターン勉強会: 生成に関するデザインパターン
生成に関するデザインパターン
AbstractFactoryパターン
あるクラス(A)を生成する際、クラスAのフィールドになるクラス(B)の生成はプログラマによって様々なものが考えられる。
例えば、CarクラスがTireクラスを必要とする時、Tireクラスの子クラスを全て受け付ける。(CarTireやBicycleTire等)
その際、クラスAが必要とするクラスBを生成するクラス(Factory)を用意することで、意図したクラスを生成することが可能である。
また、このクラスFactoryを抽象クラスにすることで、呼び出し元はクラスFactoryの実装に依存しない為、
様々なFactoryに差し替えることが可能である。(CatFactoryやBicycleFactory等)
この抽象的なクラスFactoryのことをAbstractFactoryと呼ぶのが、AbstractFactoryパターンである。
例:
code: 例.java
abstract class Factory {
public abstract Tire getTire();
}
class CarFactory extends Factory {
@Override
public Tire getTire() {
return new CarTire();
}
}
要するに、実装じゃなくて抽象に依存しましょう的なことだと思う。
Builderパターン
登場人物はDirectorとBuilderとProduct。
BuilderはコンストラクタでProductを生成する。
DirectorはBuilderを受け取り、Builderのメソッドをいい感じに組み合わせてProductの内部状態を作る。
最後に、BuilderからDirectorによって作られたProductを呼び出し元で受け取る。
メリットは、Builderを抽象にすることで、Directorに様々なBuilderを渡して同じような手順でProductの内部状態を作ることが出来ることである。
また、モデルと生成ロジックと生成ロジックの手順という3つの責務を分離させて柔軟性を上げるというメリットもある。
FactoryMethodパターン
コンストラクタを自作するイメージ。
あるインスタンスのインスタンスを返すメソッド(factoryMethod)を用意しておくと、
factoryMethodをオーバーライドすることで自由に返すインスタンスの型を変更出来る。
Qiitaの記事によると、factoryMethodは生成するクラスに実装すべきとなっている。
参考URL