web-dev-qa-db-ja.com

SRPは密結合を供給しますか？

私は関数を設計しましたが、その後、2つの非常に異なるタスクを同時に実行していることに気付きました。

したがって、私はそれを2つの異なる関数に分割して、それぞれが実行すべきことだけを実行することを考えています（ [〜＃〜] srp [〜＃〜] ）。明らかに、これらの関数の1つは他の関数のサービスを呼び出します。

しかし、この呼び出しが密結合を増加させると思う傾向があるので、これが本当に良い決定であるかどうか疑問に思います これに従って （？

だから私の質問は：SRPは密結合を増加させますか？

functionssingle-responsibilitycoupling
2
Billal Begueradj

SRPはクラスとモジュールに適用されます。

SRPについては多くの混乱があります。ここでボブおじさんの記事、SRPを「発明」したので、私よりもはるかによく説明されています。要するに：

  • SRPは、クラスが何をするか（クラスの責任）ではありません。したがって、クラスがいくつかのことを実行するという理由だけで、クラスを密結合の双子に分割する必要はありません。

  • SRPは変更する理由についてです（クラスの責任）。それはカプセル化を促進し、知識が最も少ないという原則を促進します。

関数は1つのことを行う必要がありますか？

彼の本ですかクリーンコード、 ncle Bob クラスまたはモジュール内で機能することをお勧めします "事 " 。 SRPのように聞こえるかもしれませんが、非常に異なります。 「小さく保つ」、「関数ごとに1レベルの抽象化」とともに、適切な関数分解を促進します。理解と保守が容易な部品。

もちろん、関数はそれを分解するために作成されたサブ関数に依存します。同じクラス内では、カップリングは避けられません。しかし、これらの内部の詳細を外部の世界に公開しない限り、これは問題ではありません。

4
Christophe

低結合の主な利点の1つは、システムの単一コンポーネントを理解するために同時に考慮する必要のある事項の数が減ることです。これにより、とりわけ、デバッグ、保守、および拡張性が向上します。あなたの質問に答える合理的な方法は、 [〜＃〜] srp [〜＃〜] がこれらのメトリックに関してコードを改善するかどうかを検討することです。

私の主張は、SRPはカップリングを減らす能力を持っているということですが、そのカップリングの減少は保証されていません。これを2つのシナリオで説明します。

シナリオ1（これを行わないでください）

  • 1つのメガ関数foo()から始めます。
  • foo()はSRPに違反しているため、bar()とbaz()に再ファクタリングすることに注意してください。
  • アプリケーションが大きくなると、bar()とbaz()に応じてコードの他の部分が終了します。
  • 顧客とユースケースは時間とともに変化するため、最終的にはfoo()に変更が必要です。 foo()のロジックのほとんどはbar()とbaz()に実装されているため、foo()の動作を変更するには、代わりにbar()とbaz()の動作を変更します。
  • 今、すべてが壊れています。

SRPには結合を減らす機能がありますが（少なくとも私はそう主張しています）、この例では、プログラマーはfoo()、bar()、およびbaz()を単一のユニットとして扱い、そのユニットが複数に分割されるという追加の複雑さを持っています関数の定義、そしておそらく複数のファイル。 SRPは単なる名前であり、機能がどのように使用されているかにより、実際の利点はありませんでした。

シナリオ2（SRPとの結合の減少）

  • 1つのメガ関数foo()から始めます。
  • foo()はSRPに違反しているため、bar()とbaz()にリファクタリングすることに注意してください。
  • アプリケーションが大きくなると、bar()とbaz()に応じてコードの他の部分が終了します。
  • 最終的にはfoo()を変更する必要がありますが、必要な機能を備えた適切な低レベルコンポーネントがないため、新しい関数bizz()を作成します。
  • 現在、foo()はbar()とbizz()で構成されており、それ以外はすべて正常に機能します。

この例では、2つの構成部分をatomicとして扱っているため、foo()の動作については簡単に推論できます。それらは明確に定義された動作を持ち、それらを組み合わせてfoo()を構成します。これらの動作が不十分な場合、目的の機能を備えた新しいアトミックコンポーネントを作成します。このアプローチにより、コードの再利用が容易になり、APIを破壊する変更が防止されます。さらに、すべてのコンポーネントは十分に小さく、簡単に推論して正しいことが証明できます。

Extras：SRPはある意味で結合を減らすことができますが、関数が適切にグループ化されていない場合、アプリケーション内のすべてのモジュールが何らかの形で相互に依存する可能性がありますモジュール。システム全体を疎結合するように設計することは、関数を疎結合するように設計することと同じくらい重要であり、その理由もほぼ同じです。

3
Hans Musgrave