問題タブ [circular-dependency]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
5 に答える
8389 参照

clojure - Clojureの循環依存関係の解決

私は、異なる名前空間間に循環依存関係があるいくつかのClojureコードに取り組んでおり、それらを解決するための最良の方法を見つけようとしています。

  • 基本的な問題は、ファイルの1つで「そのような変数はありません:名前空間/関数名」エラーが発生することです
  • 関数を「宣言」しようとしましたが、「存在しない修飾変数を参照できません」と文句を言います。
  • もちろん、コードベース全体をリファクタリングすることもできますが、解決する依存関係があるたびにそれを行うのは非現実的です.....循環依存関係の特定のネットワークでは非常に醜くなる可能性があります
  • たくさんのインターフェース/プロトコル/宣言を別のファイルに分けて、すべてにそれを参照させることができます....しかし、それは厄介になり、関連する機能をグループ化した現在の素晴らしいモジュラー構造を台無しにするようです一緒

何かご意見は?Clojureでこの種の循環依存を処理するための最良の方法は何ですか?

0 投票する
5 に答える
6618 参照

c# - Visual Studioでアセンブリレベルで循環依存を有効にすることは可能ですか?相互に依存するアセンブリも可能でしょうか?

これはおそらくばかげた質問のように聞こえますが、とにかくそれを試してみるつもりです。

したがって、Visual Studioでは、XがYを参照し、YがXを参照するように2つのプロジェクトXとYを作成することはできません。

一般に、さまざまな理由から、循環依存が問題になる可能性があることを完全に理解できます。

しかし、このように相互依存している2つのプロジェクトをコンパイルすることは本当に不可能ですか?(私の考えでは、これについては完全にオフベースであるかもしれませんが)2つの相互に依存するアセンブリを持つことは、2つの相互に依存するクラスを持つことと実際にはそれほど違いがないため、可能である必要があるように思われます。合法であり、コンパイルすることができます。

「コンパイラが一方を他方の前にコンパイルできなかったため、2つのアセンブリが相互に依存することはできません」と言った場合、私には意味があります。ただし、同じアセンブリ内の2つのクラスに対して同じ引数を指定できるようであり、コンパイラはこのシナリオを問題なく処理できることは明らかです。

基本的に私が尋ねている理由は、私がこのことをしたいという切実な願望を持っているということではありません。具体的には、基本的に1つのユニットの相互に依存する2つの部分として存在し、特定の部分がC#で記述されているために分離されている、MyProjectCSとMyProjectVBの2つのプロジェクトがあればいいのではないかと思います。他の部分はVB.NETで書かれています。

だから、私の質問は(yikes、3倍)です:

  1. この動作を有効にすることは可能ですか(Visual Studio、またはその他の場所で)?
  2. IDE内でそれが不可能な場合、少なくとも理論的には可能ですか、それとも相互に依存するアセンブリが存在しない可能性がありますか?
  3. 理論的にも不可能な場合は、どうしてですか?言い換えると、相互に依存するアセンブリは、単一のアセンブリ内の相互に依存するコードとどのように異なりますか?
0 投票する
1 に答える
327 参照

c# - 複数のプロジェクトの構成

私のプロジェクト

私は VS C# 2.0 を使用して Winform アプリケーションを作成しています。これは、いくつかのライブラリと 2 つの実行可能ファイルで構成され、それぞれが独自のプロジェクト ファイルにあり、すべてが同じソリューションの一部です。

各プロジェクトには、構成パラメーターを指定する独自の設定クラスがあります。一部のパラメーターはプロジェクト固有であり、一部は複数のプロジェクトで必要です (ただし、すべてのプロジェクトで必要なわけではありません)。その他は、USB 経由でユーザー マシンに接続されたハードウェア デバイスのモデルに依存します (実行時に選択されます)。

設定クラスは、列挙、プロパティ、および Load メソッドと Save メソッドで構成されます。

現在、すべてのクラスからすべての設定をインスタンス化し、ユーザーが構成を変更できるようにするプロパティ グリッドを含むフォームがあります。メインの実行可能プロジェクトに属します。

私の問題

ユーザーがアプリケーション全体を構成する方法が必要です (これをconfiguratorと呼びましょう)。そのため、プロパティ グリッドを含むフォームを持つ別のプロジェクトを作成しようとしましたが、 configuratorとメインの間の循環参照の問題で終了しました。実行可能。コンフィギュレーターは、単独で実行するか、メインの実行可能ファイルから呼び出す必要があります。

また、共通パラメーターの値の変更を対応するパラメーターに複製する良い方法もわかりません。たとえば、パラメーターpがプロジェクトABの設定クラスに共通である場合、ユーザーがAp値を変更すると、コンフィギュレーターはBp値を変更する必要があります (逆の場合も同様です)。これを解決するために私が考えた唯一の解決策は、プロパティ グリッドのPropertyValueChangedイベント ハンドラーの if 句の悪夢です。

ありがとう、ハイディ

0 投票する
5 に答える
932 参照

c++ - テンプレート、循環依存関係、メソッド、なんてこった!

背景:既存の Java クラス モデルに基づいて C++ コードを生成するフレームワークに取り組んでいます。このため、以下で説明する循環依存関係を変更することはできません。

与えられた:

  • 親子クラスの関係
  • 親には子のリストが含まれています
  • ユーザーは実行時にリスト要素のタイプを検索できる必要があります

これを次のテストケースでモデル化しました。

メイン.cpp

Parent.h

Child.h

