問題タブ [circular-dependency]

おそらくこれは非常に基本的な質問です。そうである場合はご容赦ください---私はC＃の初心者です。

受信者にコマンドを送信するためのWPFGUIがあります。コマンドはASCIIテキストです。ここで、GUIに加えて通信方法を使用するコンソールアプリケーションがあるため、通信部分を別のプロジェクトに分割しました。通信DLLは、通常のソケットで非同期メソッドを使用します。

ここで問題となるのは、循環依存関係になることです。GUIはメッセージを送信するために通信ルーチンを呼び出す必要があり、ルーチンは応答を表示するためにGUIを呼び出す必要があります。通信が継承して依存関係を回避するインターフェースを作成できることは理解していますが、これが最善の方法ですか？それとも、これは私のデザインの欠陥ですか？基本的に、GUIを基盤となる通信レイヤーから切り離したかったのです。

私は現在、次のような状況にあります。

参照が相互にポイントし続けるため、これが機能しないことはわかっています。私はまた、weak_ptrこの問題を解決すると言われました。

ただし、weak_ptrgetまたは->overloadはありません。'use'についての言及を聞いたことがlock()ありますが、これを正しく行う方法のコード例を誰かに教えてもらえますか？

プロジェクト間の循環参照が多数含まれているVisualStudioソリューションを継承しました。

これがリモートで受け入れられる状況はありますか？

このアプリケーションがひどく設計されているという私の疑いを確認しようとしているだけです。前もって感謝します。

私の最初の疑いは、コードに循環依存関係があり、Resolve ヘッダーが循環依存関係を含むということでした。しかし、これは私のコンパイルエラーを解決していません. これは、A、G、および N の 3 つのクラスを含むコードです。

Ah と A.cpp で約 10 個のコンパイル エラーが発生しています。以下にコンパイル エラーを示します。

上記のコードで何が間違っている可能性がありますか?

よろしくお願いします
、
ラガヴァ。

私は 2 つのクラス間の循環依存関係に陥り、クリーンな解決策を考え出そうとしています。

基本的な構造は次のとおりです。

ContainerManager は WCF サービスとして公開されます。これは、クライアントがアイテムとコンテナーを作成できる外部ポイントです。ResourceManager は、作成された新しいアイテムを認識する必要があります。バックグラウンド処理を行い、時にはアイテムのコンテナからの情報を必要とします。

ここで、コンテナには、ContainerManager から渡される ResourceManager (ReportNewItem を呼び出すため) が必要です。ResourceManager は、ContainerManager を使用してのみ取得できるコンテナからの情報を必要とします。これにより、循環依存が作成されます。

後で単体テスト用のモック オブジェクトを作成できるように (具体的なオブジェクトではなく)、インターフェイスを使用してオブジェクトを初期化することをお勧めします (たとえば、モック ResourceManager を作成します)。 RM はその ctor に CM を必要とします。

明らかにこれではうまくいかないので、クリエイティブな解決策を考え出そうとしています。これまでのところ、私は持っています:

1) ReportNewItem に使用するコンテナを渡し、ResourceManager に直接使用させる。ResourceManager は認識している ItemID を永続的に保存するため、これは面倒です。これは、たとえばクラッシュ後に ResourceManager を初期化するときに、必要なすべてのコンテナーを再提供する必要があることを意味します。

2) CM または RM のいずれかを 2 つのフェーズで初期化します。例: RM = new RM(); CM = 新しい CM(RM); RM.SetCM(CM); しかし、これは醜いと思います。

3) ResourceManager を ContainerManager のメンバーにします。したがって、CM は「this」を使用して RM を構築できます。これは機能しますが、テスト中に RM モックを作成するときに苦労します。

4) IResourceManagerFactory で CM を初期化します。「this」を使用して RM を初期化する Factory.Create(this) を CM に呼び出してもらい、結果を保存します。テストのために、モック RM を返すモック ファクトリを作成できます。これは良い解決策になると思いますが、このためだけにファクトリを作成するのは少し面倒です。

5) ResourceManager ロジックをコンテナ固有のロジックに分割し、各コンテナに個別のインスタンスを作成します。残念ながら、ロジックは実際にはコンテナ間です。

「正しい」方法は、CM と RM の両方が依存する第 3 のクラスにコードを引き出すことだと思いますが、それを行うエレガントな方法を思いつくことはできません。「報告された項目」のロジックをカプセル化するか、コンポーネント情報ロジックをカプセル化するかのどちらかを思いつきましたが、どちらも正しくないようです。

洞察や提案をいただければ幸いです。

次のクラスがあります。

と

はっきりとわかるように、クラス間には循環依存関係があります。クラスAを実行しようとすると、最終的にはになりますStackOverflowError。

ノードがクラスである依存関係グラフが作成された場合、この依存関係は簡単に識別できます（少なくともノードが少ないグラフの場合）。では、少なくとも実行時に、JVMがこれを識別しないのはなぜですか？スローする代わりにStackOverflowError、JVMは実行を開始する前に少なくとも警告を出すことができます。

[更新]一部の言語は、ソースコードがビルドされないため、循環依存関係を持つことができません。たとえば、この質問と受け入れられた回答を参照してください。循環依存がC＃の設計上の臭いである場合、なぜJavaではないのでしょうか。Javaが（循環依存のコードをコンパイルする）ことができるという理由だけで？

[update2]最近見つかったjCarder。Webサイトによると、Javaバイトコードを動的に計測し、オブジェクトグラフでサイクルを探すことにより、潜在的なデッドロックを検出します。ツールがサイクルを見つける方法を誰かが説明できますか？

ここに私のメイクファイルがあります:

