GRASPパターン［情報エキスパートパターン］

情報エキスパートパターン（Information Expert）

概要

責任の遂行に必要な情報を持っているクラスに責任を割り当てる

• なにか処理を行うには情報が必要になる
  • その情報を持っているクラスが自分の情報を使用して処理を行う
    • 現実社会においてごく自然な形になる（会社のお金に関するやりとりは一番それを知っている経理担当者が行う、といった感じ）

メリット

• クラス間の関連を少なくすることができる
  • 情報を渡しあう必要がなくなる
    • 変更に強い疎な結合になる
• 情報のカプセル化を行うことができる
  • 必要でない情報は他人に知られなくて済む

適用すべきでない状況

情報を持っているからといってなんでもかんでもやらせて良い、ということではない

• たとえば「売上情報」を保存するのは誰か？情報エキスパートパターンを当てはめると、保存すべき売上情報を持っているのは「売上情報」そのものだから、「売上情報」にデータベース保存ロジックを持たせたらよいのか？
  • そうすると、「売上情報」がSQLやJDBCに関する情報をもたないといけなくなる、となってしまう。「売上情報」は純粋な「売上情報」に関するロジックだけではなく、いろいろなことをしなくてはいけなくなり、いろいろな責任が伴ってしまう…
    • それは理解しにくい
    • それは再利用しにくい
    • それは保守しにくい
    • それは脆弱で変更による影響を絶えず受ける
  • 上記は「凝集性が低い」と呼ばれる、よくないパターン。似たような処理が色々なクラスに入ることにもなる
    • だからこうした処理は「データベースロジックをあつかうクラス」に集約すると良い。何でもかんでも情報エキスパートにやられるのではなく、時には責任を分割する必要もある