videoでは、作成者は既存のクラスを取り、それにSingle Responsibility Principleを割り当てます。彼は、データへのアクセス、書式設定、およびレポートの印刷の仕事を持つ印刷クラスを取る。彼は各メソッドを独自のクラスに分割し、データアクセスを処理するDataAccessクラスを作成し、ReportFormatterクラスを作成してReportの書式を処理し、ReportPrinterクラスを作成してReportの印刷を処理します。元のReportクラスには、ReportPrinterのクラスメソッドPrintを呼び出すPrint（）メソッドが1つ残っています。 DataAccessとReportFormatterは責任を持っているように見えますが、ReportPrinterはDataAcessとReportFormatterを使用しているため、SRPを壊したり、誤解していませんか？以下の例では、単一の責任原則について混乱しています
単一責任原則は、特定のクラスが単一の責任（または「変更理由」）を持つ必要があることを示します。その責任はどのように満たされるべきかを示すものではありません。そうすることで、他の複数のクラスの協力者としての協力が必要になることがあります。
SRPは依存関係に対処していません。クラスを単一責任クラスに分割すると、後でその依存関係を解除することが容易になります。 SRPは、一緒に言及された2つの原則のうちの1つ、Cohesion and Couplingの1つに取り組んでいます。 SRPは約高い凝集力であり、依存性は高い結合性を示す可能性がある。良いデザインは、高い結合力と低い結合性を持っています。ときには、これらの2つの原則が不安定になることがあります。
ビデオを見ることなく、合理的なデザインのように聞こえる。 SRPは壊れていません。データアクセスを扱うメソッドがReportPrinterクラスには表示されないため、「必要なデータを取得するために何かを呼び出せる」という概念のみが表示されます。
これを少し押して、データアクセスクラス、フォーマッタクラス、およびプリンタクラスのアクティビティを調整するだけのコーディネータクラスを持つことができます。また、コーディネーターがデータをフォーマッターに送信してプリンターに送信し、コーディネーターがプリンターについて（直接的に）認識しないように、さまざまな方法でオブジェクトを配置することもできます。
狭く絞ったオブジェクトの取り組みを調整するために何かを知っておく必要があります。それが彼らの責任となります。あなたが知らないかケアしていない限り、他のオブジェクトが行うことのアイデアや概念について知っていてもかまいません。how彼らはそれを行います。インターフェースを「責任の継ぎ目」と考えることは良いスタートです。
オブジェクトを「実行」するのではなく、互いにデータを渡すものとしてオブジェクトを考えると便利です。したがって、ReportFormatterは、既存のレポートで（概念的に）オブジェクトを実行するのではなく、書式設定されたレポートを表す新しいオブジェクトを返す（または転送する）。
いいえSRPを壊さない。
はDataAccess implements IDataAccess
ReportFormatter implements IReportFormatter
ReportPrinter implements IReportPrinter
イベントReportPrinter relies on DataAccess and ReportFormatterものの、IDataAccess or IReportFormatterの契約に何らかの変化がそれぞれDataAccess and ReportFormatterによって実施されるべきであると仮定します。 ReportPrinterは、これらのクラスの責任の変更について心配しません。
Compositionを指定するか、Mediatorパターンを実装して、これらの3つのクラス間で緩やかな結合を行い、ジョブを完了させることができます。 部分をresponsibilityから離れた場所に保管してください。
私は、実装全体の単一のクラスが4つの別々のクラスよりも高い結合性を持っていると主張します。単一のクラスは、データアクセス、書式設定、および印刷の実装に結合され、4つの別々のクラスは各クラスの定義にのみ結合されます。より多くのクラスがあるからといって、カップリングが高いことを意味するわけではありません。 –