循環参照を認識しています (クラス A はクラス B を保持し、クラス B はクラス A を保持します)。しかし、私は十分にプログラミングしていないので、それらを使用する理由を見つけるのは困難です. 人々が私にいくつかの例を挙げて、それらを使用する正当な理由を説明できるかどうか疑問に思っていました.
私の場合、現在 2D ソース コードのチュートリアルを見ていて、ユーザーは相互に参照する Creature クラスと CreatureAi クラスを作成しました。いかなる理由で？まだわからないので、例を探していて、まだ読んでいます。
あなたは、そこで働く個人のリストを含むクラス Company を持っています。コレクション内のすべての個人クラス インスタンスには、それらが勤務する会社への参照が含まれています。
これにより、どの個人がどの企業で働いているかを簡単に知ることができます。クラスが ORM またはドキュメント データベースを使用してデータベースに永続化されている場合は特に、必ずしも最適な設計ではないことに注意してください。
循環参照の最も明白なケースは自己参照です。リンクされたリスト、ツリー、およびその他の多くの再帰構造に必要です。
循環参照は、任意の入れ子を持つ UI 要素や式ツリーなど、関連するクラスの階層内で暗黙的に使用されることがよくあります。
最後に、循環参照の一般的なケースは双方向の親子関係です。親 (UI パネルなど) はその子の配列への参照を保持し、各子 (ボタン、テーブルなど) はその子の配列への参照を保持します。親。親は、モチーフ化を子に送信して、有効、無効、表示、または非表示になったことを伝える必要があります。子供は、サイズ変更、視覚状態の変更などの必要性を親に通知する場合があります。
この最後の例は、Creature-CreatureAI のペアにおそらく似ています。関心が異なるため分離していますが、異なるタスクで協力する必要があるため、相互に参照しています。
自己参照または参照サイクルの理由はいくつもあります
それらはドメイン モデルに固有のものである場合があります。たとえば、人には人でもある子供がいて、フォルダには他のフォルダを含む他のものが含まれています。自己参照またはサイクルは、これらを実装するための自然な方法です。
これらは、一般的なデータ構造またはアプリケーション固有のデータ構造に固有のものである場合があります。例えば。リンクされたリストは、リスト内の「次の」ノードと「前の」ノードへの参照を含むノードで構成されます。これには、Node クラスがそれ自体を参照する必要があります。
循環参照の背後にある理由は、アプリケーションの設計の基本的な部分になる可能性があります。
または、単に実装の利便性、または以前のリファクタリングまたはコードベースの進化の歴史的な成果物である可能性があります。
基本的に、アプリケーションのコードベースを (全体的に) 見て、これらの循環的な依存関係が存在する理由と、それらが本当に必要かどうかを判断する必要があります。
多くの場合、厳密に必要というわけではありませんが、オブジェクトを操作するコードに高いレベルの利便性を提供します。
また、本当に必要な場合もあります。たとえば、一部の関係はデータ構造としてコードで表す必要があり、その関係は再帰的です。