誰か作ってくれる人がいることにして、遊ぶほうに意識が行っちゃってますね。いいですね、これこそオブジェクト指向の醍醐味です。
複雑なものをできるだけシンプルにするには「関心の分離」が重要です。とくに、操作に関する知識と生成に関する知識とを分離するのは良いアイデアです。操作のたびに、どういう作りなのかを気にして if - else を書いてしまうと、「ラジコンのプロポをガチャガチャするだけで楽しい」では済まない複雑さになってしまいます。サーボの設定事情などは、どんなちょうぜつ操作をしてもいい感じに動くように生成して、隠蔽すればよいのです。判断を前倒しした結果を生成物に閉じ込めてしまうわけです。
というふうに生成と操作を別のクラスに分離しましょう...で話は終わりません。ここで、操作する人が具体的に誰かに作ってくれと言ってしまう(具象クラス型を利用してしまう)と、操作は生成者に直接依存してしまいます。本当に生成の詳細に無関心でいるためには、作り方だけでなく、誰が作ってくれるのかにさえ関心を払ってはいけないのです。というわけで出てくるのが「作ってくれる誰か」という抽象概念です。依存する先はそこです。
めもりーちゃん(作れないのになんで買ってきた)は姫なので、誰に頼むかまで考えていません。「まあ誰か作ってくれるんでしょ」としか思わないのです。それでいいんです。関心があるのは操作の方なので、そっちに集中してもらうのが健全で、そこまででパッケージを完結させてしまいましょう。あとは単体テストで「誰か」としてモックファクトリを使えば、パッケージに含まれるコードはすべて完成ですね。やりたいことしかしないので、テストケースも簡単です。作ってくれる人は別パッケージの責務なので気にしたら負けです。
要するに、オブジェクトを生成するオブジェクトに関して、このように詳細のわからない依存をいったん抽象のままにして、オブジェクトを利用する方にのみ着目すること、つまり、依存関係逆転原則 (Dependency Inversion Principle = DIP) のファクトリ版が Abstract Factory パターンです。
って感じで、マンガと解説(コードはノイズになるから書かない)で概念だけわかるシリーズをあと22パターン、ソロアドベントカレンダーでやっていこうと思います。
たまたま初回がいきなり最重要パターンで、解説がやや多くなってしまいました。解説の量はパターンによってムラが出てくると思いますが、どうぞよろしくおねがいします。
Twitter でも ちょうぜつエンジニアめもりーちゃん をよろしくおねがいします。