問題タブ [circular-dependency]

(ジャバの質問)

内部クラスのフィールドを参照すると、囲んでいるクラスと内部クラスの間で循環依存が発生しますか?

どうすればこれを回避できますか?

以下に例を示します。

それぞれがクラスを含む 2 つのモジュールがあります。問題は、それらのクラスが相互に参照していることです。

たとえば、room モジュールと CRoom と CPerson を含む person モジュールがあるとします。

CRoom クラスには、ルームに関する情報と、ルーム内のすべての人の CPerson リストが含まれています。

ただし、CPerson クラスは、たとえばドアを見つけたり、部屋に他の人がいるかどうかを確認したりするために、その部屋に CRoom クラスを使用する必要がある場合があります。

問題は、2 つのモジュールが相互にインポートしていることです。2 番目にインポートされたモジュールでインポート エラーが発生します :(

C ++では、ヘッダーのみを含めることでこれを解決できました。どちらの場合も、クラスには他のクラスへのポインターがあるだけなので、ヘッダーには前方宣言で十分です。

両方のクラスを同じモジュールなどに配置する以外に、Pythonでこれを行う方法はありますか?

編集：上記のクラスを使用した問題を示すpythonの例を追加

エラー：

トレースバック (最後の最後の呼び出し):
ファイル "C:\Projects\python\test\main.py"、1 行目、
部屋からのインポート CRoom
ファイル "C:\Projects\python\test\room.py"、1 行目、
人からのインポートCPerson
ファイル「C：\ Projects\python\test\person.py」、1行目、
部屋のインポートからCRoom
ImportError：名前CRoom
room.pyをインポートできません

person.py

(ほとんど) すべてのコードがヘッダー ファイルに存在するように、C++ プログラムを構成できます。基本的には、C# または Java プログラムのように見えます。.cppただし、コンパイル時にすべてのヘッダー ファイルを取り込むには、少なくとも 1 つのファイルが必要です。今では、この考えを絶対に嫌う人がいることを私は知っています. しかし、これを行うことの説得力のある欠点は見つかりませんでした。いくつかの利点を挙げることができます：

[1] コンパイル時間の高速化。.cpp ファイルは 1 つしかないため、すべてのヘッダー ファイルは 1 回だけ解析されます。また、1 つのヘッダー ファイルを複数回インクルードすることはできません。そうしないと、ビルドが中断されます。別のアプローチを使用してコンパイルを高速化する方法は他にもありますが、これは非常に簡単です。

[2] 循環依存関係を完全に明確にすることで、循環依存関係を回避します。ClassAinがinClassA.hに循環依存している場合、前方参照を配置する必要があります。(これは、コンパイラが循環依存関係を自動的に解決する C# および Java とは異なることに注意してください。これは、IMO の悪いコーディング プラクティスを助長します)。繰り返しになりますが、コードがファイル内にある場合は循環依存を回避できますが、実際のプロジェクトでは、誰が誰に依存しているかがわからなくなるまで、ファイルにランダムなヘッダーが含まれる傾向があります。ClassBClassB.h.cpp.cpp

あなたの考え？

PHPアプリケーションの循環依存の問題であると私が信じていることを経験しています。これが正しくない場合はお知らせください。状況は次のとおりです。

LogManagerとDBSessionの2つのクラス。

DBSessionはデータベースとの対話に使用され、LogManagerはファイルへのログ記録に使用されます。どちらも私のアプリケーションで広く使用されています。DBSessionのインスタンスを作成するときは、コンストラクターパラメーターを介してLogManagerのインスタンスを指定する必要があります。これは、DBSessionが情報をファイルに記録し、LogManagerインスタンスを使用してこれを行うためです。

ここで、LogManagerを拡張して、テキストファイルではなくデータベーステーブルにもログを記録できるようにしたいと思いました。当然、既存のクラスを再利用するのが好きですが、これが面白い状況をもたらすことにすぐに気づきました。

DBSessionは、構築のためにLogManagerのインスタンスをすでに必要とします。LogManagerでDBSessionクラスを再利用する場合は、DBSessionのインスタンスが必要になります。どうすれば両方の要求を満たすことができますか？明らかに、私のアプローチには何か問題があるに違いありません。

これを修正することをどのように提案しますか？

よろしくお願いします。

2 つの関数間に循環依存関係があります。これらの各関数を独自の dll に常駐させたいと考えています。これをビジュアルスタジオでビルドすることは可能ですか?

-> foo.dll にコンパイルする必要があります

-> bar.dll にコンパイルする必要があります

Visual Studio で 2 つのプロジェクトを作成しました。1 つは foo 用、もう 1 つは bar 用です。「参照」をいじって数回コンパイルすることで、必要な dll を取得することができました。ただし、ビジュアルスタジオがこれをクリーンな方法で行う方法を提供しているかどうかを知りたいです。

foo が変更された場合、bar の実装ではなく、bar の署名のみに依存するため、bar を再コンパイルする必要はありません。両方の dll に lib が存在する場合、新しい機能を 2 つのうちのいずれかに再コンパイルしても、システム全体は引き続き機能します。

私がこれを試している理由は、現在静的にリンクされている循環依存関係を持つレガシー システムがあるためです。さまざまな理由から、dll に移行したいと考えています。すべての循環依存関係をクリーンアップするまで待ちたくありません。私は解決策について考えていて、Linuxでgccを使っていくつか試してみましたが、私が提案したことを実行することが可能です。したがって、互いに依存し、互いに独立して構築できる 2 つの共有ライブラリを使用できます。

循環依存が良いことではないことはわかっていますが、それは私がしたい議論ではありません。

Windows フォーム アプリケーションで次の循環参照を解決するための適切なパターンを探しています。

• アセンブリ 1 には、アセンブリ 2 でフォームを「.Show」する Infragistics メニュー項目を含む Windows フォームが含まれています。
• アセンブリ 2 には、アセンブリ 1 でフォームを「.Show」する Infragistics メニュー項目を含む Windows フォームが含まれています。

通常、メニューには、アプリケーション全体で同じ項目があります。したがって、アセンブリ 1 とアセンブリ 2 の両方に、互いのフォームを「新規作成」して表示するための相互参照があります。

サイズに関する注意: 私のアプリは既存のアプリであるため、状況は上記の 2 つのアセンブリの状況ほど単純ではありません。しかし、上記の問題を単純に解決できれば (おそらく を実装しないで)、それをはるかに大きなアプリケーション (約 20 個のコンポーネント、コンポーネント間で互いにポップアップするいくつかのフォームを含む) に適用できます。

いくつかの解決策を考えてみましたが、どれも面倒です。私が見逃している簡単な解決策はありますか？

2 つのクラス Foo と Foo Sub があり、それぞれが異なるファイル foo.rb と foo_sub.rb にあるとします。

foo.rb:

foo_sub.rb:

循環依存のため、これは機能しません。一方のクラスを他方なしで定義することはできません。私が見たさまざまな解決策があります。そのうちの 2 つを避けたいと思います。つまり、それらを同じファイルに入れ、循環依存関係を削除することです。したがって、私が見つけた他の唯一の解決策は、前方宣言です。

foo.rb:

foo_sub.rb

残念ながら、3 つのファイルがある場合、同じことを行うことはできません。

foo.rb:

foo_sub.rb:

foo_sub_sub.rb:

foo_sub.rb が必要な場合、FooSub は foo_sub_sub.rb 内の初期化されていない定数です。それらを同じファイルに入れたり、循環依存関係を削除したりせずに、これを回避する方法はありますか?

Windowsフォームアプリケーションでメモリリークを実行しようとしています。私は今、いくつかの埋め込まれたフォームを含むフォームを見ています。私が心配しているのは、子フォームがコンストラクターで親フォームへの参照を取得し、それをプライベートメンバーフィールドに保持することです。ですから、ガベージコレクションの時期が来ると私には思えます。

親は、controlsコレクションを介して子フォームへの参照を持っています（子フォームはそこに埋め込まれています）。子フォームはGCされません。

子フォームには、プライベートメンバーフィールドを介した親フォームへの参照があります。親フォームはGCされません。

これは、ガベージコレクターが状況を評価する方法を正確に理解していますか？テスト目的でそれを「証明」する方法はありますか？

core.xml.dll と core.string.dll という名前の 2 つのアセンブリ (とりわけ) を含む再利用可能なクラス ライブラリを設計しています。

xml アセンブリは、いくつかの文字列ヘルパー メソッドを使用するために、文字列アセンブリを参照します。

ただし、xml アセンブリに含まれるメソッドを使用することでメリットが得られる文字列メソッドが存在するようになりました。

文字列アセンブリから xml アセンブリを参照すると、循環依存関係が作成され、ソース コードから両方のアセンブリをビルドできなくなります。（つまり、ニワトリと卵の問題）。

「自分自身を繰り返さない」という原則に従うために、両方のアセンブリで機能が重複することを避けたいと思います。実装にバグが見つかった場合は、1 か所だけ修正したいと考えています。

アセンブリを 1 つにマージすることはできますが、アセンブリの結合性が低下するため、これは理想的ではありません。

特定のクラスにわずかな変更を加えるだけで、アセンブリ全体を再構築して再展開する必要があります。また、最終的には、非常に多くの依存関係があるため、1 つの巨大なライブラリ アセンブリになってしまう可能性があります。

では、再利用可能なライブラリ アセンブリのセットのコンテキストでは、ここで使用する最善の方法は何でしょうか? また、.NET フレームワーク自体はこの問題にどのように対処していますか?

(Reflector では、System.Configuration.dll が System.XML.DLL を参照しているように見えます。逆もまた同様です。これは実際に正しいのでしょうか?もしそうなら、循環依存関係はどのように管理されていますか?)

いくつかの悪い設計上の決定（他の誰かによって行われた:)）が原因でC ++プロジェクトで複数のコンパイル/リンカーエラーに直面している状況に陥ることがよくあります。これは、異なるヘッダーファイルのC ++クラス間の循環依存につながります（これも発生する可能性があります）同じファイル内）。しかし、幸いなことに（？）これは、次に再び発生するときにこの問題の解決策を思い出すのに十分な頻度では発生しません。

ですから、将来簡単に思い出せるように、代表的な問題と解決策を一緒に投稿します。もちろん、より良い解決策は大歓迎です。

• A.h

  /li>

• B.h

  /li>

• main.cpp

  /li>