問題タブ [coupling]

私は C++ の経験を積むために単純なゲームを書いていますが、ポリモーフィズムがほとんど機能するのに機能しないという考えがあります。このゲームでは、Partyは をかなり直線的に移動しますが、道路で にMap遭遇することがあります。Forkフォークは (基本的に)です。当初は、メンバー関数std::vector<location*>に次のようなコードを作成する予定でした。Party

しかし、次のいくつかの変形がより良いのではないかと思っていました:

Fork は実際には Location から派生しており、いくつかの新しい function をオーバーロードしていますgetNext()。しかし後者の場合、location(低レベルの構造) は、「これをバックアップする」のではなく、ユーザーにメッセージを表示するものでなければなりませlocationんUserInterface::*。

あなたの意見は？

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

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

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

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

デメテルの法則の違反

BLLの内部

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

リポジトリ内

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

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

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

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

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

彼らは矛盾していますか？

デカップリングは素晴らしいものであり、達成するのは非常に困難です。ただし、ほとんどのアプリケーションでは実際には必要ないため、高度に結合されたアプリケーションを設計でき、「コンポーネントを分離できない」、「単体テストは苦痛」などの明らかな副作用以外はほとんど変わりません。 arse」など。

どう思いますか？常に分離してオーバーヘッドに対処しようとしていますか？

私が作っているゲームには2つのクラスがあります。

ゼロとクロスのゲームのための gui クラスとロジック クラス。GUI クラスには、JButton の配列を使用し、同じ匿名の内部クラス アクション リスナーでそれらすべてを返すメソッドがあります。

問題はこれです。ボタンをクリックすると、プレーヤー1または2の移動に応じてテキストをxまたはaoに変更したいのですが、このコードはロジッククラスにあるはずなので、何らかの形でメソッドを作成する必要がありますロジック クラスを作成し、make ボタン メソッドの anon 内部クラス アクション リスナーから呼び出します。ただし、ロジック クラスは GUI への参照を持つべきではありません。GUI にはロジック クラスへの参照があるためです。

私はこれに対するまともな解決策を考えることができません

ありがとう

私は 5 ～ 6 個のプロジェクトを含む大きな VS.NET プロジェクトを持っています。これらのプロジェクトの 1 つは Core DLL です。

プラグインのサポートを追加するために、インターフェイスを抽出しましたが、他のクラスを使用するにはインターフェイスが必要であり、Core.dll にはインターフェイスが必要だったため、それらを分離する必要がありました。(相互参照はできません)

この後、約4時間費やしてもそれらを分離できなかったので、私の一日は台無しになりました! 最後に、20以上のプロジェクトを作成しましたが、それでも機能しません(実際には閉じません)。最終的に 50 個のプロジェクトが作成され、それを正しく行うには多くのコードを変更する必要があるようです。

私のコードが高度に結合されていることに気付き、少し戻ってきました。

私はこれを正しく行っていますか？高度に結合されたコードのせいで、会費を払って苦しむ必要がありますか? または、何か不足していますか？

大きな密結合アプリケーションをリファクタリングし、より保守しやすく柔軟にしようとしています。

単体テストがたくさんあるので、段階的にリファクタリングしたいと思っています。

このタスクを達成するために、どの設計およびリファクタリング パターンを実装または適用することを検討する必要がありますか?

私はいくつか考えることができます：

• インターフェイスの抽出
• 抽出方法
• 依存性注入

また、この種のリファクタリング ジョブに関するご自身の経験とベスト プラクティスを自由に共有してください。

アップデート

この質問で説明されている理由により、このリファクタリングを実行しています。基本的に、いくつかのインターフェイスを抽出せずにプラグイン システムを実装することはできません。これらのインターフェイスは高度に結合されているため、アプリケーションを 40 以上の DLL に分離して、循環参照の問題なしにコンパイルする必要があります。

より良いオブジェクト指向設計を構成するのはどれですか?

またはこれ

学校で GRASP パターンを学んでいますが、Creator パターンについて質問があります。

Computer、UserRespository、およびUserの 3 つのクラスがあるとします。

GRASP Creator パターンの規則の 1 つは、オブジェクトを作成する責任を、それらのオブジェクトを含むクラスに割り当てるように指示します。このガイドラインに従うことで、UserRepository が User の作成者になる必要があります。

したがって、Computer がユーザーを作成する場合は、UserRespository に問い合わせます。

これにより、 ComputerがUserから効果的に分離されます。本当に？

明らかに、Computerには User への言及はありませんが、Computer は依然として User の作成と強く結びついていると思います。なんで？createUserメソッドは、作成をうまく隠していません。ユーザーがコンストラクターを変更する場合、 createUserメソッドを変更して、それらの変更と、メソッドを使用するすべてのクライアントを反映する必要があります。

このパターンを使用する利点は何ですか？

このイディオムに精通している必要があると思います。これは、Javaのクロージャの言い訳のようなものです。

私はこのイディオム/パターンをよく使用しましたが、最近それをテストしようとしました、そしてそれは私に頭痛を与えています...

ResourceManagerクラスとClientクラスを分離してテストするにはどうすればよいですか？私は、これがそれらを非常に緊密に結合しているので、簡単にそれを行うことができないことを発見しました。

アイデアは大歓迎です。

よろしく

たとえば、64ビット変数があり、その中に2つの32ビットデータ項目を格納する場合、おそらくSIMD処理の目的で、これら2つのデータ項目の論理結合を説明する名前はありますか？

私の同僚は「ハイブリッドカップリング」を提案していますが、これは広く使用されている用語ですか？

明確にするために：私たちは特定の実装よりも高いレベルの概念を求めています。たとえば、Cのような言語では、次の2つの構造体があります。

そうする理由に関係なく、UncoupledDataには存在しないCoupledDataのxデータメンバーとyデータメンバーの間に暗黙の結合があります。xとyの間のこの結合を説明する用語はありますか？