問題タブ [law-of-demeter]

私は自分のコードを階層的に整理しており、次のようなコードを使用してツリーをクロールしていることに気付きました。

taskオブジェクトにドリルダウンしているわけではありません。私はその親にドリルアップしているので、カプセル化に関して何も失っていないと思います。しかし、心の奥底で、このようにするのは何か汚いことだというフラグが立っています。

これは間違っていますか？

デメテルの法則は、自分が直接知っている対象にのみ話しかけるべきであることを示しています。つまり、他のオブジェクトと通信するためにメソッド チェーンを実行しないでください。これを行うと、中間オブジェクトとの不適切なリンクが確立され、コードが他のコードに不適切に結合されます。

良くないね。

解決策は、あなたが知っているクラスが、関係のあるオブジェクトに責任を委任する単純なラッパーを本質的に公開することです。

それは良い。

でも、それだとクラスの結束が弱くなるらしい。もはや、それが何をするかについて正確に責任を負うだけではなく、関連するオブジェクトのインターフェースの一部を複製することによって、ある意味でコードのまとまりをなくすデリゲートも持っています。

良くないね。

それは本当に結束力を低下させるのでしょうか？それは2つの悪の小さい方ですか？

これは開発の灰色の領域の 1 つで、境界線がどこにあるかを議論できる場所ですか、それとも、どこに境界線を引くか、その決定を下すために使用できる基準を決定するための強力で原則に基づいた方法はありますか?

「クラスは、引数として受け取るクラスのコントラクト、または使用する内部コントラクトについてのみ知っておくべきである」という行に沿って何かを述べているオブジェクト指向エンジニアリングの原則があります。

C++ での反例は次のとおりです。

この原則に名前はありますか？また、上記の私の言い換えではなく、実際の原則が見られるとよいでしょう。

私はシステムの新しいコンポーネントを設計しており、DIに関するさまざまなガイドラインに従おうとしているので、分離、モックなどの点で見返りが得られます。

したがって、次のコンポーネントがあります（抽象化として示されています）。

• Fetcher-特定のデータソースからデータをフェッチするIFetcherをサポートします。IDataSourceを返します。
• Builder-IDataSourceから構造を構築するIBuilderをサポートします。

これらを「Performer」（より良い名前が必要な場合）コンポーネントにまとめたいと思います。これにより、次のようになります。

依存性注入とLoDのガイドラインに準拠するために（とにかく理解している限り）、IFetcherコンポーネントとIBuilderコンポーネントの両方をに渡します。

私の質問-これは許容できる設計のように聞こえますか？同僚との会話は「ええ、いいですね」の線に沿っていますが、パフォーマークラスによるカプセル化を100％確信しているわけではありません。

私の見方では、パフォーマーは、いくつかの異なるコンポーネントを接着する複合コントロールであり、許容できるはずです。唯一の疑問符は、「Performer Factory」が必要かどうかですが、実際のコンポーネント（IFetcherとIBuilder）がモックされる可能性があることを考えると、これはやり過ぎのようです。

どんな考えでもありがたいです、ありがとう。

ゲーム オブジェクトの機能から物理シミュレーションを分離するゲーム エンジンがあります。だから私は物理的な体のための純粋な仮想クラスを持っています

そこから、物理シミュレーションのさまざまな実装を導き出します。私のゲームオブジェクトクラスは次のようになります

その特定のゲームに必要な実装をプラグインできます。しかし、私がBody持っているのはGameObject. だから私は自分が次のようなものをたくさん書いていることに気づきました

私はそれらすべてをスクラッチして、次のようなことをしたくなります

しかし、これは間違っているようです (つまり、デメテルの法則に違反しています)。さらに、実装から使用法に冗長性をプッシュするだけです。だから私はこれを行う別の方法を探しています。

同僚と私は顧客のためにシステムを設計しました。私たちの意見では、きれいなデザインを作成しました。しかし、導入したいくつかのカップリングに問題があります。私たちの設計と同じ問題を含むサンプル デザインを作成することもできますが、ご容赦いただければ、質問をサポートするために私たちの設計の抜粋を作成します。

