責任重視の設計

責任駆動設計は、オブジェクト指向プログラミングにおける設計手法であり、クライアント サーバー モデルを使用してカプセル化を改善します。オブジェクトが責任を負うアクションとオブジェクトが共有する情報を考慮して、契約に重点を置きます。Rebecca Wirfs-Brockと Brian Wilkersonによって提案されました。

責任駆動設計は、クラスの動作とそれが保持するデータの定義を促進するデータ駆動設計とは正反対です。データ駆動設計は、クラス設計ではなく、データを使用して制御フローを決定することに関係するデータ駆動プログラミングとは異なります。

彼らが言及するクライアント・サーバーモデルでは、クライアントとサーバーは両方ともクラスまたはクラスのインスタンスです。特定の時点では、クライアントまたはサーバーのいずれかがオブジェクトを表します。両者は契約を結び、それに従って情報を交換します。クライアントは契約で指定された要求のみを行うことができ、サーバーはこれらの要求に応答する必要があります。^[1]したがって、責任駆動設計では、要求の実行方法などの詳細に対処することを避け、代わりに特定の要求の意図のみを指定します。その利点は、要求が実行される正確な方法の仕様がサーバーにプライベートであるため、カプセル化が向上することです。

サーバーのカプセル化をさらに進めるために、Wirfs-Brock 氏と Wilkerson 氏は、クラスの動作に対する外部の影響を制限する言語機能を求めています。彼らは、メンバーと関数の可視性を、Eiffelプログラミング言語のように細かく制御することを要求しています。クラスの可視性をさらに細かく制御できるのは、 Newspeakプログラミング言語です。

責任駆動設計は、オブジェクトをその責任によって特徴付けられる動作抽象化として重視します。CRCカードモデリング手法は、これらの動作抽象化を生成するために使用されます。データ属性を含むオブジェクト構造の残りの部分は、必要に応じて後で割り当てられます。^[2]これにより、設計は継承の型階層に従うようになり、カプセル化が向上し、抽象クラスを識別しやすくなります。また、クライアントに基づいてクラスをグループ化することもできます。これは独自の機能と見なされています。

優れたオブジェクト指向設計では、規定された要件を満たす機能を実現するための動作に早い段階で焦点を当て、実装の詳細を要件に後から結び付けます。このアプローチは、特に制御を分散化し、システムの動作を分散するのに役立ち、高機能の大規模システムや分散システムの複雑さを管理するのに役立ちます。同様に、認知モデル、インテリジェントエージェント、その他の知識ベースシステムの説明機能を設計および維持するのにも役立ちます。^[3]

著者らは著書『オブジェクト設計：役割、責任、コラボレーション』 [ ^4]の中で、責任主導型設計を構成する以下の構成要素について説明しています。

• アプリケーション：ソフトウェアアプリケーションは、相互作用するオブジェクトの集合体として参照されます。^[5]
• 候補: 候補または候補オブジェクトは、CRCカードに記述されたオブジェクトの形をとる重要な概念です。これらは、オブジェクト設計プロセスにおける最初の発明として機能します。^[6]
• コラボレーション：コラボレーションは、オブジェクトまたはロール（またはその両方）の相互作用として定義されます。^[5]
• CRCカード：CRCは候補者、責任者、協力者を意味します。初期のデザインでは候補者を記録するために使用されていたインデックスカードです。^[7]これらのカードは、罫線のない面と罫線のある面に分かれています。
  • 罫線面の内容：この面には候補者の名前、職務、協力者が記録されます。^[7]
  • 無地面の内容：この面には、応募者の名前、応募目的、ステレオタイプの役割、参加するパターンの役割名など、価値のあることが記録されます。^[7]
• ホットスポット：ホットスポットとは、アプリケーション内で変動が発生するポイントです。ホットスポットカードを使用して記録されます。^[8]
• ホットスポットカード: ホットスポットカードは、重要な違いを区別できる程度の詳細で変化を記録するために使用されます。CRCカードと同様に、これもインデックスカードから作成されます。^[8]これらのカードは次のもので構成されています。
  • ホットスポット名
  • 変異の一般的な説明
  • 変動が発生する具体的な例を少なくとも2つ

