問題タブ [law-of-demeter]

上記のコードでは、2つの異なるHouseクラスの定義を確認できます。どちらにもgetTemp（）関数があり、最初はデメテルの法則に違反しますが、2番目の関数はそれを保持します（Head First Design Patternsの本による）。

問題は、2番目のクラスがデメテルの法則を保持している理由がよくわからないことです。getTemp（）関数にはまだstation.getThermometer（）呼び出しがあり、これはデメテルの法則に違反しています。「ドットを1つだけ使用する」-ウィキペディアでこれを見つけましたが、これは当てはまる可能性がありますが、さらに詳細な説明が必要です-「特に、オブジェクトは別のメソッドによって返されるメンバーオブジェクトのメソッドを呼び出さないようにする必要があります」（wiki）。

では、2番目のコード例が法律に違反しない理由を誰かが説明できますか？2番目の方法と最初の方法を本当に区別するものは何ですか？

現在の役割に関連する特定の役割を見つけるために、確かに醜いクエリを実行する必要があります。この行は正しい結果を生成します。

(複数の呼び出しから関連付けを推測できます)

この情報を取得する唯一の方法は、データベースの構造に関する大量の知識を必要としますが、結合を取り除くには...必要な情報を返すために、そのチェーンの各ステップで一連のヘルパー関数を入力する必要があります。 ..

これは素朴な質問かもしれませんが、RSpec のテスト DSL はデメテルの法則に違反していますか?

http://rspec.infoからの RSpec DSL の例を次に示します。

Demeter の観点からは、これは次の例と見分けがつかないように思えます。

Avdi Grimm によると、これはデメテルの法則に違反しています。

ソース: http://devblog.avdi.org/2011/07/05/demeter-its-not-just-a-good-idea-its-the-law/

実用的なプログラミングの原則を維持しようとして、「Tell, Don't Ask」の原則に基づいてユーザー パスワードの変更を処理する方法を決定しようとしています。

パスワードが 30 日ごとに期限切れになるユーザー オブジェクトがあります。パスワードの有効期限が切れている場合、パスワードの有効期限が切れている/パスワードの変更ビューを表示できるようにする必要があります。パスワードの有効期限が切れているかどうか (状態) をオブジェクトに尋ねてから、表示するビューを選択することは、原則に違反しているように思えます。

この状況を処理する最善の方法は何ですか?

データモデルオブジェクトがありますUser。私のアプリには、他にもいくつかのデータモデルオブジェクトがForkありOptionsます。たとえば、ユーザーにはフォークとブランチがあります。私のアプリは、ユーザー/フォーク/オプションなどの情報を組み合わせて多くのクエリを実行する必要があります。たとえば、ユーザーのフォークのページを表示できます。これには、フォークでそのユーザー（セッションにログインしているユーザーなど）を結合するクエリが必要になります。

私はデメテルの法則に違反したくありません。また、一般的にゲッター（およびセッター）にも反対しているので、User::getID()またはを実装したくありませんUser::getUsername()。

しかし、代替案は私にはそれほど良くは思えません。結局起こったことは、Userこれらのクエリを実行するためにさまざまなメソッドを実装することです（例User::getForks()）。一般的にこれは機能しますが、Userクラスはモノリシックになり、それ自体が悪いです。

さらに、2つのデータモデルオブジェクトのクエリをどのように解決するかがわかりません。たとえばUser、IDを持つaとIDを持つaForkがあり、フォークがユーザーに属していることを確認したい場合があります。これにはFork、IDをユーザーに公開するUserか、IDをに公開するかFork、または両方がIDをコントローラー（またはその他）に公開する必要があります。これらはどれも望ましいとは思えず、どちらを選択すればよいかわかりません。私が見逃している他の選択肢はありますか？

別の同様の手順で、ビューに情報を追加するための最良の方法がわかりません。私はビューオブジェクトを持っており、通常は、のようなメソッドを使用します。このメソッドは、1User::addForksToView(View $view)つまたは複数のクエリを実行し、いくつかの処理を実行しますが、これにより、のサイズと責任も増大しUserます。これも同様の問題だと思います。

OK、検索しましたが、私の問題に適した解決策が見つかりませんでした。POS システムの一部を再設計しています。次のクラスがあるとします。

今、私が直面している問題は、デメテルの法則に違反することなく最善のアイデアを見つけようとすることです. 私が達成しようとしていることは次のとおりです。

1. 新しい TSales が保存されるたびに、それを現在のユーザーの TWorkShift の Sales リストに追加し、販売額を TWorkShift の「TotalSold」に合計したいと考えています。

私は2つの異なるアプローチを試しました：

アプローチ A:

// ID 1 の勤務シフトがあり、データベースから次のようにロードされるとします。 CurrentShift := TWorkShift.Create(1);

このアプローチの問題は、一部のクラスまたは別の場所 (おそらく新しいクラス?) で合計のロジックをカプセル化したいため、テストが難しいことです。

アプローチ B:

私の他のアプローチは、TSale クラス自体の中にそのコードを含めることです。

このアプローチは、デメテルの法則に違反していると思いますし、私には正しくないと感じています。

コードの単純さと将来のメンテナンスの容易さを最大化する「正しい方法」を見つけたいと思っています。したがって、任意の提案をいただければ幸いです。

ありがとう

を含む単純なStoreクラスがありますInventory。にはのInventoryリストが含まれていますItem。の の1 つを変更するには、次ItemのInventoryように記述する必要があります。

私が理解しているように、これはデメテルの法則を破っStoreています。InventoryItemsetPrice()

この法律違反を、ペーパーボーイと顧客の典型的な例における法律違反と調和させたいと思います。ペーパーボーイの例では、ペーパーボーイは、顧客が財布で支払いを行うと想定することで、顧客について「よく知っている」。顧客の支払い方法が変われば、ペーパーボーイも変更しなければなりません。

ペーパーボーイの例で発生したような問題を引き起こす可能性がある、コード内のどのような仮定が行われていますか?

法律は実際にはガイドラインであり、この場合それを遵守することは最善の考えではないことを理解していますが、先に進む前に少なくとも法律を理解したい. ありがとう。

ABAPのデメテルの法則の違反を検出して解決したい。</p>

焦点はクラスレベルにあります。誰かがいくつかのアイデアや記事を持っていますか？

返信してください

よろしくyinxiao