19

高い凝集度は単一責任原則の同義語ですか？そうでない場合、それらはどのように異なりますか？

4

4 に答える 4

18

あなたは尋ねました：そうでなければ、彼らはどのように違うのですか？

単一責任の原則

この原則が意味すると思うものは何でも捨ててください。

ロバートC.マーチンは、この原則を公式に次のように定義しています。

クラスには変更する理由が1つだけあるはずです

SRPを定義するほとんどの人は正しくありません。SRPは通常、次のように誤って説明されます。

「EmployeeクラスはすべきではありませんUpdateDemographics()、そしてSendMessage()、それは2つの責任として数えられます...SendMessage()メッセージクラスに入れられます!!」

^^間違っています

vv右

ロバートC.マーチンは言います

「責任は「コードが行うこと」ではありません」。（NDC 2012）

ロバートC.マーチンはSRPを次のように定義しています。

「どのモジュールも、[役割]の1人だけに責任を負わなければなりません。」（NDC 2012）

利害関係者がビューのデータソートの変更を要求した場合、管理者はびっくりしてアルゴリズムが壊れることを心配するべきではありません。ビューでの並べ替えを処理するモジュールは利害関係者のみを担当し、合計計算アルゴリズムを処理するモジュールはビジネスアナリストのみを担当するためです。 したがって、ビジネスアナリストがアルゴリズムに変更を加えるように要求した場合、ビューが変更されることを恐れてはなりません。

したがって、モジュール（単数）は1つの理由でのみ変更する必要があります。このモジュールがサービスを提供する単一の個人-役割が変更を要求しました。

これをSRPの定義の新しい基盤として使用すると、以前はSRPであったと思っていたものを適用して、定義をもう少し細かくすることができます。すべてのフロントエンドコードを1つのモジュールに入れ、すべてのバックエンドコードを1つのモジュールに入れるとは誰も言っていません。

高い凝集度

decimal CalculatePayFor(Employee)ある方法と別の方法があると想像してくださいvoid Pay(Employee)

これらは一緒に属しますか？あらゆる種類の計算を実行するサービスが存在する可能性があり、Human-ResourcesPaymentSOAPをラップするだけのサービスが存在する可能性があります。おそらくPay(Employee)呼びかけますがCalculatePayFor(Employee)、彼らが彼らの中に言葉を持っているからといって、Pay彼らが一緒に属しているという意味ではありません！

どうすれば結束を作ることができますか？- あなたはそうしない。結束はあなたが観察するものです。あなたがしていることは、一緒に属するものをバラバラにしないでください。

必要なすべてのパブリックメソッドのクラスを作成することができます。各クラスには1つのパブリックメソッドがあり、すべてが明確に定義された混乱です。名前付きのクラスがPayrollClass1ありPayrollClass2、1つは一方向で計算を行い、もう1つは双方向で計算を行うためです。

一部の言語は、クラスが完全に欠如していることから恩恵を受け、メソッドは無料で実行されます。メソッドのグループ化はありません。メソッドは、いつでも呼び出すことができる単なるメソッドです。それらはすべてほとんど静的です。

しかし、あなたはそれを観察CalculatePayFor(Employee)することができ、Pay(Employee)実際には非常に高度にバインドされています。彼らはまるで夫婦のようで、一緒に見栄えがします。メソッドが明らかに一緒に属している場合、それらを分解したくありません。彼らの自然状態を観察し、野生生物保護区を設立します。これは高い凝集度を維持しています。あなたはそれを作成しません、あなたはそれを観察します。

これが本当に役立つのは、適切なコードの複製です。たとえばPayrollService.CalculatePayFor(Employee)、とまったく同じコードがありReportService.CalculatePayFor(Employee)ます。これは悪いですか？もちろん違います。上級管理職が報告のために従業員の給与の計算に変更を加えるように要求した場合、それは、HRが実際の支払い方法の税務上の計算に変更を加えるように指示した場合とは異なる責任です。

「待って、彼はSRPとCohesionを混同しただけですか？」いいえ、でもあなたが混乱を認識してくれてうれしいです。ReportServiceがPayrollServiceのクラスに到達し、そのメソッドを使用した場合はどうなりますか？その後、正当な支払い目的で変更されると、レポートはすべて変更されます...しかし、経営陣はそれを望んでいませんでした!!! したがって、Cohesionはメソッドを独自のクラスに保持し、SRPはモジュールをアプリケーション内に保持するように強制するため、ReportServiceはPayrollServiceクラスからメソッドをコピー/貼り付けするように強制されます。今、それらは互いに独立して変化することができます。

「しかし、それがあなたが望むものでない場合はどうなりますか？」さて、重複が除外されているコードの場所はたくさんあります。ただし、アルゴリズムがそれ自体に固執し、依存関係とは無関係に変更するのが最も一般的です。それが重複を意味するとしても。何が必要かによります。ただし、関心の分離、単一責任、結束、およびDRY（Do n't Repeat Yourself）はすべて別個のアイデアです。

補足：DRY重複がないという意味ではありません。私が述べたように：ビジネスルールはさまざまな懸念事項の間で類似しており、変更する理由が異なるため、多くの場合、重複したコードが存在する可能性があります。

于 2016-01-12T23:11:12.250 に答える
7

同じことではありません。

単一の責任だけではない、非常にまとまりのあるクラスを持つことができます。

于 2012-06-26T20:09:33.777 に答える
3

同義語ではありません。SRP（Single Responsibility Principle）は、クラスが1つの責任のみを持つようにする場合です。確かにこれはあなたのクラスの結束を高めます。

しかし、手紙にSRPを従わなくても、高い結束力を持つことができます。

これについての良い情報源があります。

于 2012-06-26T20:41:52.517 に答える
1

ロバート・マーティン自身の言葉で、

[SRP]について考えると、これが凝集度と結合度を定義するもう1つの方法であることがわかります。同じ理由で変化するものの間の凝集度を高め、異なる理由で変化するものの間の結合を減らしたいと考えています。

参照：単一責任の原則と関心の分離の違い。

于 2019-03-04T21:35:59.590 に答える