オブジェクトの生成 †
CargoのFACTORIESとコンストラクター †
- 色々なオブジェクトの生成方法があっても、原始的な(primitive)コンストラクターが必要。その方法は以下の二つ。
- CargoにFACTORYメソッドを作成させる方法
- 独立したFACTORIESを設ける方法
- 両方とも空のDelivery HistoryとnullのDelivery Specificationを持ったCargoを生成する。
- CargoとDelivery Historyは相互参照の関係。
- Cargoを生成する際に、Delivery Historyのコンストラクターを呼び出しCargo自身を渡している。
- Delivery HistoryはCargoからしか呼び出されないので、Cargoのコンポジションはカプセル化される。
Handling Eventの追加 †
- Handling Eventの原始的なコンストラクターはEvent Handlingを一意に識別するための要素を引数に持つ
- Handling Eventの属性は一度生成されたら変更されることはない
- ⇒イベントタイプ毎にHandling Eventに簡単なFACTORY METHODを持つと便利だ。
- 様々な子クラスを持つ基底クラスのHandling EventクラスにイベントタイプごとにFACTORY METHODを追加する
- ⇒インスタンス生成の実装を抽象化することができる。
- 次の循環参照がインスタンス生成を複雑にしている。
- Cargo⇒Delivery History⇒History Event
- History Event⇒Cargo
- この循環参照はFACTORYの中で解決されるべきであるが、ここで別の設計の話題に移ることにする。
担当者のつぶやき †
- 担当の前後部分を読めておらず、おかしなところがあったらすみません。
- 親クラスのHandline Eventに子クラスの生成メソッドを持つのは親が子に縛られる感じがしますが、これらのクラスを使うほうとしてはHandline Eventだけ知っているという利便性もいいなと思いました。
みんなの突っ込み †
- 冒頭部分なのですが、「FACTORYがあったとしても、コンストラクタを作らなければならない」という主旨のことが書いてあるのが気になります。「publicでなくても言語仕様的にコンストラクタは必要」という意味であればその通りなのでさらっと流せるのですが、サンプルのコンストラクタはpublicなんですよね・・・。FACTORYを作るなら、外からはFACTORYだけを使わせようとするのが自然だと思うのですが、どういうことなのでしょう？私も読み取りきれていません。
- 細かい部分で恐縮ですが、Handling Eventクラスはサブクラス化されている訳ではなく、イベントタイプ属性を持っているだけです。この属性値として定数（今ならEnumになるのでしょうが）が定義されているようですが、FACTORY METHODを使うことで、クライアントはどの値がどのタイプを表すのかを考えなくても良くなるということのようですよ。
- 最後の一文は、「循環参照の生成はFACTORYの中に隠蔽することも出来るのだろうけれど、ここでは、この怪しげな相互関係を解決できるような別のデザインを考えてみよう。」という感じで次の節に続いていくのだと思います。-- 和智?