オブジェクトは、機械のような動作をし、一緒に接続することで連携して動作できるものとして説明されます。これらのオブジェクトは明確に定義された役割を果たし、スクリプト化された応答と情報をカプセル化します。^[5]

• オブジェクト近傍:サブシステムの別名。^[9]協力者の論理的なグループです。^[9]
• 責任：責任とは、タスクを実行したり情報を知る義務のことです。^[5]これらは使用シナリオに応じてさらに分類されます。
  • 公的責任：公的責任とは、オブジェクトが他者に提供するサービスや情報に対する責任である。^[10]
  • 私的責任：私的責任とは、オブジェクトが公的な責任をサポートするために行うアクションです。^[10]
  • サブ責任：時には、大きな責任や複雑な責任がサブ責任と呼ばれる小さな責任に分割されることがあります。^[11]サブ責任は、実行内容に基づいてさらに分類されます。
    • 従属責任：これには各従属責任における主要なステップが含まれます。^[11]
    • 責任の順序付け：これは従属責任の実行の順序付けを指します。^[11]

オブジェクトロールとは、オブジェクトが提供する一般的なサービスの外観を指します。これは関連する責任の集合です。^[5]クラスまたはインターフェースとして実装できます。ただし、インターフェースは、最終的に作業を行う具体的なクラスを隠すことで柔軟性を高めるため、推奨される実装です。^[12]

役割のステレオタイプ：役割のステレオタイプは、事前に定義された責任を伴う簡略化された役割です。^[13]いくつかのカテゴリがあります。

• コントローラ：この役割を実装するオブジェクトは決定を下し、他のオブジェクトのアクションを厳密に指示します。^[13]
• コーディネーター：この役割は、他の人にタスクを委任することでイベントに対応します。^[13]
• 情報保有者：情報保有者は情報を知り、提供する。^[13]
  • 情報提供者：情報保持者の若干の変化形が情報提供者であり、情報の管理と維持においてより積極的な役割を果たします。この区別は、設計者がより具体的に表現する必要がある場合に使用できます。^[14]
• インタフェーサー：この役割は、アプリケーションの異なる部分間で情報と要求を変換します。^[13]さらに、より具体的な役割に分割されます。
  • 外部インターフェース：外部インターフェースは、自身のアプリケーションではなく他のアプリケーションと通信します。^[14]主に非オブジェクト指向APIをカプセル化するために使用され、あまり連携しません。^[15]
  • 内部インターフェース：インターシステムインターフェースとも呼ばれる。^[14]オブジェクト近傍間の橋渡しとして機能します。^[15]
  • ユーザーインターフェース：ユーザーインターフェースは、UIで生成されたイベントに応答し、それをより適切なオブジェクトに渡すことでユーザーと通信します。^{[14] [15] [16]}
• サービスプロバイダー：この役割は作業を実行し、コンピューティングサービスを提供します。^[14]
• 構造化者：この役割は、オブジェクト間の関係とそれらの関係に関する情報を維持します。^[14]

責任主導設計プロセスにおける重要な部分は、制御責任の分配であり、その結果として制御スタイルが開発されます。制御スタイルは、サブシステム間の制御フローに関係します。

• 制御の概念：クラス間の責任と協力。^[17]
• コントロールセンター：コントロールスタイルを開発する上で重要な側面は、いわゆるコントロールセンターの発明です。コントロールセンターは、制御と調整を担うオブジェクトが存在する場所です。^[18]
• コントロール スタイルのバリエーション: コントロール スタイルには、3 つの異なるバリエーションがあります。ただし、コントロール スタイルは他のコントロール スタイルよりも集中化または委任化されていると言えるため、これらは正確な定義ではありません。

この制御スタイルは、アプリケーションの構造に手続き型パラダイムを適用し、主要な意思決定の責任を少数のオブジェクトまたは単一のオブジェクトにのみ割り当てます。

