問題タブ [law-of-demeter]

パッシブビューを正しく使用する方法を理解しようとしています。パッシブビューで見るすべての例は、デメテルの法則に違反しているように思われます。

では、パッシブビューのより良い実装は何ですか？

この回答を見ると、私のプログラムで行ったように、C++ で友情を使用してプライベート ポインターをコピーしないでください。

それは問題ありませんが、一定のスマート ポインターを渡すと、カプセル化の原則に違反します。
システムの内部を公開します。bar を foo に渡すと、カップリングも作成されます。また、私のシステムでは、その質問で流暢なインターフェースと呼ばれるものにオブジェクトを集約することは理にかなっています。

そのSOの答えで言われているように、それはデメテルの法則に違反していませんか？
私はここで非常に混乱しています。
私は最後に自分のライブラリを再設計していますが、それを正しくしたいと思っています。
内部スマート ポインターを渡す代わりに、プロパティとしても使用されるラッパー クラスを渡し、それを読み取り専用に設定してから、コピーは安全だと思いましたか?

コメントに従って編集：まあ、私はD20 3.5 SRD（http://www.d20srd.org/）を実装しています。
たとえば、6 つの能力があります。
私の設計では、D20Abilities は D20Character 内に集約されています。
D20Abilities には、Strength、Dexterity、Constitution の 6 つの D20Ability インスタンスが含まれています。知恵、知性、カリスマ。
すべての D20Ability インスタンスは、システム全体で共有されるプライベート ステート (修飾子と呼ばれる) を保持します。たとえば、各スキルには独自の能力の修飾子が必要です。

デメテルの法則は、オブジェクトをクラスコンストラクターに渡すことを妨げません。ただし、後で同じオブジェクトを取得し、そのオブジェクトのメソッドを呼び出してスカラー値を取得することは禁止されています。代わりに、代わりにスカラー値を返すプロキシメソッドが作成されることになっています。私の質問は、オブジェクトをクラスコンストラクターに渡すことは許容できるのに、後で同じオブジェクトを取得してそこから値を取得することは許容できないのはなぜですか？

既存のクラスの再設計に取り組んでいます。このクラスでは、ほとんどの作業を行う約400行のwhileループです。ループの本体は、ifステートメント、変数割り当ての地雷原であり、中央のどこかに「続行」があります。ループの目的を理解するのは難しいです。

擬似コードでは、これが私が再設計しているところです：

FindOrCreateBatch（）内で、新しいバッチを作成する必要があるかどうか、または既存のバッチを使用できるかどうかを、いくつかのルールを使用して判断します。このインターフェースの実装が異なれば、それらを見つける方法などについても異なるルールがあります。戻り値は、見つけた、または作成した支払いバッチのデータベースからの代理キー（id）です。このIDは、pをパラメーターとして受け取る次のプロセスで必要になります。

これは私が始めたところからの改善ですが、このループを含むクラスに不安を感じています。

1. ドメインオブジェクトではなく、「Manager」または「Controller」タイプのクラスのようです。
2. バッチャーとsupplierBatchEntryCreator（および他のクラス）の間に入っているようです。現時点ではintのみが渡されますが、それが変更された場合は、3つのクラスすべてを変更する必要があります。これは、認知症の法則違反のようです。

何か提案がありますか、それとも大丈夫ですか？実際の言語はjavaです。

私のアプリケーションには、このようなコードがいくつかあります。それはいくつかの XML を書き出します:-

私が理解しているように、ディメンターの法則はこれが悪いと言っているでしょう. 「Code Complete」は、これがカップリングを増やしていると言います。このメソッドは、最初に "f" を取る必要があります。

しかし、今はこのコードを変更する必要があり、実際には の別のメソッドにアクセスする必要がありますb。

このインターフェイスは、変更が完全にメソッド内にあるため、作業が楽になります。アプリケーションの周りから呼び出される多くの場所について心配する必要はありません。

これは、元の設計が正しかったことを示唆しています。同意しますか？私は何が欠けていますか？

PS。このシステムでは、ドメイン オブジェクトは XML としての外部表現を認識していないため、動作が b 自体に属しているとは思いません。

私は主に Zend Framework コンポーネントに基づいた CMS を開発しています。この CMS のデータベース テーブルの一部は次のとおりです。

Siteとりわけ、次のメソッドで構成されるという名前のモデルがあります。

私は、モデルをどのように粒度化する必要があるかについて、ちょっと迷っています。

1 つのオプションは、メソッドSiteLocaleからオブジェクト/モデル (つまり、DB テーブル表現)を返すことですlistLocales()。これらのSiteLocaleオブジェクトには、次のメソッドが含まれています。

もう 1 つのオプションは、Siteモデルに次のメソッドを単純に作成し、それで完了することです。

正しい道は何だと思いますか？なぜ？

さらに、最初の選択肢 (または両方の選択肢) は、デメテルの法則に違反しますか?

編集(1 月 22 日)
私はジェフの答えが好きですが、私はまだ新しい/他の視点を受け入れています。

3層モデル（プレゼンテーション-ビジネス-データアクセスレイヤー）では、一貫して下位レイヤーを上位レイヤーに依存しないようにすることができます。たとえば、私のデータアクセス層は、それがどのように表示されるか、またはどのビジネスルールがその上で操作されるかを決して知りません。私のビジネスルールは、それらがどのように提示されるかに依存していません。

しかし、私はDemeterに許しを祈るか、少なくともStackoverflowの仲間にアドバイスを求めなければなりません。プレゼンテーション層のデータアクセスオブジェクトを参照せずに、ユーザーに「テーブル」を提示するにはどうすればよいですか。何度も、GridViewオブジェクトでADO.NETDataTableを参照していることに気付きます。現在、両方のレイヤーでサードパーティのツールを使用しています。テーブルは、OpenLinkのOpenComponentsテーブルオブジェクトからのものです。グリッドはInfragisticsUltraGrid（Windowsプラットフォーム）です。しかし、私は同じ違反で有罪です。

編集： 私はこれがWinForm3.5.NETでどのように行われるかについて特に興味があります。以下の私のコメントに注意してください。コメント内のリンクは私がすべきことだと思いますが、ドメインオブジェクトに夢中になる必要がないことを望んでいました。過剰なデザインで非難されたくありません。これは良いバランスですか？

The Pragmatic Programmer の143 ページに次のようなコード スニペットがあります。

これは、デメテルの法則/最小知識の原則に従います。

依存性注入を利用する以下のものに置き換えることが望ましいですか、また注意事項はありますか?

私はこの「デメテルの法則」について調べてきましたが、それ (および一般的な純粋な「ラッパー」クラス) は一般的にアンチ パターンのようです。実装クラスを考えてみましょう:

ここで、別のクラスの 2 つの異なる実装を考えてみましょう。

そして、上記のメソッドを呼び出す方法:

一見すると、バージョン 2 は少し単純に見え、「Demeter のルール」に従い、Foo の実装を非表示にするなどしています。たとえば、パラメーターをリセットに追加すると、次のようになります。

どちらのバージョンでも callingMethod を変更する必要がありますが、バージョン 2 では ScreenSpaceEffectsも変更する必要があります。誰かがラッパー/ファサードを持つことの利点を説明できますか (アダプター、外部 API のラップ、または内部 API の公開を除く)。

編集：些細な例ではなく、これに遭遇した多くの実際の例の1つ。

次のコードは、デメテルの法則に違反しています。

質問

1. LoDはどのように壊れていますか？
2. LoDを破るコードはどこにありますか？
3. LoDを維持するためにコードをどのように書く必要がありますか？