問題タブ [law-of-demeter]

私のAndroidアプリからのメソッドは次のとおりです。

Android Studio は、次の 2 行がデメテルの法則に違反していると「考えます」。

理解できません。定義は次のとおりです。

関数のデメテルの法則では、オブジェクト O のメソッド m は、次の種類のオブジェクトのメソッドのみを呼び出すことができます。

• 〇そのもの
• m のパラメーター
• m 内で作成/インスタンス化されたオブジェクト
• O の直接コンポーネント オブジェクト
• m のスコープ内で、O からアクセスできるグローバル変数

そう？holder変数は内で作成/インスタンス化されますm。

当然のことながら、インスタンス化はメソッドに委譲されてcreateViewHolderいます...違いはありますか? （副質問）。

IDE にはありませんholder。代わりに直接インスタンス化すると、警告が引き続き表示されます。

質問：

Androidスタジオは間違っていますか? それとも、デメテルの法則に対する私の理解が不足しているのでしょうか? 後者が真の場合、LoD を満たすためにこのビットをどのようにリファクタリングする必要がありますか?

誰かが私にデメテルの法則を説明するのを手伝ってくれることを願っています. 集約ルートであると想定しているクラスがあり、その中に子クラスのコレクションがある場合、集約ルートを介してアクセスしてそれらの子クラスのプロパティを更新することは違法ですか?

例えば

最初に Company クラスにアクセスしているクライアントがいるとしましょう。

または、これは常に会社に委任する必要があります

クライアントで

2 番目の方が優れているように見えますが、クライアントが更新したい Employee の ID を知らなければならないことに何か問題がありますか?

これは、多数のネストされた集計がある場合に複雑になり始める可能性があるようです。

ありがとう

Java の他のオブジェクトに含まれるリストに関連するデメテルの法則について質問があります。私は次のクラスを持っています。

このクラスの conversationList に新しい Message オブジェクトを追加するには、通常、次のようにします。

少し読んだ後、これはデメテルの法則に違反しているように見え、次のように会話にメソッドを追加すると、これに近づく「より良い」方法になります。

しかし、これは私には完全にやり過ぎのようです。この状況でのベストプラクティスのアプローチは何ですか?

3 つのクラスがある場合は、引数のためにそれらを呼び出しましょう。

• 主な活動
• GLRenderer
• その他のクラス

GLRendererは純粋なプロキシ クラスではなく、いくつかのプロキシ メソッドが含まれていることに注意してください。

MainActivityは、valueと呼ばれる int を初期化します。さて、なんらかの理由でOtherClassがその値を変更する必要があり、GLRenderer クラスに直接アクセスするしかない場合(これはMainActivityクラスにアクセスできます)、この変数にアクセスする最善の方法は何でしょうか?

現在、私はMainActivityでセッター メソッドを使用し、次にGLRendererで別のセッターを使用しています (値を渡すだけなので、実際にはプロキシ メソッドです)。

これはうまく機能し、現在私がやっている方法です。ここにいくつかの疑似コードがあります（このコードはコンパイルできない可能性があることを認識しています。これは純粋にこの質問の目的のためです）：

主な活動

セカンドクラス

その他のクラス

上記は、次のようなことを行うよりも優れています: ( OtherClassコードのコメントを参照してください)

GLRenderer

その他のクラス

最初のメソッドでは、 OtherClassでより短い最終命令が必要であることはわかっていますが、上記のメソッドを使用すると、ゲッター/セッターを効果的に複製することなく、 MainActivityから何かにアクセスできます(必要なものがたくさんある場合、これは苦痛になる可能性があります)。アクセス）。

アジャイル開発者に不可欠なスキル、ニーズと機能のインターフェース、第 12 章では、著者がこの章の終わりまでに言及している DEMETER の法則を適用するという課題に対して提案された主な解決策を理解しようとしています。

話を短くするために。

次のスタディ ケースから始めます。

著者は次のように述べています。

このようなモデルは、カプセル化するのではなく、公開することを奨励します。コードに特定の City インスタンスへの参照が含まれている場合 (たとえば、シアトルをマップするインスタンス)、メイン ストリート 1374 番地の家の色が必要な場合は、次のようにします。

これが一般的な慣行として行われる場合の問題は、システムがあらゆる場所で依存関係を開発し、このモデルの任意の部分を変更すると、これらの依存関係のチェーンの上下に影響を与える可能性があることです。ここで、「見知らぬ人と話すな」2 というデメテルの法則の出番です。これは、関数/メソッドのデメテルの法則としてオブジェクト システムで形式化されています。オブジェクト O のメソッド M は、次の種類のオブジェクトのメソッドのみを呼び出すことができます。

1. オーズ
2. M のパラメーター
3. M 内でインスタンス化されたすべてのオブジェクト
4. O の直接コンポーネント オブジェクト
5. O によってアクセス可能なグローバル変数

そして、DEMTERの法則を適用するときは、次のようなものを目指すべきであることを提案します

そして、次のことからすぐに警告します。

これは最初は賢明なポリシーのように見えますが、特定のエンティティのインターフェイスが文字通り関連するものすべてを提供することが期待できるため、すぐに手に負えなくなる可能性があります。これらのインターフェイスは時間の経過とともに肥大化する傾向があり、実際、特定のグラスが最終的にサポートする可能性のあるパブリック メソッドの数にはほとんど終わりがないように思われます。

次に、結合と依存関係の問題を説明する際の簡単な回り道の後、サービスのインターフェースによってクライアントとそのサービスを分離することの重要性に言及し、さらにクライアントを「サービス機能」から「インターフェースが必要」に分離することによって、彼は言及します。理想的であるが必ずしも実用的ではないものとしてアダプターを使用することによる「インターフェイス」。

彼は、問題を解決するために、以下に説明するファサード パターンを使用して、DEMETER の法則とニーズ/機能の分離を組み合わせることができると提案しています。

元の依存関係から

デメテルの法則とニーズ/機能の境界面の分離を適用すると、最初に次のことが得られます。

しかし、特にモッキングの観点からは非現実的であることを考えると、次のようにファサードを使用してより単純なものを作成できます。

問題は、デメテルの法則に違反しないという問題を正確に解決する方法がわからないことです。元のクライアントと元のサービスの間の法律を維持していると思います。しかし、FACADE 内で違反を移動しただけです。