イントロダクション オブジェクトを利用する側からすれば、使用する際にオブジェクトの詳細を意識したくはありませんよね。 たとえば、条件によってデータファイルの読み込みに使うオブジェクトが異なる場合、CSV形式であればCSVDataReaderオブジェクトを、XML形式であればXMLDataReaderオブジェクトを生成します。 通常はif、else、switchなどの条件分岐を使用して、条件ごとに生成するオブジェクトを変更します。 ここで新たなデータファイル形式への対応が必要になった場合は、新しいオブジェクト生成処理と、条件式を追加しなければいけません。 オブジェクトの使用者は、オブジェクトが使用できる状態で受け渡してもらい、オブジェクトは使うことだけに専念したいものです。 また、このようにオブジェクトの生成処理と使用処理が同じコードに書かれていた場合、オブジェクトの生成処理によってオブジェ
GoFデザインパターンはなかなか奥深く、入門書を読んでパターンごとのクラスの絡み合いを理解しただけでは 真価を理解できないことが多々あります。 独習デザインパターン のクラス図からAbstract Factoryパターン と Builderパターンの違いがうまく説明できなかったので GoF本を紐解いて その目的を調べてみました。 Abstract Factoryパターンの適用可能性 Abstract Factoryでは、「ある抽象的な型の実装を返す」というインターフェースを定義し、 そのインターフェースの実装を多種揃えるといった形になります。 GoF本では例としてlook&feelを取り上げています。 JavaのswingのライブラリではUIのデザインをごっそり切り替えることができますが、 その具象クラスの生成を具象型を知らずに行いたいというようなケースを想定すればよいのでしょう。 GoF
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
