.net - 次の例で単一責任の原則について混乱している

Question

次のビデオでは、作成者は既存のクラスを取得し、それに単一責任原則を割り当てています。彼は、データへのアクセス、フォーマット、およびレポートの印刷を担当する印刷クラスを受講します。彼は各メソッドを独自のクラスに分割するため、データアクセスを処理するDataAccessクラスを作成し、レポートのフォーマットを処理するReportFormatterクラスを作成し、レポートの印刷を処理するReportPrinterクラスを作成します。次に、元のReportクラスには、ReportPrinterのクラスメソッドPrintを呼び出す1つのメソッドPrint（）が残ります。DataAccessとReportFormatterに責任があるように見えますが、ReportPrinterはDataAcessとReportFormatterに依存しているので、これはSRPを壊しませんか、それとも私はそれを誤解していますか？

Answer 1

単一責任の原則は、特定のクラスが単一の責任（または「変更する理由」）を持つ必要があることを示しています。それ自体は、その責任がどのように満たされるかを示すものではありません。そのためには、共同作業者として他の複数のクラスの協力が必要になる場合があります。

Answer 2

ビデオを見なくても、それは合理的なデザインのように聞こえます。データアクセスを処理するメソッドはReportPrinterクラスに表示されないため、SRPは壊れていません。「必要なデータを取得するために、何かを呼び出すことができる」という概念のみです。

もう少しプッシュして、データアクセスクラス、フォーマッタークラス、およびプリンタークラスのアクティビティの調整のみを担当するコーディネータークラスを作成することもできます。また、コーディネーターがデータをフォーマッターに送信し、フォーマッターがプリンターにデータを送信し、コーディネーターがプリンターについて（直接）認識しないなど、さまざまな方法でオブジェクトを配置することもできます。

焦点の狭いオブジェクトの作業を調整することについて、何かを知る必要があります。それが彼らの責任になります。他のオブジェクトがどのように機能するかを知らない、または気にしない限り、他のオブジェクトが何をするかについてのアイデアや概念を知っていてもかまいません。インターフェイスを「責任の継ぎ目」と考えることは良いスタートです。

また、オブジェクトを「実行」するのではなく、相互にデータを渡すものと考える場合にも役立ちます。したがって、ReportFormatterは、（概念的に）既存のレポートでオブジェクトを実行するのではなく、フォーマットされたレポートを表す新しいオブジェクトを返します（または転送します）。

Answer 3

いいえ。SRPを壊すことはありません。

と仮定する

DataAccess implements IDataAccess    

ReportFormatter  implements IReportFormatter 

ReportPrinter implements IReportPrinter 

ただし、イベントReportPrinter relies on DataAccess and ReportFormatterの契約の変更は、それぞれIDataAccess or IReportFormatterによって実装する必要がありDataAccess and ReportFormatter ます。ReportPrinter それらのクラスでの責任の変更について心配する必要はありません。

MediatorCompositionパターンを使用または実装して、これら3つのクラス間の緩い結合を提供し、作業を完了することができます。一部をから遠ざけてください。couplingresponsibility

Answer 4

SRPは依存関係に対応していません。クラスを単一責任クラスに分割すると、後でそれらの依存関係を簡単に分割できます。SRPは、一緒に言及されている2つの原則の1つである凝集度と結合度に対応しています。SRPは高い凝集度であり、依存関係は高い結合度を示している可能性があります。優れた設計では、凝集度が高く、結合度が低くなります。これらの2つの原則が相反する場合があります。