GRASPパターン［高凝集性パターン］

高凝集性パターン（High Cohesion）

「凝集性」（ぎょうしゅうせい）とは

一般的には

• 集団の中にいる人たちが、互いに魅力を感じている「程度」のこと。この程度が高いほど、仲間意識が強くなり、一致団結して行動するようになる

GRASPパターンでは

• 要素の責任がどの程度強く関係し、集束されているかを示す尺度のこと（ここでいう「要素」とはクラス・サブクラス）
  • 高い凝集性を持つ、というのは、以下のこと
    • 関係性の高い責任を持つ
    • あまり多くの作業をしない
  • 逆に凝集性が低い場合、関係ない仕事をこなしたり、仕事が多すぎたりする、という状態

概要

オブジェクトの焦点を明確にし、わかりやすく、凝集性が高くなるように責任をわりあてる、という考え方

• このパターンは、「生成者パターン」とか「情報エキスパートパターン」など、他のパターンと切り離して考えることはできない
  • 設計のあらゆる意思決定において考慮する必要がある（あらゆる設計における原則、だということ）

メリット

• 設計の明確さと理解しやすさが高まる
• 保守と拡張が容易になる
• 関係性の強い、適度に細分化された機能の再利用性が促進される
  • 凝集性が高いクラスは限定された目的に使用できるから

凝集性の「度合い」

非常に低い凝集性

• 機能が大きく異なる複数の分野の仕事を1つのクラスが単独でおこなう
  • このような場合、まず分野ごとにクラスを分け、さらに仕事ごとにクラスを分ける、というのが必要

低い凝集性

• 1つの分野での複雑なタスクの責任を1つのクラスが単独でおこなう
  • すべてのデータベースにアクセスするための処理を1つのクラスでやっている、というような状態
    • この場合、作業を複数のクラスで分担させる必要がある

高い凝集性

• クラスが1つの機能分野で適度の責任を持ち、タスクを遂行するために他のクラスと協調する
  • こういうクラスは以下の特徴がある
    • 機能の関連性が強い
    • メソッドが少ない
    • コード量が少ない
    • 仕事の量が少ない
  • 理解しやすく、保守や再利用も容易になる
  • 現実社会で考えても、本来は別の人に委譲されるべき責任を背負わされると、その人の能力がうまく使えなくなるのに似ている
    • こういう人は強いストレスを感じる

適用できない状況

低凝集性をあえて受け入れなければいけない場合もある

• 1人の担当者によって保守しやすくするために、コードや責任を1つにまとめる
  • SQLの超スペシャリストが大規模プロジェクトに1人しかいないという状態だとすると、そのスペシャリストが保守しやすいようにSQL関連のクラスを1つにまとめる、という場合
    • かえって保守しにくくなる場合もあるけどね
• レスポンスを考慮しなくてはいけない場合
  • （リモート操作呼び出しなど）、1度の処理に時間がかかるような状況の場合、1つのクラスに1度にいろいろな仕事をさせた方が呼び出し回数が減り、レスポンスが高くなる可能性がある場合