「結合が低く凝集力が高い」とはどういう意味ですか

声明の理解に問題がありlow in coupling and high in cohesionます。私はグーグルでこれについて多くを読みましたが、それでも理解するのは難しいと感じています。

私が理解しているのHigh cohesionは、特定の機能を実行するために特化したクラスが必要であることです。これが正しいと思いますか？クレジットカードのみの検証に特化したクレジットカード検証クラスのように。

それでも、低カップリングの意味がわかりませんか？

私が信じているのはこれです：

凝集度とは、モジュール/クラスの要素が一緒に属している度合いを指します。関連するコードは互いに近接している必要があるため、高い凝集度を追求し、すべての関連するコードをできるだけ近くにバインドする必要があります。これは、モジュール/クラス内の要素に関係しています。

カップリングとは、さまざまなモジュール/クラスが互いに依存し合う度合いを指します。すべてのモジュールを可能な限り独立させることをお勧めします。そのため、カップリングは低くなります。異なるモジュール/クラス間の要素に関係しています。

全体像を視覚化することは役に立ちます：

スクリーンショットはCourseraから取得したものです。

ソフトウェアエンジニアリングにおける結束とは、現実の世界と同様に、全体を構成する要素（この場合はクラスとしましょう）が実際に一緒に属していると言える程度です。したがって、これは、ソフトウェアモジュールのソースコードによって表される各機能がどれだけ強く関連しているかの尺度です。

オブジェクト指向の観点からまとまりを見る1つの方法は、クラスのメソッドがプライベート属性のいずれかを使用しているかどうかです。

ここでの議論はこれよりも大きくなりますが、高凝集度（または凝集度の最良のタイプ-機能凝集度）は、モジュールの一部がグループ化されたときに発生します。

カップリング簡単な言葉で、どのくらいの1コンポーネントは（再び、必ずしもクラスを想像して、ではないが）、それは他のコンポーネントの持っているつまり、どのくらいの知識、内部の仕組みや、他の1の内側の要素を知っているされています。

疎結合とは、システムまたはネットワーク内のコンポーネントを相互接続して、それらのコンポーネントが実際には可能な限り最小限に相互に依存するようにする方法です...

これについてブログに投稿しました。例などを使用して、これらすべてについて詳細に説明します。また、これらの原則に従う必要がある利点についても説明します。

ソフトウェア設計では、凝集度が高いということは、クラスが1つのことと1つのことを非常にうまく行う必要があることを意味します。高い凝集性は単一責任の原則と密接に関連しています。

カップリングが低いことは、クラスの依存関係が可能な限り最小限であることを示唆しています。また、存在しなければならない依存関係は弱い依存関係でなければなりません-具体的なクラスへの依存よりもインターフェイスへの依存を優先するか、継承よりも構成を優先してください。

高い凝集力と低い結合力により、メンテナンスが容易な優れた設計のコードが得られます。

短く明確な答え

• 高い凝集度：1つのクラス/モジュール内の要素は、機能的に一緒に属し、特定の1つのことを行う必要があります。
• 疎結合：異なるクラス/モジュール間での依存関係は最小限でなければなりません。

低カップリングは、2つ以上のモジュールのコンテキストにあります。1つのモジュールでの変更が他のモジュールで多くの変更をもたらす場合、それらは高度に結合されていると言われます。これは、インターフェイスベースのプログラミングが役立ちます。モジュール間のインターフェース（対話の平均）が変更されていないため、モジュール内の変更は他のモジュールに影響を与えません。

高い凝集性-同様のものを組み合わせます。したがって、クラスには、関連する仕事を行うためのメソッドまたは動作が必要です。誇張された悪い例を示すだけです。Listインターフェースの実装には、Stringに関連する操作があってはなりません。Stringクラスには、Stringに関連するメソッドとフィールドが必要です。同様に、Listの実装には対応するものが必要です。

お役に立てば幸いです。

私が理解しているように、長いストーリーは短く、低いカップリングは、システムの適切な機能に影響を与えることなくコンポーネントを交換できることを意味しました。基本的にシステムをモジュール化して、システムを壊すことなく個別に更新できる機能するコンポーネントにします。

スマートフォンはありますか？大きなアプリは1つですか、それともたくさんありますか？あるアプリが別のアプリに応答しますか？別のアプリをインストール、更新、アンインストールするときに、あるアプリを使用できますか？各アプリが自己完結型であることは、高い結束力です。各アプリが他のアプリから独立していることは、カップリングが低いことです。DevOpsはこのアーキテクチャを支持します。これは、システム全体を中断することなく、個別の連続展開を実行できることを意味します。

継承または一般化は、高い結合（つまり、高い相互依存性）の例です。つまり、継承では、親クラスが子クラスで使用される基本機能を定義し、親クラスのメソッドの変更が子クラスに直接影響を与えることがよくあります。したがって、クラス間にはより大きな相互依存関係があると言えます。

