オブジェクトが存在するドメインについて自問できる質問がいくつかあります。
- このメンバー (メソッド、プロパティなど)は、他のオブジェクトからアクセスする必要がありますか?
- 他のオブジェクトには、このメンバーにアクセスするビジネスがありますか?
カプセル化はしばしば「データの隠蔽」または「メンバーの隠蔽」と呼ばれ、多くの混乱を招くと思います。経験の浅い開発者は、当然のことながら、「コードの残りの部分から何かを隠したいと思うのはなぜですか?そこにあるのであれば、それを使用できるはずです。結局のところ、それは私のコードです。」
あなたのチーム リーダーの返答の仕方にはあまり納得できませんが、彼は非常に良い点を述べています。オブジェクト間の接続ポイントが多すぎると、接続が多すぎます。オブジェクトはますます緊密に結合され、1 つの大きなサポート不可能な混乱に融合します。
アーキテクチャ全体で関心の分離を明確かつ厳密に維持することで、これを防ぐことができます。オブジェクトを設計するときは、パブリック インターフェイスがどのように見えるかを考えてください。外見上、どのような属性や機能を持っているでしょうか? その機能の一部として合理的に期待されないものは、公開すべきではありません。
たとえば、 というオブジェクトを考えてみましょうCustomer。次のような を説明するいくつかの属性を合理的に期待できますCustomer。
また、いくつかの機能が利用できることを期待するかもしれません:
その中に技術的な考慮事項もあるとしますCustomer。たとえば、オブジェクトのメソッドはCustomer、クラスレベルの接続オブジェクトを介してデータベースに直接アクセスする場合があります。その接続オブジェクトは公開する必要がありますか? 現実の世界では、顧客にはデータベース接続が関連付けられていません。したがって、明らかに、公開すべきではありません。これは、 の外部から見えるインターフェイスの一部ではない内部実装の問題Customerです。
もちろん、これは非常に明白な例ですが、要点を示しています。public メンバーを公開するときはいつでも、そのオブジェクトの機能の外部から見える「コントラクト」に追加します。そのオブジェクトを、同じコントラクトを満たす別のオブジェクトに置き換える必要がある場合はどうすればよいでしょうか? 上記の例で、データベースではなく XML ファイルにデータを格納するバージョンのシステムを作成したいとします。外部の他のオブジェクトCustomerが公開データベース接続を使用している場合、それは問題です。の内部実装だけでなく、全体的な設計についてさらに多くの変更を加える必要がありCustomerます。
原則として、最初に最も厳密なメンバーの可視性を優先し、必要に応じてそれらを開くことが通常は最善です。そのガイドラインを、オブジェクトが表す現実世界のエンティティと、それらのエンティティに表示される機能の観点からオブジェクトを考えるアプローチと組み合わせると、特定の状況に対する正しい行動方針を決定できるはずです。