問題タブ [law-of-demeter]

これは私が尋ねている明確なはい/いいえの質問であり、実装に関係なく、法律に違反するかしないかのどちらかであると私は信じています. 私の質問は、エンティティ フレームワーク モデルで作成されたナビゲーション プロパティは、デメテルの法則を破るのでしょうか? 1 つのエンティティがあまりにも多くの知識を持ち、以下のようなナビゲーション プロパティ インスタンスにアクセスできるため、そうしていると思います。

上記のコードOrdersでは、ナビゲーション プロパティを含むメイン エンティティにありますProducts。多くの場合、その関連オブジェクトの詳細にアクセスするには、そのナビゲーション プロパティをドリルダウンする必要があります。一般的にインスタンスプロパティを持つことも法律を正しく破らないと思いますか?

これを解決するための支援が役に立ちます、ありがとう!

私は最近、stackoverflowに質問を投稿しました。

@period_registration.period.event

しかし、私は次のようなことをすることが提案されました：

私の一般的な感覚は、これは少し手間がかかるように見えるということです。この以前の投稿を見て、これにデメテルの法則を適用するにはどうすればよいですか？は、すべてのアソシエーションに対してこれを行った場合に、これがどれほど重くなり得るかを示しています。

Railsではこれはどのくらい一般的な方法ですか？私の考えでは、これが技術的に正しいことであったとしても、それが鉄道文化の一部でなければ、これを行うことは人々を失望させるように思われます。そして、さらに重要なことは、他の開発者がこれらすべてのヘルパーメソッドで時間を無駄にしていると考えているため、実際にコードの保守性を低下させることです。

これを暗示したいとしましょう。@period_registration.event.cityは、都市がイベントの属性であり、個別のオブジェクトもLoDに違反していないか、または別のメソッドを記述して、@period_registration.cityを実行できるようにする必要があります。

