問題タブ [law-of-demeter]

これはデメテルの法則に違反していますか?

これはどう？

デメテルの法則に従いたい。「2つのドット」を検索するコードを調べていると、このタイプのコンテキストで委任の責任を設定する価値があるかどうかを自問自答しています。

から

に

あなたの考えは何ですか？

Misko Hevery によるGoogle のクリーン コード トークを見てきました。これらの話は次のように述べています: コンストラクターで依存関係を要求して、他のプログラマーが特定のオブジェクトのインスタンスをインスタンス化するために必要なものを事前に正確に確認できるようにします (デメテルの法則)。これにより、プログラマーは何をモックする必要があるかを正確に把握できるため、テストが容易になります。

例の時間
クラスがあり、データ アクセスを抽象化Customerするクラスもあるとします。CustomerDAO顧客オブジェクトを作成するときは、次のようにします。

これは私のコントローラーで発生する可能性があります。依存性注入コンテナを使用することで、このオブジェクトの構築を簡素化できます。以下では、DI コンテナーを使用してデータベース クラスのインスタンスを取得しました。これは、アプリケーション全体で広く使用されているためです。これにより、構築コードが 1 か所に減り、テスト用にモックできます。

ドメイン クラスの依存関係 (この場合は DAO オブジェクト) を DI コンテナーに追加する必要がありますか? アプリケーションが大きい場合、DI コンテナーは巨大になりますか?

DI コンテナーを使用すると、コードは次のようになります。

別のプログラマーが をテストしたい場合はCustomer、 mock だけが必要CustomerDAOです。

この例をさらに一歩進めると、他のドメイン クラスに依存するドメイン クラスがある場合、私の DI コンテナーはすべてのドメイン クラスを構築する方法を知る必要がないはずです。例えば：

私の顧客は会社/機関であり、したがって多くのユーザーがいます。

問題

1. DI コンテナーをオブジェクトに渡していCustomerないため、データベース DSN への参照がないため、上記のようにユーザー オブジェクトを作成できません (ユーザーの作成方法を知る必要はありません)。
2. 独自の依存関係を作成すると、モック用の継ぎ目がなく具体的​​であるため、このコードをテストできなくなります。
3. コンテナを自分のCustomerクラスに渡すと、インターフェイスがCustomer嘘になりますか? (リンクされた Google ビデオの 9:15 を参照)。

オブジェクトCustomerを構築できるようにするには、ユーザー ファクトリを渡す必要がありますか?User

の構造をUserFactoryDI コンテナに入れる必要がありますか?

これは不自然な例です。たとえば、ある人が友達を持っている国の人口をリストしたい場合、以下に2つの設定を示します。モデルでデータを繰り返すのが最善でしょうか？

デメテルの法則に従うことが重要だと言われました。例としては、犬に歩くように指示する場合、足に歩くように命令するのは愚かです。

People.where(:country => friend.country)私の豊富な経験のなさ（noob）で、モデルがデータを繰り返す場合、 （これまで不可能だった）連鎖した関連付けがあるコレクションと比較して、クエリがはるかに簡単になることがわかりました:(People.where(:city => { :county => { :region => { :country => friend.city.county.region.country }}}) これは本当にこのnoobに役立ちますここで、正しい工夫されたLoDの設定と構文を想像できれば、概念を理解できます。デメテルの法則とは関係のない例を使用しなかったことを願っています）LoDを適用してみdelegateたところ、まだ連鎖している（私はそうです）が、私が考えることができる唯一の解決策は、関連付けを介してアクセスできるデータを繰り返すことです。

しかし、私はデータを繰り返すのが嫌いです！これは、Twitterを再作成するDHHのRailsのチュートリアルをフォローしているためです。彼は、関係を作成することとデータを繰り返すことの素晴らしさを示しました。

アソシエーションの連鎖を少なくするには、データを繰り返すことが適切である必要がありますか？

モデル、繰り返しデータ

vs連鎖関連のあるモデル

私は最近いくつかの読書をしていて、デメテルの法則に遭遇しました。今、私が読​​んだもののいくつかは完全に理にかなっています。たとえば、紙の少年は顧客のポケットをライフル銃で撃ち、財布をつかんでお金を取り出すことは決してできないはずです。ウォレットは、ペーパーボーイではなく、顧客が管理する必要があるものです。

法則について私を悩ませているのは、おそらく私は全体を誤解しているだけかもしれませんが、機能/情報の階層と一緒にプロパティを文字列化することは非常に役立つ可能性があるということです。例：.NETsHTTPContextクラス。

次のようなコーディングはしません：

または

または

この法律を破っていますか？私は（おそらく誤って）OOPのポイントは、部分的には、優れた階層構造で関連するクラスへのアクセスを提供することだと思いました。

たとえば、ページクラスで使用できるユーティリティツールキットを参照して、メールの送信や便利な文字列メソッドのカプセル化などの反復的なタスクを回避するというアイデアが好きです。

どんな明快さも素晴らしいでしょう...現時点では、法律が文字列のプロパティとメソッドを一緒に追放するように見える方法を調整することはできません...あまりにも多くの力を無視する必要があるのは私には奇妙に思えますか？ご想像のとおり、私はOOPにかなり慣れていないので、簡単に行ってください:)

