SRP では、「責任」は通常「変更する理由」として説明されるため、各クラス (またはオブジェクト?) には、誰かがそこにアクセスして変更する必要がある理由が 1 つだけある必要があります。
しかし、これを極限まで細かく考えると、オブジェクトが 2 つの数値を加算することは責任であり、変更の理由となる可能性があると言えます。したがって、オブジェクトには他のロジックを含めないでください。他のロジックを含めると、別の変更理由が生じるからです。
少し客観性に欠ける単一責任の原則である「スコープ設定」に関する戦略を持っている人はいるのだろうか?
ベストアンサー1
それは、モデル化しているもののコンテキストに帰着します。私は SOLID 原則について広範囲にわたる執筆とプレゼンテーションを行っており、単一責任に関する議論の中であなたの質問に具体的に答えています。
以下の記事は、Code Magazine 2010年1月/2月号に掲載されたもので、オンラインでもご覧いただけます。「一歩ずつ進む SOLID ソフトウェア開発」
単一責任の原則では、クラスには変更する理由が 1 つだけある必要があるとされています。
これは、最初は直感に反しているように思えるかもしれません。クラスには存在する理由が 1 つだけあるべきだと言った方が簡単ではないでしょうか。実際、存在する理由が 1 つしかないという状況は、簡単に極端になり、メリットよりもデメリットの方が大きくなります。その極端にまで行き着いて、存在する理由が 1 つだけのクラスを作成すると、クラスごとにメソッドが 1 つしかなくなる可能性があります。これにより、最も単純なプロセスでもクラスが大量に発生し、システムが理解しにくくなり、変更も難しくなります。
クラスが存在する理由が 1 つではなく、変更する理由が 1 つであるべき理由は、システムを構築しているビジネス コンテキストです。2 つの概念が論理的に異なる場合でも、それらが必要とされるビジネス コンテキストでは、それらを 1 つにまとめる必要がある場合があります。クラスを変更するタイミングを決定する際の重要なポイントは、概念を純粋に論理的に分離することではなく、概念に対するビジネスの認識に基づいています。ビジネスの認識とコンテキストが変わった場合、クラスを変更する理由があります。1 つのクラスが持つべき責任を理解するには、まず、そのクラスによってカプセル化される概念と、その概念の実装の詳細がどこで変更されると予想されるかを理解する必要があります。
たとえば、車のエンジンについて考えてみましょう。エンジンの内部の仕組みを気にしますか? ピストン、カムシャフト、燃料インジェクターなどのサイズが特定されていることを気にしますか? それとも、車に乗ったときにエンジンが期待どおりに作動することだけを気にしますか? もちろん、その答えは、エンジンを使用する必要がある状況によって完全に異なります。
自動車工場で働く整備士であれば、エンジンの内部構造に関心があるでしょう。エンジンの具体的なモデル、さまざまな部品のサイズ、その他の仕様を知る必要があります。これらの情報がなければ、エンジンを適切に修理することはできないでしょう。しかし、A地点からB地点までの移動だけが必要な平均的な日常生活者であれば、そのレベルの情報はおそらく必要ないでしょう。ピストン、スパークプラグ、プーリー、ベルトなど個々の部品の概念は、あなたにとってほとんど意味がありません。あなたが気にするのは、運転している車にエンジンが搭載されていて、それが正しく機能することだけです。
エンジンの例は、単一責任原則の核心に直結しています。自動車の運転とエンジンの整備というコンテキストは、単一の概念であるべきものとそうでないものについての 2 つの異なる概念、つまり変更の理由を提供します。エンジンの整備というコンテキストでは、すべての個別のパーツを別々にする必要があります。それらを単一のクラスとしてコード化し、すべてが個々の仕様に準拠していることを確認する必要があります。ただし、自動車の運転というコンテキストでは、エンジンは単一の概念であり、それ以上細分化する必要はありません。この場合は、おそらく Engine という単一のクラスになります。どちらの場合も、コンテキストによって適切な責任の分離が決定されます。