Abstract Factoryパターンについて。

Abstract Factoryパターンについて。

本を読むと大抵難しくこんな感じで書いてあると思います。

「互いに関連したり依存し合うオブジェクト群を、その具象クラスを明確にせずに生成する為のインターフェースを提供する。」

これ読んで一発でわかるなら、以降のAbstract Factoryパターンについては読まなくても大丈夫です。

何言ってんだ？？？
って場合は、前記載した通りできる限り簡単に噛み砕いて説明をします。

そもそもこのAbstract Factoryパターンで何がやりたいのよっていうと、
同じような操作を呼び出し元が行う場合に、各種呼び出し結果による振る舞いを
実態に任せて、呼び出し元は何を実体化させるかを意識しないでおきたいというような場合に利用します。

(´－｀) ンー　これでも難しいですね説明が。

さて、もっと噛み砕きましょう。

何かしようかと思ったら、見えない妖精さん達が、最適な物を作ってくれるようにする為の仕組みです。
(こんな書き方したら、間違いなく偉い人は怒るよね？(´ρ`))

なんでこのような仕組みが必要かというと、例えば開発において使用するデータベースが環境単位で複数あるとします。
そんな時、当然使用するSqlCommandクラスなどは、対象となるDBに合わせたものが必要となります。

しかしながら、データを操作する側としては、インサート処理はインサート処理として記載をしたいわけです。
データベースがなんであれ。

そうした場合に、データ操作を行う為のクラスの実態と、データ操作を行うという命令自体を分けてしまい、
その間を取り持つための抽象クラスとして、各種操作を行う為の命令を提供しようという事です。

結果として、使用する側は実態が何かを考えないで、各種操作をするうえで必要となる命令部分を
抽象クラス側で提供してもらえればよい。

抽象クラス側も実装自体は、各種操作側の実態に任せてしまえばよいので楽ちんです。

そして操作側も、他に何があるかを考えずに、指定された抽象クラス内で定義されている
操作を実装するだけで問題が無いので楽ちん楽ちんです。

そして、最後に、このクラスの実態を生成する為仕組みとしてクラスの実態を作成する為の
実態作成クラスを作ってしまいます。

基本的には、どういった設定で実態クラスを生成するかは、Abstract Factoryの実態作成クラス側の内部に隠蔽するべきです。
これを外部から指定し始めてしまうと、隠蔽していた実際の命令が外部にまで飛び火する可能性が高いです。

実態がなんであれ、命令として同一の命令で臨む結果を設定に従って適宜実態であるクラスが行ってくれるのが
一番良い方法です。

もっとも、どうして特殊な操作が必要で、生成する実態を外部から制御したい場合があるとは思いますが、
そういった場合は、苦肉の策としてパラメータを指定して生成する実態を制御する方法もあります。

ただ、これを行うと先に書いた通り、抽象化していたクラスの実態が何であるかをわかったうえで操作する必要がある
特殊な物がある状態になるので、メンテナンス性は著しく低下します。

また、新規の操作を追加したり、新しい実態群が必要になった場合は、実装側のクラス全てに手が入る可能性がある為、
メンテナンスを行う手間が多くなる可能性もあります。

この辺を考えて作る必要があります。

今回のデータベースで考えると、作成しなければいけないのは、コマンドクラスとパラメータクラスとコネクションクラスとって色々ありますが、これらのクラスを抽象化し、実態をそれぞれ実装してもらい使う側は抽象クラス使って、実態生成の整合性については実態生成部分に責任をなすりつけようという形になります。

んでは今回はここまで。
暇があったらgithubにでもサンプルを随時追加予定？？？