イントロダクション アプリケーションで扱うデータをモデル化してみると、オブジェクト同士の関係を単純な1対1の関係だけで管理できることはほとんどありません。 多くのオブジェクトは、他のいくつかのオブジェクトへの関わりを持つことで構造を作っています。 この構造が単純なうちはよいのですが、また別のオブジェクトへと次々に関わりを持っていくことで、構造はどんどん複雑になっていき、直感的に実装したり使ったりすることが難しくなります。 そんなときはコンポジットパターンが威力を発揮します。 コンポジットパターンは、要素であるオブジェクトと、複数の要素からなる複合オブジェクトを区別なく扱えるという特徴を持ちます。 この特徴を利用することで、構造を再帰的に組み立て、クライアントからの見た目をシンプルに保つことができます。 パターン解説 コンポジットパターンは、ディレクトリ構造のような再帰的な構造を解決すること

イントロダクション 入出力は同じだけど条件によってアルゴリズムの交換を行いたい場合や、将来的にアルゴリズムが変更される可能性がある処理に遭遇する場面があります。 また、switch文などの条件分岐にアルゴリズムを埋め込むような処理を行うと、変更が発生した場合に他のアルゴリズムへ影響が生じたりコードが冗長になったりし、保守性がよくありません。 ストラテジパターンは、アルゴリズムをクラス化することにより、アルゴリズムの切り替えを使用するクラスとは無関係に簡単に行えるようにするパターンです。 なお、ストラテジは「戦略」という意味です。条件によってアルゴリズムを切り替えるところは、まるで戦略を練っているようですね。 パターン解説 データ処理を例にストラテジパターンを説明します。 図6の左側のように、入力したデータ処理が条件により振り分けられ、最終的に同じ型のデータを出力する処理が存在します。 この

イントロダクション オブジェクトを利用する側からすれば、使用する際にオブジェクトの詳細を意識したくはありませんよね。 たとえば、条件によってデータファイルの読み込みに使うオブジェクトが異なる場合、CSV形式であればCSVDataReaderオブジェクトを、XML形式であればXMLDataReaderオブジェクトを生成します。 通常はif、else、switchなどの条件分岐を使用して、条件ごとに生成するオブジェクトを変更します。 ここで新たなデータファイル形式への対応が必要になった場合は、新しいオブジェクト生成処理と、条件式を追加しなければいけません。 オブジェクトの使用者は、オブジェクトが使用できる状態で受け渡してもらい、オブジェクトは使うことだけに専念したいものです。 また、このようにオブジェクトの生成処理と使用処理が同じコードに書かれていた場合、オブジェクトの生成処理によってオブジェ