Array.h

  1. 上記のコードをコンパイルすると、次のようになります error C2027: use of undefined type 'Child'return ElementType::getType();

  2. #include "Child.h"前方宣言の代わり に試してみると、次のようになりますerror C2504: 'Parent' : base class undefinedclass Child: public Parent

  3. Array<Child*>取得する代わりに試してみるとArray<Child>: error C2825: 'ElementType': must be a class or namespace when followed by '::'atreturn ElementType::getType();

循環依存は、次の理由で発生します。

  1. Child.h はクラス Parent について知る必要があります
  2. Parent.h はクラス Array について知る必要があります
  3. Array.h はクラス Child について知る必要があります

何か案は?

0 投票する
2 に答える
4802 参照

python - Python 循環参照

同じファイル内で、相互に参照する 2 つのクラスを作成しようとしています。これを機能させるための最良の方法は次のとおりです。

?

問題は、プロパティがクラス上にあるため、クラス自体が解析されるとすぐに実行しようとすることです。

それを解決する方法はありますか?

編集:

これらのキーは SQLAlchemy マッピングに使用され、実際にはクラス変数 (インスタンスではありません) です。

0 投票する
5 に答える
1542 参照

c++ - C++ での循環依存の解消

解決しようとしている次の循環依存関係の問題があります。

my_class が typedef の前に宣言されていないため、コンパイラはこれを好みません。

次のように myclass を前方宣言しようとすると:

「エラー: 'my_class' の前方宣言」が表示されます。

どうすればこの悪循環を断ち切ることができるでしょうか?


申し訳ありませんが、私の表現が少し間違っていることに気付いたので、質問を修正する必要があります。

以下は私の問題の正しい表現です:

これにつきましては申し訳ございません

0 投票する
4 に答える
14598 参照

c++ - テンプレート クラス間の循環依存関係の解決

から派生したFoo<T>との2 つのクラスがあります。それぞれが methodをオーバーライドします。ここで、 はorの特定のインスタンス化を一意に識別する型のインスタンスです(それが であるふりをします)。問題は、がインスタンスを返せるようにする必要があり、同様に をインスタンス化できる必要があることです。どちらもテンプレートであるため、 と の間に循環依存関係が発生します。これを解決するにはどうすればよいですか?Bar<T>Basevirtual Base* convert(ID) constIDFooBarenumFoo::convert()BarBar::convert()FooFoo.hBar.h

編集:各メソッドの実装には他のクラスのコンストラクターが必要なため、前方宣言は機能しません。

Foo.h:

Bar.h:

エラーは、当然、「不完全な型の無効な使用」です。

0 投票する
3 に答える
1191 参照

language-agnostic - この循環する双方向の依存関係をどのように解決できますか?

RequestHandler クラスと RequestListener クラスがあります。RequestHandler は RequestListener を作成し、それ自体への参照を渡します。次に、RequestListener は RequestHandler のメソッドを呼び出して、処理時にさまざまなタイプのリクエストを処理します (例: handleTypeARequest()、handleTypeBRequest() など)。残念ながら、RequestHandler は RequestListener (例: processNextRequest()) のメソッドも呼び出すため、循環依存関係があります。

これは、2 つの間の結合がより緊密であることを意味し、一般的にはコードの匂いと見なされます。

1 つの解決策は、異なるメソッドではなく、異なるオブジェクトを使用して各リクエストをカプセル化することです。RequestListener は、プロンプトが表示されたときにリクエストを処理し、そのリクエストに対して何らかのタイプの Request オブジェクトを返すことができます。残念ながら、私はこのアプローチがあまり好きではありません。その理由の 1 つは、より多くのオブジェクトとクラスの複雑さが増したためであり、もう 1 つはパフォーマンスの問題 (ここで重要です) のためです。RequestHandler で handleXXXRequest() メソッドを直接呼び出すと、一連のオブジェクトを作成し、必要になるまでそれらをバッファリングするためにスタックを維持するよりもはるかに高速です。

この問題に対する他の解決策はありますか?また、それは本当に問題なのでしょうか?

0 投票する
2 に答える
1602 参照

c# - マルチプロジェクトでカスタムイベントを発生させる

それは以下に関係します:私は互いに多かれ少なかれ独立して存在するはずの2つのプロジェクトを持っています。プロジェクト1は、一種のファイルシステムウォッチャーです。もう1つは私のUIのコニストです。新しいファイルがある場合、ファイルウォッチャーはイベントを発生させます。その後、ファイルのデータをデータベースに追加する必要があります。それは大まかに背景の話です。実際の問題は、ファイルウォッチャーがイベントを発生させた後、データのビューを更新するようにUIに通知したいということです。つまり、イベントはファイルウォッチャーによって発生し、UIの実装にイベントを登録する必要があります。主な問題は、両方のプロジェクトのクラスのインスタンスが必要になることです。明らかに、これは循環依存の問題を引き起こします。もちろん、CP問題のインターフェースの解決策はありますが、これでは問題は解決しません。データの作成とイベントの登録に同じオブジェクトが必要です。うまくいけば、あなたはこの問題で私を助けることができます。ありがとう。

0 投票する
4 に答える
625 参照

c++ - C++ のインクルードと循環依存関係

更新:ファイルを明確にして、質問を繰り返しましょう:

main.h

main.cpp

その他.h

その他.cpp

だから基本的に私が欲しいのはこれです:オブジェクトAをインスタンス化し、オブジェクトBをインスタンス化し、オブジェクトBからオブジェクトAのメソッドを呼び出します。このようなことは可能だと確信していますが、設計が悪いだけかもしれません私の分。どんな方向性でも大歓迎です。