Factory Method パターンの利点

ご回答ありがとうございます。
教えてもらった設計をすることで、利用者には誰がどの携帯電話を使ってるかまで意識する必要がなくなりますね。

質問してわかったのですが「java の抽象化の利点＝Factory Method の利点」と勘違いしていたケースが多々あります。ご迷惑かけました ^^

自分も紹介された本を含め、２冊ほどデザインパターン関連の本を購読しています。解説された利点も紹介されていて、確かに使えるパターンですね。

パターンをより効率よく利用してよい設計を心がけたいものです。

どうも、インターフェイスについての理解が足りなかったようです。しかし、いずれのパターンも多様性を意識して作られているので、上記説明は大変参考になりました。

また、勉強していくうちに、私の返答がFactory Method に関して言及している訳ではないことも理解できました。

以降はjava の経験を積むとともに、教えて頂いた書籍で勉強しようと思います。

今回はいろいろと教えていてだき、ありがとうございました。

自分の理解の再確認ができ、大変参考になりました。ありがとうございます。

こちらは、オブジェクトを利用する(クラス) 立場からの利点を書かれているのですね。

オブジェクトの実装クラスと利用クラスが分別できている場合、利用クラスでは Iterator ite=coll.iterator(); のように利用してもIterator の実装クラスを知る方法はなく、また知る必要もないですね。

つまり、この例でいえる事＝Factory Method の利点とは、

「利用クラスがインターフェイスの実装を知る必要がないため、実装クラスの変更がしやすくなる、つまり再利用しやすいこと」

でしょうか？

テンプレートパターンと併用するケースは分かりやすく、理解できました。ありがとうございます。

この例を見ても、boss() のように国によって異なる実装がある場合に戻り値としてインターフェイスを使うようですね。そして、親クラスでアルゴリズムを決めておいて、サブクラスでインターフェイスの実装を行う。だから自然と戻り値もインターフェイスとなるのですね。

テンプレートパターン、Factory Method パターンの実例があると分かりやすいです。

何度もお手数掛けますが、「継承はそのツリー構造内でカプセル化が破られる」とは、継承クラスで新たにメソッドやプロパティーを定義することができることをおっしゃっていますか？

これがFactory Method パータンにそぐわない理由は、

通常、オブジェクト利用者はメソッドを利用する場合、インターフェイスの仕様にあるメソッドを使う。が、継承クラスの場合は継承クラス独自のメソッドを実装できるため、オブジェクト利用者が知らない実装ができてしまう。つまり、継承したクラス独自のメソッドが作れてしまうことが問題。

という理解でよいのでしょうか？

お返事ありがとうございます。

質問してから私もWEB+DB の特集などを参考にFactory Method パターンの利用価値について勉強してますが、なにせ初心者なのでなかなか理解できません。追加で質問させてください。

「Javaでは戻り値の型をインタフェースにする」とありますが、戻り値をインターフェイスにする理由はオブジェクト利用者にFactory Method が返すオブジェクトを意識させないためですよね？例えば、ログ出力をsyslog にする場合、getLogger( "syslog" ) のように、利用者が欲しいオブジェクトをFactory Method に教えている意味では、意識していると思うのですが。戻りをインターフェイスにする価値がいまいち分かってないと思います。

お手数ですが、よろしければ教えてください。

※ 参考書は本屋で見てこようと思います。ありがとうございます。