「結合度が低く、凝集度が高い」とはどういう意味ですか
ステートメントlow in coupling and high in cohesionの理解に問題があります。私はグーグルでこれについて多くのことを読みましたが、それでも理解するのは難しいと感じています。
私が理解しているのは、High cohesionは、特定の機能を実行するために特化したクラスが必要であることを意味します。これが正しいことを願っていますか？クレジットカードのみを検証するために特化されたクレジットカード検証クラスのように。
そして、低カップリングの意味がまだわかりませんか？
私はこれが信じている：
凝集度とは、モジュール/クラスの要素がどの程度一緒に属しているかを指します。関連するコードは互いに近接していることが推奨されます。モジュール/クラス内の要素withに関係しています。
カップリングとは、異なるモジュール/クラスが互いに依存する度合いを指します。すべてのモジュールが可能な限り独立していることが推奨されるため、カップリングは低くなります。異なるモジュール/クラスの要素amに関係しています。
全体像を視覚化することは役立ちます：
スクリーンショットは Coursera から取得されました。
ソフトウェア工学における結束は、実生活と同様に、全体を構成する要素（この場合はクラスとしましょう）が実際に一緒に属していると言える程度です。したがって、それは、ソフトウェアモジュールのソースコードによって表される各機能がどれほど強く関連しているかの尺度です。
凝集度をOOの観点から見る1つの方法は、クラス内のメソッドがプライベート属性のいずれかを使用している場合です。
議論はこれよりも大きくなりましたが、High Cohesion（または結束の最良のタイプ-機能的結束）は、モジュールの一部がすべて単一のウェルに貢献するためにグループ化される場合です。モジュールの定義済みタスク。
Couplingは、単純な言葉で言えば、1つのコンポーネントが（必ずしもではありませんが、クラスを想像してください）別のコンポーネントの内部の動作または内部要素、つまりどのくらいの知識を知っているかです他のコンポーネントを持っています。
疎結合は、システムまたはネットワーク内のコンポーネントを相互接続して、それらのコンポーネントが実際に可能な限り最小限に依存するようにする方法です…
私はブログ記事を書きました これについて。このすべてを例などとともに詳細に説明します。また、これらの原則に従うべき理由の利点についても説明します。
ソフトウェア設計では、高い凝集度は、クラスが1つのことと1つのことを非常にうまくやるべきことを意味します。高い凝集力は、 単一責任原則 と密接に関連しています。
低カップリングは、クラスに可能な限り依存性が少ないことを示唆しています。また、存在しなければならない依存関係は弱い依存関係である必要があります-具体的なクラスへの依存よりもインターフェイスへの依存を優先するか、継承よりも合成を優先します。
凝集度が高く、結合度が低いと、コードの設計が改善され、保守が容易になります。
低結合とは、2つ以上のモジュールのコンテキストです。 1つのモジュールの変更が他のモジュールの多くの変更をもたらす場合、それらは高度に結合されていると言われます。これは、インターフェイスベースのプログラミングに役立ちます。モジュール内のインターフェース（相互作用の平均）は変更されていないため、モジュール内の変更は他のモジュールに影響しません。
高い凝集性-同様のものをまとめます。したがって、クラスには、関連するジョブを実行するためのメソッドまたは動作が必要です。誇張された悪い例を挙げます。Listインターフェースの実装には、Stringに関連する操作がありません。 Stringクラスには、メソッド、Stringに関連するフィールドが必要です。同様に、Listの実装には対応するものが必要です。
お役に立てば幸いです。
短くて明確な答え
- 高凝集度：1つのクラス/モジュール内の要素は機能的に一緒に属し、1つの特定のことを行う必要があります。
- 疎結合：異なるクラス/モジュールの中で、最小限の依存関係にする必要があります。
私が理解したように、長い話、短い低結合は、システムの適切な機能に影響を与えることなくコンポーネントを交換できることを意味していました。基本的に、システムを破壊せずに個別に更新できる機能コンポーネントにシステムを変調します
スマートフォンはありますか？大きなアプリは1つありますか、それとも小さなアプリはたくさんありますか？あるアプリは別のアプリに返信しますか？別のアプリをインストール、更新、アンインストールするときに使用できますか？各アプリが自己完結型であることは、高い凝集度です。各アプリが他のアプリから独立していることは、低カップリングです。 DevOpsは、システム全体を中断することなく、個別の継続的な展開を行えることを意味するため、このアーキテクチャを採用しています。
例を参考にしてください。データを生成して、データストア（ディスク上のファイルまたはデータベース）に格納するシステムを想像してください。
データ生成コードからデータストアコードを分離することにより、高い凝集度を実現できます。 （実際、データベースストレージからディスクストレージを分離します）。
データ生成がデータストアについて不必要な知識を持たないようにすることで、低結合を実現できます（たとえば、ファイル名やデータベース接続についてデータストアに問い合わせません）。
以下は、抽象的でグラフ理論的な角度からの回答です。
ステートフルオブジェクト間の（有向）依存関係グラフのみを見て、問題を単純化します。
非常に単純な答えは、依存グラフの2つの ケースの制限 を考慮することで説明できます。
最初の制限ケース：a クラスターグラフ 。
クラスターグラフは、高い凝集度と低いカップリング（クラスターサイズのセットが与えられた）依存関係グラフの最も完全な実現です。
クラスター間の依存関係は最大（完全に接続）で、クラスター間の依存関係は最小（ゼロ）です。
これは、 限定的なケース の1つでの答えの抽象的な図です。
2番目の制限ケースは完全に接続されたグラフであり、すべてがすべてに依存しています。
私の謙虚な理解では、現実はその中間にあり、クラスターグラフに近いほど良いです。
別の観点から：有向依存グラフを見るとき、理想的には非周期的である必要があります。そうでない場合、サイクルは最小のクラスタ/コンポーネントを形成します。
階層の1段階上/下は、疎結合、ソフトウェアの密結合の「1つのインスタンス」に対応しますが、この疎結合/密結合の原理は、非循環有向グラフのさまざまな深さでの繰り返し現象として見ることができますそのスパニングツリーの1つ）。
このようなシステムの階層への分解は、指数関数的な複雑さを克服するのに役立ちます（たとえば、各クラスターには10個の要素があります）。次に、6層ですでに100万個のオブジェクトになっています。
10個のクラスターが1個のスーパークラスターを形成し、10個のスーパークラスターが1個のハイパークラスターを形成するなど...緊密な結合、疎結合の概念がなければ、このような階層アーキテクチャは不可能です。
したがって、これはストーリーの真の重要性であり、2つのレイヤー内のみでの高い凝集性と低結合性だけではありません。より高いレベルの抽象化とそれらの相互作用を考慮すると、実際の重要性が明らかになります。
継承または一般化は、高い結合（つまり、高い相互依存性）の例です。これが意味することは、継承では多くの場合、親クラスがその子クラスで使用される基本機能を定義し、親クラスのメソッドの変更がその子クラスに直接影響することです。したがって、クラス間の相互依存度が高いと言えます。
インターフェースの実現または使用は、高い凝集度（つまり、低い相互依存性）の例です。つまり、インターフェイスはそれを実装するクラスのコントラクトを提唱しますが、各クラスには独自の方法でインターフェイスで宣言されたメソッドを実装する権利があり、あるクラスで宣言されたメソッドの変更は他のクラスには影響しません。
Cohesion-すべてが互いに密接に関係していること。
カップリング-すべてを相互に接続する方法。
例を見てみましょう-自動運転車を設計したいと思います。
（1）モーターが正常に動作する必要があります。
（2）自力で運転するには車が必要です。
（1）モーターを起動し、モーターを正常に動作させるためのクラスと機能はすべて一緒に動作しますが、車の操縦には役立ちません。そのため、これらのクラスをエンジンコントローラーの背後に配置します。
（2）のすべてのクラスと機能は、車を操縦、加速、および制動するのに最適です。彼らは車の始動を助けたり、ガソリンをピストンに送ったりしません。そのため、これらのクラスを独自のドライビングコントローラーの背後に配置します。
これらのコントローラーは、使用可能なすべてのクラスおよび機能と通信するために使用されます。その後、コントローラーは相互にのみ通信します。これは、車を速くするために、ガスペダルクラスからピストンクラスの関数を呼び出すことができないことを意味します。
ペダルクラスは、ドライビングコントローラーにエンジンコントローラーと通信するように要求する必要があり、エンジンコントローラーはピストンクラスに高速化を指示します。これにより、プログラマーは問題を見つけることができ、心配することなく大きなプログラムを組み合わせることができます。これは、コードがすべてコントローラーの背後で機能していたためです。
低結合と高凝集が推奨される現象です。
カップリングとは、さまざまなモジュールがどの程度相互依存しているか、およびモジュールの一部/かなりの機能を変更したときに他のモジュールがどのように影響を受けるかを意味します。依存性を低く維持する必要があるため、他のモジュールに最小限/無視できる変更が加えられるように、低結合が強調されます。