私は循環参照を知っています（クラスaはクラスbを保持し、クラスbはクラスaを保持します）。しかし、私は十分にプログラミングしていないので、それらを使う理由を見つけるのは難しいです。人々が私に素晴らしい例を与えて、それを使う良い理由を説明できるかどうか疑問に思っていました。クラスによる循環参照の理由は？
たとえば、私は2Dのソースコードチュートリアルを見ていて、ユーザーはお互いを参照するCreatureクラスとCreatureAiクラスを作成しました。いかなる理由で？私はまだ分かりません。そのため、私は例を探していて、まだ読んでいます。
循環参照の最も明白なケースは自己参照です。リンクされたリスト、ツリー、および他の多くの再帰構造に対しては、この参照が必要です。
循環参照は、任意のネストを持つUI要素や式ツリーなど、相対クラスの階層内で暗黙的に使用されることがよくあります。
最後に、循環参照の一般的なケースは、双方向の親子関係です。親（UIパネルなど）はその子の配列への参照を保持し、各子（ボタン、表など）は親への参照。親は子どもたちにモチベーションを送って、それが有効、無効、目に見える、または見えなくなったことを伝える必要があります。子供はサイズ変更や視覚的な状態の変更などの必要性を親に知らせることができます
この最後の例はおそらくあなたのCreature-CreatureAIのペアに似ています：それらの懸念事項は異なるが、他の人は異なる仕事に協力する必要があるからです。
あなたは、それに対応する個人のリストを含むクラス会社があります。コレクション内の個々のクラスインスタンスには、それぞれが働く会社への参照が含まれています。
この方法で、どの個人がどの会社で働くかを簡単に知ることができます。特にクラスがORMまたは文書データベースを使用してデータベースに永続化されている場合は、必ずしも最適な設計であるとは限りません。
多くの場合、厳密には必要ではありませんが、オブジェクトで動作するコードには高いレベルの利便性があります。
これ以外にも、本当に必要です。例えば、いくつかのリレーションシップはデータ構造としてコード内に表現する必要があり、そのリレーションシップは再帰的です。
あり、自己参照または基準サイクルの理由の任意の数
それらはドメインモデルに固有であってもよいです。例えば人々はまた人である子供を持っている、フォルダは他のフォルダを含む他のものを含んでいる。自己参照またはサイクルは、これらのことを実装する自然な方法です。
これらは、汎用またはアプリケーション固有のデータ構造に固有のものである場合があります。例えば。リンクされたリストは、リスト内の「次の」ノードおよび「前の」ノードへの参照を含むノードで構成され、これはノードクラスがそれ自身を参照することを要求する。
循環参照の背後にある推論は、アプリケーションの設計の基本的な部分です。
または単に実装上の利便性や、以前のリファクタリングやコードベースの進化の歴史的なアーチファクトでもかまいません。
基本的に、あなたは彼らが本当に必要であればこれらの環状依存関係が存在して...と理由を把握するために、アプリケーションのコードベースで（総体的に）見てする必要があります。
OrmLiteを使用していて、コード自体に対外関係を指定する必要がある場合は、実際には*唯一の*デザインかもしれません。しかし、はい私はそれも好きではありません。 – Voo