問題タブ [law-of-demeter]

デメテルの法則は非常に強力な概念のようです。それが、優れた保守可能なオブジェクト指向コードを作成するのにどのように役立つかを理解できます。

ビュー内の関連付けられたオブジェクトの属性にアクセスする必要があるたびに、デリゲート メソッドを作成することを提案する人もいます。ビューでこのようなものを書く代わりに

次のコードを記述します。

一方、ビューでモデルを指示するべきではなく、ビューのアンダースコアとドットを交換するためだけにデリゲートなどのメソッドをモデルに追加するべきではないと主張する人もいます。

ビューでデメテルの法則に違反する場合、モデルにデリゲート メソッドを記述することはベスト プラクティスと見なされますか?

C#コードでデメテル違反の法則を発見するツールを構築することを考えています。明らかに、車輪を再発明して別のツールを構築したくはありませんが、代替ツールが利用可能である場合、特に c# コード用のツールを検索することはできませんでした。

同じ問題に関するスタック オーバーフロー (ここ) に関する別のトピックがありますが、提案された解決策 (たとえば、正規表現を使用して LoD 違反を発見する) は単純な違反のみをキャッチすると思います。たとえば、次のコードを考えてみましょう (そして person オブジェクトが既に存在するとします):

これは明らかに LoD 違反 ( と同じDriversLicense license = person.Wallet.DriversLicense) ですが、検出が困難です。

c# でデメテル違反の法則を確認する方法に関するスレッドをいくつか見つけましたが、特定のツールに対する回答はありません。

以前に C# コードで示された種類の LoD 違反を検出できるツールを知っていますか?

次のようなショッピングカートのチェックアウトプロセスを本質的に模倣する一連のページ状態があります。

アイテムが選択されたら、本質的に状態を変更して、そのアイテムのセラーをレンダリングしたいと考えました。アーキテクチャは次のようになります。

これら 2 つの状態が与えられた場合、Sellers コレクションをインスタンス化し、Sellers を取得してビューをレンダリングするためのベースとなる場所はどこでしょうか?

私は基本的に、SellersApp ビューと ItemsApp ビューを 1 つに組み合わせて、レンダリングするサブビューとフェッチするコレクションを決定する一種のコントローラーとして機能することを考えていました。そのようにする場合、メインアプリの名前空間で両方のコレクションをインスタンス化し、必要に応じてコレクションを取得するか、対応する状態 (url) が呼び出されたときにのみ各コレクションをインスタンス化する必要があります。後者のアプローチはデメテルの法則に違反していると思います。

どうすればいいと思います。

これは良いアプローチですか？それが良いアプローチである場合、状態を変更するように MainApp に指示する必要があります。つまり、メイン アプリのフェッチ コレクション メソッドを明示的に呼び出す必要があります (つまり
、ItemsView の「クリック」イベントで、ItemsApp.sellers を明示的に宣言する必要があります)、またはリスナーを使用する必要があります。アイテムが選択されるのを自動的にリッスンするメイン アプリ ビューで。

私は基本的に、router.navigate - トリガーを使用し、ルーターを使用して各ビュー/コレクションをインスタンス化する代替手段を探しています。これは良い習慣ではないと聞いています。

次のクラスを仮定します。

Intelli-J は、DoSomethingToThing が関数の結果を使用しており、おそらくフィールド、パラメーター、またはオブジェクト自体のメソッドしか呼び出せないため、デメテルの法則に違反していると言っています。

私は本当にこのようなことをしなければなりませんか:

私はそれが面倒だと思います。デメテルの法則は、あるクラスが別のクラスの内部を知らないがgetThing()、同じクラスであるようにするためのものだと思います!

これは本当にデメテルの法則に違反していますか？これは本当にデザインを改善していますか？

ありがとうございました。