インターフェースの実現または使用は、凝集度が高い（つまり、相互依存性が低い）例です。つまり、インターフェイスはそれを実装するクラスのコントラクトを提供しますが、各クラスは独自の方法でインターフェイスで宣言されたメソッドを実装する権利を持ち、1つのクラスで宣言されたメソッドの変更は他のクラスに影響しません。

結束 -すべてが互いにどの程度密接に関連しているか。
カップリング -すべてが互いにどのように接続されているか。

例を挙げましょう-自動運転車を設計します。

（1）モーターが正常に作動する必要があります。

（2）自分で運転する車が必要です。

（1）モーターの始動とモーターの稼働を一緒にすることで、クラスと機能のすべてが機能しますが、車の操縦には役立ちません。したがって、これらのクラスをEngine Controllerの背後に配置します。

（2）のすべてのクラスと機能は、車の操舵、加速、ブレーキに最適です。車の始動を助けたり、ガソリンをピストンに送ったりすることはありません。したがって、これらのクラスを独自のドライビングコントローラーの背後に配置します。

これらのコントローラーは、使用可能なすべてのクラスおよび関数との通信に使用されます。その後、コントローラーは相互にのみ通信します。つまり、アクセルペダルクラスからピストンクラスの関数を呼び出して、車の速度を上げることはできません。

ペダルクラスは、ドライビングコントローラーにエンジンコントローラーと通信するように要求する必要があります。エンジンコントローラーは、ピストンクラスに速く進むように指示します。これにより、プログラマは問題を見つけることができ、心配することなく大きなプログラムを組み合わせることができます。これは、コードがすべてコントローラーの背後で機能していたためです。

低結合と高結合は推奨される現象です。

カップリングとは、さまざまなモジュールがどの程度相互依存しているか、およびモジュールの一部/かなりの機能の変更時に他のモジュールがどのように影響を受けるかを意味します。依存性を低く維持して、他のモジュールに最小限の/無視できる変更が加えられるようにする必要があるため、低結合が強調されます。

例が役立つかもしれません。データを生成し、それをディスク上のファイルまたはデータベースのいずれかのデータストアに配置するシステムを想像してください。

データストアコードをデータ生成コードから分離することにより、高い凝集性を実現できます。（実際には、ディスクストレージとデータベースストレージを分離しています）。

低結合は、データ生成がデータストアの不必要な知識を持たないようにすることで実現できます（たとえば、ファイル名やデータベース接続についてデータストアに問い合わせないようにします）。

これは、抽象的でグラフの理論的な角度からの回答です。

ステートフルオブジェクト間の（有向）依存関係グラフのみを見て問題を単純化しましょう。

非常に単純な答えは、依存関係グラフの2つの制限的なケースを検討することで説明でき ます。

第1の制限ケース：クラスターグラフ。

クラスターグラフは、高い凝集性と低い結合（クラスターサイズのセットを前提とする）依存関係グラフの最も完全な実現です。

クラスター間の依存関係は最大（完全に接続）であり、クラスター間の依存関係は最小（ゼロ）です。

これは、限定的なケースの 1つにおける答えの抽象的なイラストです。

2番目の制限ケースは完全に接続されたグラフで、すべてがすべてに依存します。

私の控えめな理解では、現実はその中間にあり、クラスターグラフに近いほど良いです。

別の観点から：有向ディペンデンシーグラフを見るとき、理想的には非循環である必要があります。

階層を1つ上または下に移動すると、ソフトウェアの疎結合、密結合の「1つのインスタンス」に対応しますが、この疎結合/密凝集の原理を、非巡回有向グラフ（またはそのスパニングツリーの1つ）。

このようなシステムの階層への分解は、指数関数的な複雑さを克服するのに役立ちます（各クラスターに10の要素があるとしましょう）。次に、6つのレイヤーでは、すでに100万のオブジェクトです。

10個のクラスターが1つのスーパークラスターを形成し、10個のスーパークラスターが1つのハイパークラスターを形成するなど、緊密な凝集、疎結合の概念がないと、このような階層型アーキテクチャーは不可能です。

したがって、これはストーリーの本当の重要性であり、2つの層内のみでの高い凝集性と低い結合だけではありません。より高いレベルの抽象化とそれらの相互作用を検討すると、真の重要性が明らかになります。

赤の定義はたくさんあると思いますが、まだ疑問がある場合、またはプログラミングに不慣れでこれに深く入りたい場合は、このビデオ（https://youtu.be/HpJTGW9AwX0）をご覧になることをお勧めします これは、ポリモーフィズムに関する詳細情報を取得するための参照にすぎません...これで理解が深まることを願っています

低カップリング：-非常にシンプルに保ちます。モジュールを変更すると、他のモジュールにどのように影響しますか。

例：-サービスAPIがJARとして公開されている場合、メソッドシグネチャに変更を加えると、呼び出しAPI（高/密結合）が壊れます。

モジュールと他のモジュールが非同期メッセージを介して通信する場合。メッセージを取得する限り、メソッド変更シグネチャはモジュールに対してローカルになります（低カップリング）。

もちろん、メッセージ形式に変更がある場合は、呼び出し側のクライアントに変更を加える必要があります。