GRASPパターン – Controllerパターン（コントローラーパターン）
Controllerパターンの提唱するもの
システムイベント（クリックなど）の処理を行う責務割り当てについて提唱している。
考察
デザインパターンで有名なMVCパターンにおいて、C（コントローラー）の部分がControllerパターンに当てはまっている。
もうひとつ他の例をあげると、GUIプログラムでボタン押下などのイベント発生時に、ボタンを保持しているクラスに処理を直接記述する（従来のVisualBasicのようなイメージ）のではなく、イベントを一括して受け取るコントローラーオブジェクトを用意しておき、そのオブジェクトが処理の決定を行うようにする。
メリット
- イベントの捕獲を一括して行うので、責務が分散しない。
ものすごく単純な例
MVCモデルでの基本的な図を示す。
図１：MVCモデルの処理フロー
図１：MVCモデルの処理フロー
- クライアントがリクエストを送信（イベントの発生）
- リクエストを受け取ったコントローラーは処理フローをモデルに移す
- モデルは処理を行い、処理結果をコントローラーに返す
- コントローラーはビューに対し、処理フローを移す
- クライアントはビューを受け取る
GRASPパターン – Creatorパターン（生成者パターン）
Creatorパターンが提唱するもの
Creatorパターンはオブジェクト生成を行う責務をどのように割り当てるか提唱している。具体的には、そのクラスを包括しているクラスがインスタンスの生成を行うことが望ましいとされている。
考察
Creatorパターンの原則に従わず、関係のないクラスにインスタンス生成を任せると、クラス同士の関係が複雑になり、保守性が低下してしまう。基本的に、クラスの包括関係を表す階層図を作成し、各々のクラスは自分が保持しているクラスのインスタンス生成を行うようにする。
メリット
- 再利用性の向上
- 責務分散の抑止
ものすごく単純な例
シナリオ
Mainクラスはデータベースにクエリを送信した結果をCSVクラスに渡す。CSVクラスはStreamWriterクラスを使用してファイル出力を行う。
Mainクラスはデータベースにクエリを送信した結果をCSVクラスに渡す。CSVクラスはStreamWriterクラスを使用してファイル出力を行う。
始めにインスタンスの包括関係を表した階層図を考える。
Creatorパターンを意識して考えると、階層図において相対的に自分の下に位置するクラスのインスタンスを生成することになる。上記の例ではMainクラスがCsvクラスのインスタンス生成を行い、CsvクラスがStreamWriterクラスのインスタンスを生成する。
コードでの例(Java)
○
class Main{
public static void main(String[] args){
// 処理省略
Csv csv = new Csv()
// 処理省略
}
}
class Csv{
public Csv(){
StreamWriter writer = new StreamWriter("c:\test.txt");
// 処理省略
}
}
×
class Main{
public static void main(String[] args){
// 処理省略
StreamWriter writer = new StreamWriter("c:\test.txt");
Csv csv = new Csv(writer)
// 処理省略
}
}
class Csv{
public Csv(StreamWriter writer){
// 処理省略
}
}
GRASPパターン – Expertパターン（情報エキスパートパターン）
Expertパターンが提唱するもの
Expertパターンは、オブジェクト指向での責務割り当ての基本を提唱している。オブジェクトに責務を割り当てる際に、その責務を満たすことができる情報を保持しているクラスに責務の割り当てを行う。
考察
オブジェクト指向のポイントのひとつであるカプセル化を意識して設計を行っていれば、Expertパターンを満たしていることが多い。これは「各クラスは必要な情報とその情報に対する操作が定義される」というカプセル化の原則と、Expertパターンが提唱している責務の割り当て方針が一致するためである。
メリット
- 情報をもっているクラスが、その情報に対する操作の責任を担うため、クラス同士の余計な関連を少なくすることが出来る。
- 各クラスの責務がシンプルになるので、理解しやすい設計を行うことが出来る。
ものすごく単純な例
以下のように、幅と高さの情報を保持している図形クラスがある
図１：図形クラス
図１：図形クラス
ここで「面積を管理する」という責務をどのように与えたらよいのか考える。面積を算出するには図形の幅と高さの情報が必要となる。Expertパターンを意識して設計を行った場合、必要な情報は図形クラスが保持しているため、面積管理の責務も図形クラスに与えることになる。
図２：面積管理の責務を割り当てた図形クラス
以下に、責務を図形クラスに割り当てなかった場合の例を示す。
図３：面積管理の責務を他のクラスに割り当てた場合（一例）
図からも読み取れるように、余計な関連が増えてしまっている。
プロフィール
@hacker634
へなちょこシステムエンジニア。Java,PHP,C#,JS,Objective-C,DB,なんでも好きです。ヘビーな言語もLLも全部好き。SIer→受託屋→フリーランス→ちびっこWEB開発会社勤務（いまココ）担当は、ディレクション、アーキテクト、設計、開発、テスト、保守、研究、雑用、デザイン。つまり、なんでも屋。 Follow @hacker634-
リンク
