́∀`)'`,、ついにパターンのカタログまで来ました。何らかのインスタンスを必要とする時に、その実装に関わる具象クラスを明確にせずに生成する為のマネージャクラスを用意するパターンです。見たいなクラスがあったりするでしょう。用いて設計されているのではないでしょうか。このパターンは、抽象クラスとサブクラスを用いて場合によって実装をスイッチする際等に活躍します。簡単にまとめると、何らかのオブジェクトの集合に対して複数の実装系がある時、生成用のアクセスポイントを持つマネージャクラスを用意し、実際の生成はサブクラスに任せる構造です。複数のプラットフォームに対応したアプリケーションを書く場合、各プラットフォーム向けのGUIコンポーネント群を定義するでしょう。その時、実装に拠らず同じオペレーションで同等の機能を呼び出す為に、各コンポーネントは抽象基底クラスから派生して実装するかと思います。生成する場面で特定の実装に触れたくないのです。フォローしたいわけです。そこで生成の為のインターフェイスを持つマネージャクラスを用意し、それを派生して各実装のコンポーネントを生成するサブマネージャクラスを定義します。後はプラットフォームにあわせた具象クラスを抽象マネージャクラスに代入して、コンポーネントの生成は抽象マネージャクラスを通せばよいのです。パターンとの併用も良く見られます。パターンもいい事づくめと言う訳ではありません。メリットがあればデメリットもあります。関しては、インターフェイスの追加や削除を含む変更に弱いと言うデメリットがあります。インターフェイスの追加や削除が行われるとサブクラスまで手を加えなければなりません。一つの解答を示しています。構文でクラス名が既知でならなければならない問題を最小化します。これは動的に型付けする言語では問題にならないのかもしれませんが、静的な型付けを行う言語ではまず確実に問題になる部分です。長月はC++ぐらいしかまともなOOPLに触れていないので他の言語の事情を知りませんが、生成に関するパターンはC++でそれなりに良い設計と実装を行いたければ必須の構造に思えます。