デザインパターン：コンパウンドパターン（Compound Pattern）

no_mkd

一.コンパウンドパターンとは？

形式的には、コンパウンドパターンは確かに複数のパターンの組み合わせですが、これだけではコンパウンドパターンとは言えません。以下の定義に注意してください：

複数のパターンを結合して「フレームワーク」を形成し、一般的な問題を解決します。「フレームワーク」と言えば、MVC が最も思い浮かびやすいでしょう。実際、MVC は古典的なコンパウンドパターンです。

二.MVC とコンパウンドパターン

Model、View、Controller 各々の役割：

ここで制御ロジックとアプリケーションロジック（アルゴリズムロジック）の違いを強調しておきます：

• 制御ロジックとは、現在の状況でどのオブジェクトのどのメソッドを呼び出すべきかを判断することです
• アプリケーションロジックとは、具体的なオブジェクトの具体的なメソッドの内部実装（複雑なアルゴリズムや一連の具体的な処理）を指します

（厳密に言えば、View にも少し制御ロジックが含まれています（ユーザーのアクションに基づいてどの Controller を呼び出すべきかを判断）。もちろん、通常はこの程度のロジックは無視します）

MVC の最大の利点は、表現層 View とモデル Model を分離し、設計上の疎結合（変化への対応）とコードの再利用（View は簡単に交換でき、新しい View のわずかな制御ロジックを変更するだけで済む）を実現していることです。

前述の通り MVC はコンパウンドパターンの一種ですが、どのようなパターンが組み合わされているのでしょうか、見てみましょう：

• オブザーバーパターン：V と C はどちらも M のオブザーバーです（Model の状態更新は V にビューの更新を通知したり、C に論理処理を行うよう通知したりします）
• ストラテジーパターン：C は V の「ストラテジー」です。したがって V に含まれる制御ロジックは「ストラテジーの選択」、つまりコントローラー Controller の選択です。
• コンポジットパターン：V の実装自体にコンポジットパターンが適用されています（トップレベルコンテナの repaint メソッドを呼び出すと、コンテナ内のすべてのコンポーネントが再描画されます）

MVC は複数のパターンを適用し、設計上の一般的な問題をうまく解決できるため、コンパウンドパターンと呼ばれます。

三.従来の MVC と Java ローカルプログラムの MVC

上記から、従来の MVC では具体的なアプリケーションロジックが M に含まれていることがわかります。つまり、モデルオブジェクトは一連のプロパティ（および getter、setter）を持つだけでなく、関連するデータ処理方法も持つ必要があります。

これは Java ローカルプログラムの MVC とは異なります。Java プログラムでは、パッケージを作成してコード構造を階層化します。一般的には以下のようになります：

説明が必要です：

• vo パッケージには通常、各エンティティから抽象化されたクラスが含まれます（bean というパッケージ名を使うこともありますが、意味は同じで、エンティティのプロパティと対応する getter、setter のみを含み、アプリケーションロジックは含みません）
• dao と core はどちらも service の補助層であり、3 層合わせて Controller にマッピングされます

Java ローカルプログラムの MVC と従来の MVC の最大の違いは、Java における M がより純粋（クリーン）で、単純な値オブジェクトのみを含み、アプリケーションロジックを全く含まないことです。ほぼすべてのロジックが Controller 内に格納されています（さまざまな Concrete Service クラス）。

最後に：

コンパウンドパターンを適用した成熟したフレームワークは MVC 一つだけではありません。他のフレームワークについてはまだ触れていないため、軽率に評論することはできません。

unfamiliar なフレームワークに直面したときは、まず設計的な角度から内部実装を簡単に分析してみましょう。例えば、どのようなデザインパターンが適用されているか、各層の機能と層間の相互作用などです。

基礎的なデザインパターンをいくつか理解することは、フレームワークを迅速に受け入れるのに役立ちます。フレームワークの内部実装を理解して初めて、それを自由に使いこなすことができるのです。