事例で学ぶデザインパターン 第 4 回 (Factory Method Pattern)
事例で学ぶデザインパターン 第４回 Factory Method パターン ～オブジェクト生成の柔軟性を導入する～ （株）オージス総研 福田 直樹 今回は、生成に関するデザインパターンを取り上げます。 通常、何らかのオブジェクト利用する際には、コンストラクタを呼び出してオブジェクトを生成し、そのオブジェクトを利用します。しかし、その際には利用する側では利用したい具象クラスを指定する必要があり、クラス間の結合度が強くなってしまいます。それよりも柔軟性のある生成の仕組みを提供するFactory Methodパターンを取り上げます。 ※雑誌『Java WORLD』 2006 年 7 月号に掲載した記事のオリジナル原稿を Java WORLD 編集部の了解を得て掲載しています。 前回のおさらいと今回のお題 前回は、重複した実装を洗練、整理するデザインパターンとして Template Method
クラス設計に関するメモ
経験的にこのようにした方がよいと思った点についての記録です。 仕事で大規模(2000クラス超)かつ製品寿命がながいパッケージソフトを作っていた関係で、 ちょっとした設計の間違いが、 あとあとで大変な苦労する羽目になったりすることを経験してきました。 このような規模が大きいアプリケーションを作ることはなかなかないかもしれませんが、 なにかの参考になれば、と思います。 継承する前に委譲を検討する Singleton パターンを使うときの注意 Template Method パターンを使うときの注意 クラス間の依存に関する注意 クラスの粒度 Singleton の問題を回避できるか？ 継承する前に委譲を検討する 継承はスーパークラスの仕様をよく理解しておかないと、 バグを作りこみやすいので十分注意する必要があります。 メソッドのオーバーライドをするときも、 public void foo(){
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