私はデメテルの法則に従おうとしています ( http://en.wikipedia.org/wiki/Law_of_Demeter、http://misko.hevery.com/code-reviewers-guide/flaw-digging-into-collaborators/を参照) ) 利点はわかりますが、ドメイン オブジェクトに関しては少し行き詰まっています。

ドメイン オブジェクトには当然チェーンがあり、チェーン全体に関する情報を表示する必要がある場合があります。

たとえば、ショッピング バスケット:

各注文には、ユーザー、配送情報、およびアイテムのリストが含まれています。各注文アイテムには、製品と数量が含まれています。各製品には、名前と価格があります。各ユーザーには名前とアドレスが含まれています

注文情報を表示するコードは、注文、ユーザー、製品に関するすべての情報を使用する必要があります。

上記のすべてのオブジェクトに対してクエリを実行し、それらを個別にコードに渡すコードよりも、「order.user.address.city」などの注文オブジェクトを介してこの情報を取得する方が、確かに優れており、再利用可能ですか?

コメント/提案/ヒントは大歓迎です!

私には位置があり、位置を識別子として使用するいくつかのエンティティ (地理、バイオームなど) があります。それらにアクセスしたい場合は、その位置でそれぞれを取得する必要があり、コードが繰り返されることになります。一方、「場所」のようなコンテナーであるクラスを作成することもできます。しかし、この場合、たとえば地理を取得するには、デメテルの法則を破る必要があります。

これに対する他のアプローチ、または私が見逃している一般的なパターンはありますか? このタイプのオブジェクト (私が説明した方法で位置に関連するもの) は、数か月後に数が増える可能性が非常に高いことに注意してください。

デメテルの法則によれば、オブジェクトはオブジェクトAからオブジェクトBからメソッドMを呼び出すことはできません。しかし、それはプロパティにも適用されますか？例？

私はそのようなことをすることができますか？

または私はこれを行う必要があります：

AからBのメソッドにアクセスした場合、（法律に従って）問題はありますか？

LoDに続くテスト可能なコードを読んでいましたが、頭の中ですべてが台無しになりました。したがって、このコードに関するガイダンスをいただければ幸いです。

コンストラクターの引数がHouse増えるにつれて、コンストラクターを使用してそれを管理することは困難になります。多くの依存関係が渡されます。それは正しいことですか？または、このコードをリファクタリングできるより良い方法はありますか？

編集：Houseコンストラクター引数を参照する

Ruby on Rails（またはコレクションを含む他の言語...）内で、カウントのような単純なものをクエリするときに、デメテルの法則違反を解消する必要がありますか？

「実用的なプログラマー」の演習を考慮して、いくつか質問があります。

それは言う：

1.1。

変数acctはパラメーターとして渡されるため、getBalance呼び出しが許可されます。ただし、amt.printFormat（）の呼び出しはそうではありません。私たちはamtを「所有」しておらず、それは私たちに渡されませんでした。

しかし、私たちはamtを所有していますか？これはメソッドで宣言され、LODは次のように述べています。メソッドがローカルオブジェクトを作成するとき、そのメソッドはローカルオブジェクトのメソッドを呼び出すことができます。

この例はLODを壊していますか？私の見方ではありませんか？

2.2。

ColadaはmyBlenderとmyStuffの両方を作成して所有しているため、addIngredientsとelementsの呼び出しが許可されます。

doSomethingがmyBlenderとmyStuffを作成しなかったため、呼び出しを許可されている理由がわかりません。

3.3。

この場合、processTransactionはamtを所有し、スタック上に作成され、acctが渡されるため、setValueとsetBalanceの両方が許可されます。ただし、processTransactionはwhoを所有していないため、who-> name（）の呼び出しは違反しています。

したがって、ここでは誰を宣言しますが、電話をかけることは許可されていません。おそらく私は「所有者」の概念を誤解しています。

誰かがこれを明確にしてくれませんか？

ありがとう

全体的な設計:それぞれが共通の書き込み専用インターフェイスとクラス固有の読み取り専用アクセサー関数を持つ型のメンバー変数Cを含む集約クラスがあります(実際にはそのような通常の名前はありません)。各メンバー型は、独自の独立した抽象化を形成し、私のプログラムの他の場所で使用されます。NM_i, i = 1 ... N update()[F]un_i(), [F] = any letter, i = 1 .. NM_i

集約クラスは、単一のトランザクションですべてのメンバーを更新する必要があるため、すべてのメンバー変数のメンバー関数をupdate()呼び出す独自の関数があります。update()

質問: 集約クラスのさまざまなメンバー変数のさまざまなメンバー関数にアクセスできますか? 私は3つの選択肢を考えることができます:

代替案 1 : すべてのメンバー変数のすべてのメンバー関数にN * Kデリゲートを書き込むKN

代替 2 : すべてのメンバー変数Nにアクセサーを書き込むN

代替 31 :アクセサ テンプレートをすべてのNメンバー変数に書き込む

代替案 1 は、デメテルの法則に違反することを回避しますが、非常に多くの面倒なボイラー プレート コードが必要です (私のアプリケーションでは、N = 5ラッパーを委譲します)。代替案 2 はラッパーの数を削減しますが、呼び出しコードは少し見苦しく感じます。しかし、そのコードはすべて読み取り専用であり、変更は一貫した集計によってのみ発生する可能性があるため、代替案 2 が代替案 1 よりも望ましい (そして少なくとも安全である) という私の現在の意見です。その場合は、1 つのアクセサーしか使用せず、Alternative 2 と同じ安全性が保証されるため、Alternative 3 が最適な選択となるはずです。K = 315update()

質問: このタイプのコードに適したインターフェイスは何ですか?

「デメテルの法則」とタグ付けされた問題はほぼすべて読みました。私の特定の質問は、これらの他の質問のいずれにも答えられていませんが、非常に似ています. 主に私の質問は、構成のレイヤーを持つオブジェクトがある場合ですが、さまざまなオブジェクトからプロパティ値を取得する必要がある場合です。これをどのように達成し、なぜあるアプローチを別のアプローチよりも優先するのでしょうか?

次のように、他のオブジェクトで構成された非常に標準的なオブジェクトがあるとします。

以下は両方ともデメテルの法則に違反します。

これはまた、デメテルの法則に違反すると思います (明確化?):

したがって、おそらく、「getPrimaryPhoneNumber()」メソッドを Customer に追加します。

そして、次のように呼び出します: System.out.println("Phone: " + customer.getPrimaryPhoneNumber());

しかし、これを時間をかけて行うと、実際には多くの問題が発生し、デメテルの法則の意図に反するように思えます。これにより、Customer クラスは、独自の内部クラスについてあまりにも多くの知識を持つ getter と setter の巨大なバッグになります。たとえば、Customer オブジェクトは、ある日、さまざまなアドレス (「プライマリ」アドレスと「勤務先」アドレスだけでなく) を持つ可能性があるようです。おそらく、Customer クラスでさえ、特定の名前の ContactInfo オブジェクトではなく、単に ContactInfo オブジェクトの List (またはその他のコレクション) を持つことになります。その場合、どのようにデメテルの法則に従い続けますか? 抽象化の目的を無効にしているように見えます。たとえば、Customer が ContactInfo アイテムの List を持っているような場合、これは妥当と思われます。

一部の人々が携帯電話と固定電話を持っていることを考えると、これはさらにおかしなことになり、ContactInfo は電話番号のコレクションを持たなければならないように思えます。

その場合、オブジェクト内のオブジェクト内のオブジェクトを参照するだけでなく、有効な addressType と phoneType が何であるかを知る必要もあります。これには間違いなく問題がありますが、回避する方法がわかりません。特に、これを呼び出しているクラスが何であれ、問題の顧客の「プライマリ」アドレスの「携帯」電話番号を取得したいことをおそらく知っているでしょう。

デメテルの法則に準拠するためにこれをどのようにリファクタリングできますか?また、それがなぜ良いのでしょうか?