種類

• コールリターン モデル: アプリケーション内のオブジェクトの制御は階層的に行われます。制御はルートから始まり、下方向に移動します。これはシーケンシャル モデルで使用されます。
• マネージャーモデル: アプリケーション内のオブジェクトの制御は 1 つのオブジェクトのみで行われます。一般的には並行モデルで実装されます。case文を使用して順次モデルで実装することもできます。

利点

• アプリケーション ロジックは 1 か所にまとめられます。

デメリット

• 制御ロジックが過度に複雑になる可能性がある
• 管理者は情報保有者のコンテンツに依存する可能性がある
• オブジェクトはコントローラのアクションを通じて間接的に結合される可能性がある
• 唯一の興味深い作業はコントローラーで行われます

いつ使うか

下すべき決定が少なく、単純で、単一のタスクに関連する場合。

委任型制御スタイルは、集中型制御スタイルと分散型制御スタイルの中間に位置します。このスタイルでは、意思決定の一部とアクションの大部分が、制御センターを囲むオブジェクトに渡されます。各隣接オブジェクトには、重要な役割があります。これはイベント駆動型モデルとも呼ばれ、イベントの処理を要求するオブジェクトに制御が委任されます。

種類[参考]

• ブロードキャストモデル: イベントはアプリケーション内のすべてのオブジェクトにブロードキャストされます。イベントを処理できるオブジェクトが制御を取得できます。
• 割り込み駆動モデル:割り込みを処理する割り込みハンドラがあり、それを処理するために何らかのオブジェクトに渡します。

利点

• 分かりやすいです。
• 外部コーディネーターが存在しても、オブジェクトはよりスマートになり、何をすべきかを認識し、他のアプリケーションで再利用できるようになります。
• 委任コーディネーターは、支配コントローラーよりも少ないオブジェクトについて知っている傾向があります。
• ダイアログはより高レベルです。
• 通常、変更によって影響を受けるオブジェクトは少ないため、変更は簡単です。
• チームメンバー間で設計作業を分割しやすくなります。

デメリット

• 責任の分散が多すぎると、オブジェクトが弱くなり、コラボレーションも弱くなる可能性がある。

いつ使うか

より専門的なオブジェクトに作業を委任したい場合。

この制御スタイルは、集中制御スタイルのバリエーションであり、制御はアクションが調整されたオブジェクトのグループ間で要素化されます。^[19]クラスター化制御スタイルと委任制御スタイルの主な違いは、クラスター化制御スタイルでは意思決定オブジェクトが制御センター内に配置されているのに対し、委任制御スタイルでは意思決定オブジェクトはほとんどが外部にあることです。^[20]

分散制御スタイルには制御センターは存在しません。ロジックはオブジェクト全体に分散され、各オブジェクトは小さく保たれ、オブジェクト間の依存関係は可能な限り少なくなります。^[21]

利点

• なし

デメリット

• 何かがどのように動作するかを知りたい場合は、多くのオブジェクトにわたるサービス要求のシーケンスをトレースする必要があります。
• 単一のオブジェクトがあまり役に立たないため、再利用性は低い

いつ使うか

一度もない。

広範囲にわたる実験の結果、委任型制御スタイルと集中型制御スタイルの利点をプログラマーに活用するために必要なスキルを持っているのは上級管理職のみであることが判明しました。中間レベルの従業員については何も言及されていません。^[17]

• オブジェクト指向設計: 責任主導型アプローチ。オブジェクト指向プログラミング システム、言語、アプリケーションに関する会議議事録 (米国ルイジアナ州ニューオーリンズ、1989 年 10 月 2 日～6 日)。OOPSLA '89。ACM Press、ニューヨーク、NY、71-75 ページ。
• Wirfs-Brock, Rebecca; McKean, Alan (2002 年 11 月)。『オブジェクト デザイン: 役割、責任、コラボレーション』。Addison Wesley。ISBN 978-0-201-37943-3。