[JP]Design Pattern: Abstract Factory
--
我々は前の記事で Factory Method Pattern に対して勉強しました。
Factory とはオブジェクトの生成のみを担当しているクラスで、オブジェクト生成をシンプルにして管理を簡単にする利点がありました。
Factory Method 復讐
GameFactory というファクトリーを利用し Game インターフェイスを実装した Zelda と Pokemon クラスのオブジェクトを生成しています。
オブジェクト生成に対するロジックを全てファクトリーに書いたため、コードの修正が必要な時、ファクトリーのみ確認すればいいです。
Factory Method 評価
現在は Game インタフェースを実装したクラスが2つしかない状態ですが、ゲームの種類が多くなって、100種類になればどうなるでしょうか？
Factory クラス内部の条件文が非常に長くなります。コードの管理が難しくなります。
その理由で Factory Method をより簡単にする必要性ができました。
Abstract Factory
Factory Method Pattern の問題が条件分が多くなることであれば条件分をなくす方に GameFactory クラスを修正することができます。
ここで1つの疑問ができました。条件分を継承したクラスに変える単純なことが Abstract Factory Pattern の全てなのかという疑問です。
Factory Method Pattern と違うところを調べたら、Abstract Factory は関連する生成メソッドを結ぶことにありました。
ゲームのパッケージを作るこのプログラムをよく考えると、パッケージを作るということには「説明書」、「イラスト画像」、「ゲームCD」を作るなどの作業が必要だということがわかります。
Factory Method Pattern ではただ1つの生成メソッドのみクラス内に存在しましたが、Abstract Factory では生成メソッドだけじゃなく、必要な他のメソッドも1つのクラスの中で管理します。
Abstract Factory 拡張
ゲームパッケージを作るのに関連するすべてのメソッドを1つのクラスで管理する方法でコードを理解することがもっと簡単になりました。
最上位抽象クラスを通じてコンクリートクラスがどんなことをするかを予測することもできるし、メソッドの中身はコンクリートクラスで実装するため、スペックの変更が発生すると対応が非常に簡単になります。
結論
ただフレームワークに合わせて使っていたデザインパターンがなぜ作られたのか、勉強しながら調べて理解するのは思ったより楽しいですね。
次の記事では Adapter Pattern に対して調べてみます。
