これまでの私の知識では、カップリングは 2 つ以上のクラスが「相互接続」されている程度に関連していると考えていました。つまり、クラスが他のクラスのメソッドまたは変数をどの程度使用するかということです。適切に設計されたソフトウェア システムにおける私たちの目標は、もちろん結合を低く (緩く) 保つことです。
私は現在本を読んでいますが、疎結合の目的はシステムを設計することによって達成され、すべてのクラスが他のクラスの API (パブリックメソッド) のみを使用し、インスタンス変数を直接使用しないように明示的に述べている本を読んでいます。したがって、インスタンス変数はプライベートでなければなりません。それがポイントである場合、疎結合と強力なカプセル化の違いは何ですか? 私に関する限り、後者はカプセル化を指します。オブジェクト指向ソフトウェア開発の上記の概念に関して実際に正しいのはどれですか?
疎結合は、パブリック API を使用するだけでなく、その APIのみを理解し、特定の実装に依存しない機能でもあります。また、実装の違い全体で依存コードに必要な変更量を制限することも含まれます。
カプセル化は、プロパティへの直接アクセスを禁止するだけではありません。また、意図しない動作 (内部構造の防御コピーを返すなど) を引き起こす可能性のある方法で内部データが公開されていないことを確認し、データだけでなく動作が適切に分離され、責任が適切な場所に実装されていることを確認することも含まれます。 .
Loose coupling is properly achieved by the judicious application of strong encapsulation. Weak encapsulation may provide loose coupling but may also introduce loopholes that allow for visibility of methods and variables outside of the abstraction's scope (inadvertant tight coupling). Strong encapsulation however, does not imply anything about coupling since a class of this nature can be designed to couple loosely, tightly, or not at all with external entities.
強力なカプセル化で疎結合を実現することはできますが、カプセル化自体はまだ良好なコードと疎結合を保証するものではありません。カプセル化にもかかわらず、密結合のコードを書くことはできます。
疎結合 (オブジェクト/モジュール間の不必要な依存関係が導入されない規則) は、正式なカプセル化 (アクセサー/セッターおよび制限された可視性) なしで実現できます。
しかし...自分自身または少数の熟練した共同開発者のためにコードを書く場合、クラスメンバーを直接参照する (したがってカプセル化を破る) と、コードを小さくして読みやすく、理解しやすくすることが容易になる場合があります。C# はプロパティで部分的にそれを行っています。これらはプレーンなクラス メンバーのように見えますが、実際にはアクセサーとセッターです。
大規模なチームや再利用可能なコードの場合、強力なカプセル化は必須です。ただし、常に柔軟性に留意する必要があります。API を制限しすぎると、使用できなくなります。これは、コードがまだ「公式」API のすべてのユースケースを処理できるほど成熟していない場合に特に重要です。