問題タブ [law-of-demeter]

私は昨日休暇から仕事に戻ってきました。私たちの毎日のスタンドアップで、私のチームメイトは、Java コード内のすべてのモデル オブジェクトをリファクタリングして、すべてのゲッターとセッターを削除し、代わりにモデル フィールドをすべてパブリック オブジェクトにすることについて言及しました。そうする理由としてのデメテル

デメテルの法則を順守しやすくするため: モジュールは、操作する「オブジェクト」の内部について認識してはなりません。データ構造には動作が含まれていないため、内部構造が自然に公開されます。その場合、デメテルは適用されません。

LoD に関する知識をブラッシュアップしなければならなかったことは認めますが、これが法律の精神の範囲内であることを示すものは、私の人生では何も見つかりません。私たちのモデルの getter/setter にはビジネス ロジックが含まれていないため、これらのオブジェクトのクライアントは get/set メソッド内で実行されているビジネス ロジックがあるかどうかを理解する必要がありません。

これは、「オブジェクト構造の内部知識」が必要であることの意味を誤解していると思います。少なくとも、文字通りに解釈しすぎて、その過程でかなり標準的な慣習を破っています。

私の質問は、LoD の名前でゲッター/セッターを介してではなく、モデル オブジェクトの内部構造を直接公開することに実際に意味があるのでしょうか?

次のモデル/関連付けのセットがあります。

これはオブジェクト指向の観点からは理にかなっていますが、たとえば、UI でそれを表す NewsItem と Photo.image。

明らかな改善は、ポリモーフィックを省いてMediaItem作成Videoし、Photoポリモーフィックにすることですが、それらを交換可能に扱い、順序付け、ランク付けして検索する必要があり、ポリモーフィック関連付けにより、これが非常に複雑/扱いにくくなります。また、多くの重複した属性 (現在オンになっているものMediaItem) も含まれます。

この設定に関する私の主な問題は、 aNewsItemが視覚的に表現される状況があることです。そのタイトルとともに、そのカバー画像である画像を表示しNewsItemます。事実上、ギャラリーの最初の写真です。

この状況では、私は効果的にこれを行っています:

これらのアイテムが一度に最大 20 個 (おそらくそれ以上) 画面に表示されることを考えると、データベース クエリを最適化する必要がありますincludes。

もちろん、委任の背後にあるアクセスの一部を非表示にするために、大規模な方法を使用できます。たとえば、次のようになります。

しかし、これでも一連のテーブルを含めようとする厄介なクエリが残っています。

これを構造化するより賢明な方法はありますか？

私はhttp://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf (特にページ 8 を参照) を読んで、テスト可能なコードの記述に関する Misko の Youtube ビデオを見ていましたが、Angular DI はデメテルの法則を破るように強制しますか。

Demeter の法則を破る Java コンストラクターの例を PDF から単純化すると、次のようになります。

このクラスは、ユーザーが管理者であるかどうかのみを必要とし、AccountService は必要としないためです。

Angularは、DIでDemeterの法則を破るように強制しているようです。次の代替手段が見つかりません。

これが解決パラメーターを持つルーターのコントローラーであるコントローラーである場合、ユーザーを注入できますが、一般的なケースではできません。何かご意見は？AccountService のみがシングルトンであり、後続の各オブジェクトはインスタンスである (DI できない) と想定していることに注意してください。

デメテルの法則について私が理解したのは：

メソッドはそのクラス内の他のメソッドを直接
呼び出すことができます メソッドはそれ自身のフィールドのメソッドを直接呼び出すことができます (ただし、フィールドのフィールドではできません)
メソッドがパラメーターを受け取る場合、メソッドはそれらのパラメーターのメソッドを直接呼び出すことができます。
メソッドがローカル オブジェクトを作成すると、そのメソッドはローカル オブジェクトのメソッドを呼び出すことができます。

ただし
、グローバル オブジェクトでメソッドを呼び出すべきではありません (ただし、パラメーターとして渡すことはできますか?)
a のクラス以外のクラスにメッセージ a.getB().getC().doSomething() のチェーンを持つべきではありません。

私の方法の1つで私がやっていることはこれです:
final ServiceStatusBean serviceStatusBean = new ServiceStatusBean(); serviceStatusBean.setName("someName"); serviceStatusBean.setApiVersion("someVersion");

私の serviceStatusBean インスタンスはメソッド内でローカルに作成され、そのセッターを呼び出しています。私の理解では、デメテルの法則で問題ありません。しかし、PMD によると、セッターを呼び出す回線でデメテルの法則に違反しています。
警告 - 「デメテルの法則に違反する可能性があります (ローカルで作成されていないオブジェクト)」

これらの PMD 警告の背後にある理由を理解できません。説明はありますか??
PMD の詳細:
プラグイン バージョン - 4.0.5.v20141105-1906
PMD バージョン - 5.2.1

私はそれが悪いと考えられていることを知っています:

また

「大量の->->->->は必要ありません」と説明されていますが、この構造を物理的にしたかったので、切り離すことはできません。アーキテクトが変わればどこでもやらなければならないことは理解していますが、そうはいきません。もう一度、これを回避するにはどうすればよいですか？

クラス Foo があるとします

Foo を使用し、LoD に違反するプログラムがあります

LoD を使用するためのリファクタリングは次のようになります。

IntelliJ-IDEA には多くのリファクタリング メソッドがあります (メソッドへの抽出、変数への抽出、インラインなど)。

bar.getFoo().getX()コードを次のようにリファクタリングする IntelliJ-IDEA のメソッドはありbar.getFooX()ますか?