問題タブ [circular-dependency]

テストケースを作成していますが、循環依存関係をカバーする必要があります。これまでのところ、テーブルAがBに対してFKを持ち、BがAに対してFKを持つように、2つのテーブルを作成することができました。

他にどのような循環依存関係が存在しますか/オブジェクト間に許可されていますか？ビュー間にサイクルを作成しようとしましたが、Oracleはそれを拒否しました。

現在、 StructureMapをビジネス レイヤーに統合していますが、双方向の依存関係が原因で問題が発生しています。

レイヤーには複数のマネージャーが含まれており、各マネージャーは相互にメソッドを呼び出すことができます。通信に関する制限やルールはありません。これには、以下の例のような循環依存関係も含まれます。設計自体に問題があることは承知していますが、現在はStructureMapを機能させたいだけであり、将来的にはさらなるリファクタリングに注力する予定です。

すべてのマネージャーは次のIManagerインターフェースを実装します。

また、独自の特定のインターフェイスもあります。

2 つのダミー マネージャーの実装を次に示します。

これが私が現在使用している StructureMap 構成です。

マネージャーを登録する方法がまだわからないので、現在は手動登録を使用しています。多分誰かがこれで私を助けることができます。

結局、 StructureMapはとの間の循環依存関係について不平を言うIManagerAため、作成できません。この問題を解決し、現在の設計を維持するための簡単でクリーンな解決策はありますか?ManagerAManagerB

structuremap には最も単純な種類の循環依存関係があります。クラス A はそのコンストラクターでクラス B に依存し、クラス B はそのコンストラクターでクラス A に依存しています。依存関係を壊すために、クラス B がクラス A をコンストラクター引数ではなくプロパティとして受け取るようにしましたが、structuremap はまだ文句を言います。

他の DI フレームワークでこの方法を使用すると、循環依存関係が壊れているのを見てきました。これは Structuremap の問題ですか、それとも何か間違っていますか?

編集: クラス B のプロパティは、次のように配線されたクラス A インスタンスの配列であることに言及する必要があります。

明確にするために、次の一連のイベントが発生するようにします。

• B、「b」のインスタンスを構築する
• A のインスタンス「a」を構築し、そのコンストラクターに「b」を注入します
• "b.ArrayOfA" を ["a"] に設定します

そして、可能であれば、これらすべてを自動配線を使用して実現したいと考えています...

編集 2:これは、明示的な配線を使用する単純化された例です。

構成を検証すると、「RequestedType: IocTest2.ILoader... で検出された双方向の依存関係の問題」が発生します。

2つのクラスがあります。

と

Matrixは、開始イテレーターと終了イテレーターを返すことができる必要があり、イテレーターは、そのインターフェースを介して要素にアクセスするために、マトリックスへの参照を保持します。結合を防ぐために、IteratorがMatrixの内部ストレージに依存することは望ましくありません。この循環依存の問題をどのように解決できますか？

（内部Storageクラスには、Matrixクラスと同じテンプレートパラメーターと、Matrix自体と同じアクセスプロシージャがあります）

循環参照のあるWCF契約を結んでいます。単純な親子関係の場合、ソリューションは.NET 3.5SP1以降（DataContractのIsReferenceプロパティ）を使用すると非常に単純です（このページには適切な説明があります）。

しかし、私の関係は3つのレベルの深さです：祖父母<->親<->子。「祖父母」には多くの「親」がいて、「親」には多くの「子供」がいます。祖父母<->の親の関係を機能させるために、祖父母にIsReferenceを設定しています-問題ありません。ただし、親<->子の関係を機能させるには、「親」もIsReferenceである必要があります。これを設定するとすぐに、サービスが失敗します。問題は、「祖父母」と「親」の両方がIsReferenceの場合、シリアライザーが何をすべきかわからないことだと思います。

IsReferenceでこれを修正する方法はありますか、それとも別の解決策を追求する必要がありますか？

次のインターフェイスを定義しました。

基本的に、IStateSpaceインターフェースはチェス盤のようなものであるべきで、チェス盤の各位置には一連の可能な動きがあります。ここでのそれらの動きはIActions と呼ばれます。このインターフェイスをこのように定義したので、さまざまな実装に対応できます。その後、2D マトリックス、3D マトリックス、グラフなどを実装する具象クラスを定義できます。

