kyosho5’s blog

貧乏で数学があまり得意ではない理系出身のエンジニアのブログ

デザインパターン勉強メモ④

第7章 Builderパターン

構造を持ったインスタンスを積み上げていくという考え方。

・Builder役
インスタンスを作成するためのインタフェース(API)を定める。
インスタンスの各部分を作るためのメソッドが用意される。

・ConcreteBuilder役
→Builder役のインタフェース(API)を実装しているクラス。
実際のインスタンス作成で呼び出されるメソッドが定義される。また、最終的にできた結果を得るためのメソッドも定義される。

・Director役
→Builde役のインタフェース(API)を使ってインスタンスを生成する。
ConcreteBulder役の種類に関係なく動作するようにBuilder役のメソッドのみを使う。

・Client役
→Builderパターンを利用する役。

オブジェクト指向プログラミングでは、どのクラスがどのメソッドを使えるかを意識することが重要。
DirectorクラスがBuilderクラスしか知らないような形にする(ConcreteBuilderクラスの種類に関しては何も知らないようにする)ことで
交換可能性が高まる。

つまり、Builderクラスはそのサブクラスたちが将来必要とするであろう必要十分なメソッドを宣言していなければならない。
設計者は、すべてを見通せないまでも近い将来必要となりそうな変化には耐えうるような設計を意識する必要がある。

既存のソースを読むときは、抽象クラスばかりを眺めるのではなく
Directorクラスを読みこんでBuilderクラスのメソッドの使われ方を理解し、最後にConcreteBuilderクラスを読むことで
Builderクラスにどういう動作が期待されているのかをチェックする。
変更すべきクラスとそうでないクラスのみきわめが大事。

第8章 Abstract Factoryパターン

抽象的な工場が登場し、抽象的な部品を使って抽象的な製品を作る。
部品の具体的な実装には注目せず、インタフェース(API)に注目し、それだけを使って
部品を組み立てて製品にまとめる。
Template MethodパターンやBuilderパターンと同様にサブクラスのレベルで具体的な実装をおこなう。

・AbstractProductの役
AbstractFactory役によって作り出される抽象的な部品や製品のインタフェース(API)を定める。

AbstractFactoryの役
→AbstractProduct役のインスタンスを作るためのインタフェース(API)を定める。

・Client役
→AbstractProducとtAbstractFactoryのインタフェース(API)だけを使って仕事をする役
具体的な製品や工場については知らない。

・ConcreteProduct役
→AbstractProduct役のインタフェース(API)を実装する。

・ConcreteFactory約
AbstractFactoryのインタフェース(API)を実装する。

AbstractFactoryパターンではクラスの構造やどのようなメソッドを実装すべきかがはっきりしているため、
ConcreteFactoryを新たに追加するのが簡単になる。

AbstractFactoryに新しい部品を追加すると、それを実装しているすべてのConcreteFactoryに対応する修正を加えなければならないため大変。

工場を新たに追加するのは簡単だが、新たな部品を追加するのは困難である。

インスタンスの作り方
①Something obj = new Something();

②Prototypeパターンで登場するclone()メソッド
→すでに存在するインスタンスをもとに新しいインスタンスを生成できる。
(コンストラクタは呼ばれない)

③newInstance
java.lang.ClassクラスのnewInstanceメソッドを使う。
例外が発生するメソッドなのでtry-catchでくくるかthrowsの宣言が必要。

ここまでの感想

著者もいうように8章は自分にとってかなり難しいというか複雑というか
週末の時間を使ってソースを写経することにする。