患者の特定の治療を登録するためのシステムを開発しています。画像へのリンクが壊れないように、概念的な UML クラス図を ac# スタイルのクラス定義として説明します。

設計について少し説明しようと思います。プロトコルは新しい治療のテンプレートです。そして、プロトコルは特定の種類のものであり、投与する必要のある薬が含まれています。プロトコルごとに、同じ薬の投与量が (とりわけ) 異なる可能性があるため、これは ProtocolMedication クラスに格納されます。AdministrationRoute は、薬が投与される方法であり、プロトコル管理とは別に作成/更新されます。

デメテルの法則に違反する可能性のある次の場所を発見しました。

デメテルの法則の違反

BLLの内部

たとえば、ProtocolMedication のビジネス ロジック内には、医薬品の AdministrationRoute.Soluble プロパティに依存するルールがあります。コードは次のようになります

リポジトリ内

特定の分野のすべてのプロトコルをリストするメソッドは、次のように記述されます。

ユーザー インターフェイスの内部

システムのインターフェースに ASP.NET (MVC なし) を使用していますが、私の意見では、このレイヤーには現在最悪の違反があります。グリッドビューのデータバインディング (プロトコルの規律を表示する必要がある列は、Kind.Discipline.Name にバインドする必要があります) は文字列であるため、コンパイル時のエラーは発生しません。

ですから、実際の問題は、いつそれをデメテルの暗示と見なすのがよいのでしょうか、そしてデメテルの法則の違反を解決するために何ができるでしょうか?

私は自分自身についていくつかのアイデアを持っていますが、それらを回答として投稿して、個別にコメントしたり投票したりできるようにします. （そうでない場合は、回答を削除して質問に追加します）。

デメテルの法則（実際にはデメテルの提案である必要があります）は、オブジェクトを「通過」して子オブジェクトに到達するべきではないと述べています。クライアントとして重要な操作を実行する必要がある場合、ほとんどの場合、使用しているドメインモデルはその操作をサポートする必要があります。

RESTは、原則として、オブジェクトのダム階層です。これは、各オブジェクトが子オブジェクトを持つことができるリソース/オブジェクトのファイルシステムのようなものです。ほとんどの場合、RESTを使用します。オプションで、REST手法を使用して従来の複合オブジェクトタイプを構築できます。プロバイダーとクライアントがより高いレベルの操作に同意する限り、リーチスルーを回避できます。

では、RESTとDemeterのバランスをどのように取っていますか？RESTは、プロバイダーがクライアントのすべてのニーズを予測しようとするのは無意味であるという点への超緩い結合に関するものであるため、それらは競合していないように見えますが、Demeterは、ロジックがリファクタリングによる最も自然な場所。

ただし、クライアントをよりよく理解するまでは、RESTは単なる一時的なギャップであると主張することができます。RESTは単なるハックですか？デメテルはどのサーバー/クライアントシナリオでも非現実的ですか？

依存性注入について質問があります。

それを呼び出すクラスを作成したいとします、WebGetTask

WebGetTask には HttpService への依存関係が必要です

悪いコード 1 コード:

わかった。httpService が挿入されているため、これが悪いことはわかっていますが、新しい WebGetTask での作成を除いて、使用されることはありません

OK 悪いコード 2 コード:

私たちは工場を使用しているので、これはより良いと思いますが...しかし..

私が立っている場所から、WebGetTaskFactory ではまだ HttpService を注入しており、新しい WebGetTask を作成するという唯一の目的以外には何もしていないことがわかります。

私の質問を要約すると、新しいオブジェクトがコンストラクターに依存関係 (HttpService) を必要とする場合に、単に依存関係 (HttpService) を注入して渡すことなく、新しいオブジェクト (WebGetTask) を作成するファクトリ クラス (WebGetTaskFactory) を設計するにはどうすればよいですか? というか、これがやり方か。もしそうなら、それはすべて良いです、そうでない場合は、DIとファクトリーパターンを適切に使用する方法を教えてください。ありがとう。

メソッドが 'xyz' を知る必要がある場合、'x' を要求する代わりに 'z' を直接要求するべきであるというプログラミング "ルール" があります。名前しか思い出せない。