はIAction、上に移動する (これは、 に(2, 2)移動する場合(2, 1))、下に移動するなどです。ここで、各アクションが StateSpace にアクセスできるようにして、いくつかのチェック ロジックを実行できるようにします。この実装は正しいですか？それとも、これは循環依存の悪いケースですか? はいの場合、別の方法で「同じ」を達成する方法は?

ありがとう

私は現在、非常に厄介な問題に直面しています。

ここで説明するようにIPosition、IValueとIStateは相互に依存しています。どうすればこれを回避できますか？この循環依存を回避し、それでも私がやりたいことを正確に説明する他のデザインは考えられません。

基本的に、内部に状態がある状態空間IStateSpaceがあります。IState状態空間でのそれらの位置は、によって与えられIPositionます。各状態には、1つ（または複数）の値がありますIValue。説明よりも少し複雑なので、階層を単純化しています。この階層をジェネリックスで定義するという考え方は、同じ概念のさまざまな実装を可能にすることです（IStateSpaceグラフなどのマトリックスとして実装されます）。

これで逃げられますか？この種の問題を一般的にどのように解決しますか？これらの場合、どのようなデザインが使用されますか？

ありがとう

.Net リモーティングを使用して、2 つのオブジェクト間の双方向通信回線をセットアップしています。基本的な構造は次のとおりです。

このセットアップの問題は、RemoteObjectA gets StaticObjectA gets RemoteObjectB gets StaticObjectB gets RemoteObjectA の循環参照です...

インターフェイス IRemoteObjectA と IRemoteObjectB を実装し、それぞれのインターフェイスからリモート オブジェクトを継承しましたが、リモート処理の設定に失敗しました。

この問題の解決策が「リモーティングを使用しない」である場合、私はそれに対処できます。簡単な解決策を見逃していないことを確認したかっただけです。

私はJavaで例を作成しましたが、他の（すべて？）言語で機能すると思います（テストされていません）。

2つのファイルがあります。まず、M.java：

次に、別のファイル（同じディレクトリ内）XType.java、:

プログラミングは悪いですが、実行するjavac XTypeとコンパイルされます。必要な場合でもコンパイルさMTypeれXTypeます。しかし...MType必要XType...それはどのように機能しますか？コンパイラは何が起こっているかをどのように知るのですか？

コンパイラー（javacまたはあなたが知っている他のコンパイラー）がその状況をどのように管理するかを知りたいのですが、それを回避する方法ではありません。

私はプリコンパイラを書いているので、その状況を管理したいので、質問しています。

最近、休止後にC ++開発に戻り、StateDesignPatternの実装について質問があります。GoFの本とまったく同じように、バニラパターンを使用しています。

私の問題は、ステートマシン自体が組み込みシステムの一部として使用されるハードウェアに基づいているため、設計が修正されて変更できないことです。これにより、2つの状態（特に）の間に循環依存が発生し、これを解決しようとしています。簡略化されたコードは次のとおりです（通常どおりヘッダーを使用してこれを解決しようとしましたが、それでも問題が発生しました。このコードスニペットではヘッダーを省略しています）。

問題は、基本的に、状態パターンでは、次の状態のコンストラクターを呼び出すContextクラスのChangeStateメソッドを呼び出すことによって状態遷移が行われることです。

循環依存のため、「問題」状態の両方のコンストラクターを事前に定義することができないため、コンストラクターを呼び出すことができません。

私はこの記事を見て、理想的な解決策のように思われたテンプレートメソッドを調べましたが、コンパイルされず、テンプレートに関する私の知識はかなり限られています...

私が持っていたもう1つのアイデアは、多重継承を介してヘルパークラスをサブクラス化された状態に導入し、基本クラスのコンストラクターを指定して、状態サブクラスのコンストラクターを参照できるかどうかを確認することです。しかし、それはかなり野心的だったと思います...

最後に、ファクトリメソッドデザインパターンを直接実装することが、問題全体を解決するための最良の方法でしょうか？