私は同僚からデザインに反対されており、この場合のSRPの適用について誰が正しいかについてコンセンサスがあるかどうか疑問に思っています。
SRPは、主にクラスの責任など、設計の下位レベルの詳細に関連していると思います。抽象化のレベルが上がるにつれて、SRPは依然として適切であると思いますが、単一の責任の定義も必然的に、より高いレベルの抽象化に向かって移動します。
私の特定のケースでは、「fooを処理し、その結果を保存し、それらの結果へのアクセスを提供する」サービスは、「foo処理サブシステム」の単一責任を負っていますが、同僚はこれに同意せず、これを2〜3個の別個のものと見なしています。責任。私の場合、あなたが常に単一の責任を詳細に分解する場合、「銀行」を持つことは「お金を保持し、口座を維持し、住宅ローンを販売する...」ので、SRPの違反です。
ソフトウェア設計の多くの原則と同様に、これは非常に主観的なもののように思えますが、そうではないかのように議論されることがよくあります。「単一の責任」の定義は不十分であり、何を責任とみなすかによって異なります。1 つのコードが明らかにやりすぎている場合があり、その懸念をぶら下げるためのフックがあると便利ですが、それが常に切り詰められた評価であるふりをするのはばかげています。
あなたはおそらく正しいと思いますが、この原則を使用して紛争を解決することはできません. ロバート・マーティンは、責任を「変化する理由」と定義しています。foo の構造が変更された場合 (たとえば、フィールドが追加された場合)、その変更をこのクラスに反映する必要があります。あなたの同僚のアプローチでは、すべてのクラスを変更する必要があります。これは、アプリケーション層のコンテキスト内で原則を適用する必要がある場所です。これは、明らかに同じクラスであってはならない表示コードも変更するためです。ストレージ メカニズムが変更された場合 (たとえば、別のデータベース ドライバーを使用する場合)、これは永続構成を介して外部で処理されると予想されるため、変更する他の理由をクラスから除外するだけで、誰もが満足できます。
私はあなたの同僚に同意しません。
単一の責任の粒度は、モデリングしているレベルと一致する必要があります。抽象化のレベルが上がるにつれて、責任の粒度もより高いレベルの抽象化に向かって移動する必要があります。
銀行の例について言えば、その唯一の責任は金融サービスを提供することです。
この概念は、作業分解構造のように機能します。降りて部門の集まりを「見る」と、それらは独自の単一の責任を持つことになります。したがって、責任も崩壊する可能性があります。重要なのは内訳が揃っていることです。
この場合、私はあなたの同僚に同意します。ストレージと処理は、「変更する理由」が異なるため、分離する必要があります。
あなたが挙げた銀行の例について言えば、銀行は住宅ローンを売っていないと私は主張します。ローン部門 (または何でも) は住宅ローンを販売しており、銀行にはローン部門があります。「銀行」を 1 つのオブジェクトとして扱うことは、1 人の人物が銀行全体を運営することに相当します。