コンパイルしようとするたびに、makefile の依存関係がmake: Circular program.lex <- program.lex.o dependency dropped.まったく表示されないという警告が表示されます。依存関係ツリーが約 4 層の深さであることがわかりますが、循環しているようには見えません。program.lexprogram.lex.o

メイクファイルを改善するにはどうすればよいですか?

アプリケーションアーキテクチャの変更により、最近発生した循環依存関係があります。

アプリケーションは、MEFを介してプラグインをロードするプラグインマネージャーに依存しています。次のように表示されたため、これまでのすべてが正常に機能しました。

プラグインは次のようになりました。

しかし、今では、すべてのプラグインに、インターフェイスを介してPluginManager（または場合によっては他のオブジェクト）にクエリを実行して、システム内の他のプラグインの機能を確認する機能を持たせたいという状況があります。別のインターフェースを追加することでこれを「解決」しました。これをPluginQueryInterfaceと呼びましょう。次に、モデルにこのインターフェイスを実装させました。

プラグインの署名は次のようになります。

またはこれ

プラグインではプラグインを作成する前にPluginQueryInterfaceを作成する必要があるため、 2番目の実装は明らかに循環参照ですが、PluginQueryInterfaceはモデルであり、PluginManagerをインポートする必要があります。これにより、すべてのPluginInterfaceを作成する必要があります...起動すると、MEF循環依存エラーが発生します。

最初の実装は、私にとって循環参照のようには見えません。PluginQueryInterfaceがプロパティの場合、使用されるまで解決されないと思いました。また、コンストラクターではまったく使用されません。では、なぜPluginManagerがすべてのMyPluginを楽しく作成しないのでしょうか。どちらの場合も同じMEFエラーが発生します。

PluginManagerにPluginQueryInterfaceを実装させることで、この問題を解決しようとしました。これは、a）とにかく意味があり、b）循環依存を処理する既知の方法であるためです。代わりに、2つの相互依存クラスを3番目のクラスに依存させます。問題は、別のMEFエラーが発生することです。これはそれが言うことです：

WTF？コードにブレークポイントを設定し、GetExportedValueを呼び出す前にエクスポートされた値PluginManager.filename が設定されています。

私は完全に困惑しています。どんな観察や提案も今すぐ大歓迎です。私はこの問題をデバッグしようとして何時間もMEFで覆われた壁に頭をぶつけてきました。

（更新しました）

以前はこれについて考えていませんでしたが、プラグイン間の違いである可能性があるため、2つのプラグインのいずれかを削除すると、MEFエラーなしでアプリケーションが読み込まれます。私はそれを追加し直しました、そしてそれは再び失敗しました。次に、他のプラグインを削除しましたが、機能しました。したがって、これは他のMEFエラーのようです。特定のインターフェイスで複数のプラグインをロードする必要がないかのようです...しかし、私はImportManyを使用していますが、それはCardinalityExceptionある種のプラグインとして現れたのではないでしょうか。

アップデート

私はMEFのこの部分を理解していません、そしてうまくいけば、ここの誰かがそれが何であるかを説明することができます。しばらくコードにステップインした後、値を見つけた後にMEFがインポート定義を削除したことが原因でエラーが発生したことがわかりました。

私はこれまでこの問題を経験したことがなく、率直に言って、この問題を表面化させたインポートとエクスポートで現在何をしているのかを理解するのに苦労しています。MEFの設計者が誰にも意図していないことをしていると思います。やみくもにコメントアウトすることはできthis._importValues.Remove(definition);ましたが、それはおそらく正しくありませんでした。私の推測では、これは私が使用したMEF属性に要約されますが、この値をインポートするプラグインには作成ポリシーがあるCreationPolicy.Sharedので、なぜ問題が発生するのでしょうか。

私は3つのファイルを持っています:

testimports モジュール:

モジュールワン:

モジュール 2:

を実行するtestimportsと、次のようになります。

import moduleTwoただし、 の行のコメントを外すtestimportsと、プログラムは動作を停止する前にこの時点に到達します。

この循環依存の問題を解決するにはどうすればよいですか?

少し循環依存の問題があります。それは問題なく動作しますが、見苦しいコードになります。これは、スネーク ゲームのコンテキストにあります。

SnakeSegments のベクトルを含むクラス Snake があり、それらの相互作用を管理します (たとえば、個別のエンティティとしてではなく、ユニットとして移動および成長します)。

SnakeSegment が Food オブジェクトと衝突すると、hasEaten メンバーが true に反転します。Snake は、基本的にこのメンバーに対して SnakeSegments を定期的に照会します。いずれかのクエリが正の値を返した場合 (つまり、1 つが食べ物に当たった)、ヘビはユニットとして成長します (つまり、頭を広げて尻尾を縮めます)。これはすべて問題ありませんが、SnakeSegment が食べ物にヒットすると、アラート (シグナル、割り込みなど) を Snake クラスに送信し、Snake クラスに成長を指示する、よりシグナルベースのアプローチを好みます。 . これは、すべてのセグメントをチェックして、Snake の Update 関数に醜いコードが含まれていないことを意味します。代わりに、Snake クラスに OnEat() 関数を用意します。

ただし、これは循環依存につながります。Snake には SnakeSegments のベクトルが含まれており、SnakeSegments には Snake& または Snake* メンバーがあり、食べるときに誰に警告するかを指示します。コードでは、基本的に Snake クラスを事前に宣言する必要があります。

私のSnakeクラスは正常に動作します

これよりも優れたデザインはありますか？ここで発生する問題だけではないことに注意してください。同様の問題が多くの領域で発生します (たとえば、GameWorld には Snake メンバーが含まれており、Snake は GameWorld が死亡したときに警告を発します)。そのため、Snake と SnakeSegment に固有の解決策は私が探しているものではありません。