私のアプリでは、Photo has_and_belong_to_many :land_uses

Photoモデルに次のヘルパー メソッドがあります。

これはコードの匂い (デメテル) のように感じますが、LandUse モデルに移動する方法を理解できませんでした。私がやりたいことは次のようなものです：

そのため、呼び出す代わりに を呼び出すphoto.land_use_listことができますphoto.land_uses.list。

しかし、特定の写真に属するスコープされたインスタンスに対して呼び出されるのではなく、クラスに対して呼び出されるため、これは機能しません。

私が考えていることを行う方法はありますか？そして、より一般的に言えば、アプリでこのような問題にどのようにアプローチしますか? リスト コードを LandUse モデルに移動することは正しいアプローチですか、それとも別の方法をお勧めしますか?

イベントが関係するプログラミング環境のデメテルの法則を調整しようとしています-両方ともイベントを許可するため、このjavascriptとobj-c（CocoaのNSNotificationCenter）にタグを付けました。

このような環境では、イベントをスローしてバインド/サブスクライブするだけで、任意の2つのオブジェクトを任意に分離できます。obj-cでは、メソッドを呼び出す必要のあるオブジェクトへの参照を渡す代わりに、これを行う方がはるかに簡単です。これはおそらく常に使用するのは良くないと思います。パフォーマンスの観点から、メソッドディスパッチの最適化を見逃します（巨大なアプリでない限り、おそらく無視できます）。読みやすくするために、プログラマーは、あるオブジェクトが別のオブジェクトの依存関係であることを明示したい場合があります。これは、オブジェクトがイベントをスローするだけでは明らかではありません。

ソフトウェアアーキテクチャにおけるイベントの役割について考えてみたいと思います。イベントバインディングと直接メソッド呼び出しのバランスをどのように取っていますか？

だから私はここで何をすべきかわからない。

注文があり、メンバーが1人いるとします。

その関連付けられたメンバーが削除されたmy_order.member.first_nameと言うと、nilClassエラーが発生する可能性があります。my_order.member.try（：first_name）..を実行できますが、それはばかげた回避策のようです。私はいたるところにたくさんの試みを続けたくありません。

Nilオブジェクトに関する[この記事]を読みました：http：//robots.thoughtbot.com/post/8181879506/if-you-gaze-into-nil-nil-gazes-also-into-you？

良いもの。しかし、レールは非常に一般的であるため、これには便利なものがあると思います。独自のカスタムnilClassなどを作成する代わりに。

もしそうなら、その防御は何ですか？そうでない場合、なぜそうではないのですか？

次のようなものがあるとします (残念ながら、元のコードを投稿することは許可されていません)。

fooを呼び出しbar、 を渡しobjます。ただし、を使用する代わりにobj、ゲッターを呼び出して必要な情報を取得します。これはデメテルの法則に違反していますか?

以下のように書いた方が良いでしょうか？