GoFデザインパターンの生成パターンを会得しているかどうかを示す、な話 生成に関するパターン篇
ごあいさつ
こんばんわ。今日はこの記事の続きです。
現在、GoFデザインパターンを覚えなおそうということで、そのうちの５つ、「生成に関するデザインパターン」を覚えなおそうという話です。
1.Factory Method
ロジック内部で抽象的なオブジェクトを使えるように、基底クラスではロジックのみ、使用するオブジェクトの生成に関する部分をサブクラスに任せるパターン。依存性交換に使えるデザインパターン。
2.Abstract Factory
工場そのものを抽象化させて、工場の中身に依存すること無くいろいろな工場を再利用できるようにできる。抽象化した工場の中では、更に内部で使用するオブジェクトを抽象化しておく（Factory Methodを活用する）。
3.Builder
複雑な一つのオブジェクトを一気に作るのではなく、複数の構成に分けて段階的に作っていくように設計する方式。Factory Methodを応用できる。JavaのBufferdReaderなどが有名。インタフェース分離の原則を実現しやすくなる。
例えば、フルコースを出すロジック内で魚料理を出す際、魚料理クラスを基底にして焼き魚料理クラス、マリネクラス、刺し身クラスに差し替えても、ロジックを変えること無く魚料理を出すことができる。
(※このパターンは昔のRubyの「大クラス主義」と対比すると、インタフェース分離の原則に相まって、実情に見合わなさそうに見えていたが、その後、Objectクラスの上位にBasicObjectクラスを追加するなどの変化が見られている)
4.Singleton
システムの中で使う、とあるクラスのオブジェクトが複数の場所で存在しているように見えて、実体はただ一つのみということを保証する方式。
オブジェクトの内部ロジックで一つしか存在できないもの(例えば、ファイルI/OやDBアクセスのオブジェクト、メッセージキューなど)に対して余計な心配(二重に生成したらどうしよう、など)をすることなく設計できるようになる。
定数も一種のSingletonと捉えられる。
5.Prototype
オブジェクトのインスタンスを生成するときに、どうしても複雑な処理や時間がかかる処理がかかると分かっている場合、生成したインスタンスを複製するようにしてその手間を省く手法。Singletonと違うのは、オブジェクト自体は別々のものが生成されること。
例えば、「手描きで百万本のバラの絵を描いておく」オブジェクトを生成するときに膨大な時間がかかるのは目に見えているので、「描いた絵を複写機でコピーする」処理を実装しておくと、次の生成ではそれほど時間がかからなくなる。
おわりに
今回、あまり実例を示さなかったのは、考え方を理解して、共通言語のように使えるのかを試してみたかったからです(Builderは厳しかった…)。
ぐちゃぐちゃ実装内容を説明するより、「このパターンを使いました」と言えるようになったらめっちゃスマートやないですか。
続きの「構造に関する(略)」と「振る舞いに関する(略)」も同じようにやっていけたらなと思います。
参考
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？