問題タブ [cyclic-reference]

休止状態のドメイン モデルに循環参照があり、Betwixt が失敗します。ドメイン モデルを変更したくありません。

Betwixt を変更して循環参照を無視するにはどうすればよいですか?

Mark Lutzによる「LearningPython」を読んでいて、このコードサンプルに出くわしました。

これは、循環データ構造として識別されました。

だから私は疑問に思っていました、そしてここに私の質問があります：

実際のプログラミングで使用される「循環データ構造」とは何ですか？

少し混乱しているようですが、これは非常に短いコードサンプルに起因すると思います...同じオブジェクトLを使用した行がさらに数行あります

2 つのモジュールが相互にインポートするとどうなりますか?

問題を一般化すると、Python の循環インポートはどうなるでしょうか?

そのような状況をどのようにモデル化しますか? データベースはどのように設計する必要がありますか? どのクラスが必要ですか?

問題の説明:各従業員は少な​​くとも 1 つのプロジェクトに属し、各プロジェクトには多くのタスクがあり、各タスクは少なくとも 1 人の従業員に割り当てられています。

私はかき回すことができるはずです

• プロジェクトに取り組んでいる従業員。
• プロジェクトに属するタスク
• 特定の従業員が取り組んでいるタスク。

等...

循環/循環関係は悪い設計であり、排除できますか?

データベースでエンティティをどのように表現する必要がありますか? クラスを使用してエンティティをどのように表現する必要がありますか?

前もって感謝します、

私はいくつかのctypesバインディングを持っており、bodyごとに新しいbody.Freeと呼ぶ必要があります。私がバインドしているライブラリには、残りのコードから分離された割り当てルーチンがありません（それらはどこからでも呼び出すことができます）。また、循環参照を作成するために必要ないくつかの便利な機能を使用します。

デストラクタをオブジェクトにフックする信頼できる方法を見つければ解決すると思います。（weakrefsは、データがドロップされる直前にコールバックを提供してくれる場合に役立ちます。

したがって、velocity_funcを入力すると、明らかにこのコードはメガフェイルになります。

私はまた、weakrefsを介してそれを解決しようとしましたが、それらの状況は悪化しているように見えますが、ほとんど予測できません。

私がvelocity_funcを入力しなくても、これを実行すると、少なくともその時点でサイクルが表示されます。

では、構造が共有ライブラリによって割り当て/解放された場合でも、構造がガベージコレクションされるようにするにはどうすればよいでしょうか。

詳細に興味がある場合は、リポジトリがあります：http: //bitbucket.org/cheery/ctypes-chipmunk/

互いに参照する 2 つの列挙型を持つことによって引き起こされるクラスの読み込みの問題を回避する方法はありますか?

次のように定義された Foo と Bar の 2 つの列挙セットがあります。

上記のコードは、次の出力を生成します。

なぜそれが起こるのか理解しています - JVM は Foo のクラスローディングを開始します。Foo.A のコンストラクターで Bar.Alpha を認識し、Bar のクラスローディングを開始します。Bar.Alpha のコンストラクターへの呼び出しで Foo.A 参照が確認されますが、(まだ Foo.A のコンストラクターにいるため) Foo.A はこの時点で null であるため、Bar.Alpha のコンストラクターには null が渡されます。2 つの for ループを逆にすると (または、Foo の前に Bar を参照すると)、Bar の値はすべて正しくなるように出力が変更されますが、Foo の値は正しくありません。

これを回避する方法はありますか？静的マップと 3 番目のクラスで静的マップを作成できることはわかっていますが、それはかなりハックな気がします。外部マップを参照する Foo.getBar() および Bar.getFoo() メソッドを作成することもできるので、インターフェイス (パブリック フィールドの代わりにインスペクターを使用している実際のクラス) も変更されませんが、それでも感じられます。私にはちょっと不潔です。

(実際のシステムでこれを行っている理由: Foo と Bar は、2 つのアプリが相互に送信するメッセージのタイプを表します。Foo.b フィールドと Bar.f フィールドは、特定のメッセージに対して予想される応答タイプを表します。サンプル コードでは、app_1 が Foo.A を受信すると、Bar.Alpha で応答する必要があり、その逆も同様です)。

前もって感謝します！

私は現在、に大きく依存するアプリケーションをまとめており、shared_ptrこれまでのところすべてがうまくいっているようですshared_ptr.

最も認識されている問題の 1 つは、循環依存関係です。これらの問題は、チェーンのオブジェクトの有効期間に影響を与えないshared_ptrを格納することで解決できます。weak_ptrただし、外部オブジェクトへのポインターを a 経由で保存する必要がある場合に頭を悩ませていますweak_ptr-それが禁止されているのか、推奨されていないのか、それとも安全なのかわかりません

次の図は、私が何を意味するかを説明しています (黒い矢印は を示しshared_ptr、破線は を示しますweak_ptr)。

代替テキスト http://img694.imageshack.us/img694/6628/sharedweakptr.png

• 親にはshared_ptr、 を使用して親を指す 2 つの子へのが含まれますweak_ptr。
• 最初の子のコンストラクターで、親を介して2 番目の子weak_ptrへのポインターを取得し、それをローカルに保存します。

コードは次のようになります。

私はこれをテストしましたが、問題なく動作しているようです(メモリ リークの報告はありません) が、私の質問は次のとおりです: これは安全ですか? もしそうでなければ、なぜですか？

お恥ずかしい話ですが、最近、相互に関連する 3 つの異なるタイプの銀行エンティティに対して 1 つのテーブルを作成する必要がある状況がありました。説明させてください。

統治銀行、地方の支店を運営する通常の銀行、またはこの銀行の下で運営されている地方の支店、またはこの階層には属さないが地方の支店とのみ取引するリテール銀行の支店の詳細を保持する BANK テーブルを想像してみてください。

以前は、FK 制約 (管理銀行、地方支店を運営する銀行、地方支店、リテール銀行支店にそれぞれ 1 つずつ) を使用して、これらに 4 つの異なるテーブルを用意することにしました。しかし、TRANSACTION テーブルの作成に移ったとき、これらのエンティティのいずれかの間でトランザクションが発生する可能性があるため (例: 地方の支店と小売店の間、地方の支店同士など)、当惑しました。これは、銀行エンティティの「ソース」と「宛先」ID の記録を保持するだけでなく、アプリケーション ロジックがクエリのためにどのテーブルに結合するかを決定するのに役立ついくつかのデータを保持する必要があることを意味しました。悪い。

さらに、USER テーブルがあり、ユーザーはこれらのエンティティのいずれかに属している可能性があります。ここでも、銀行エンティティの 4 つの異なるテーブルがあると問題がありました。ユーザーが地方の支店、小売店、または管理銀行に属しているかどうかはどうすればわかりますか?

したがって、単一の BANK テーブルを作成しました (基本的に、これらは互いに取引できるため、類似したエンティティであるためです)。親機関の ID の値を保持する PARENT 列をテーブルに追加しました (別の方法で FK を使用して達成した関係)。したがって、地方の支店は、親列に営業銀行の ID を持ちます。小売店の支店には親がないため、値は NULL です。

私が今見ている問題は、循環参照である BANK テーブルに PK/FK 関係があることです。

私の質問は次のとおりです。これはどれほど悪いですか？そして、何が抜け道になるでしょうか？

CoreData エンティティ X と、このエンティティ XController のコントローラーがあります。これで、X エンティティのコレクションと XGroupController を含む別のエンティティ XGroup ができました。

問題は、XGroupController が XController と対話する必要があることです。XGroupController に XGroup を渡して観察し、X エンティティから XController を取得するだけでよいでしょう。

質問は次のとおりです。エンティティ内のコントローラーへの参照を (保持サイクルを避けるために弱い) 格納することは良い考えですか? ちょっと「ダメ」な感じです。このための別の設計パターンはありますか?

[編集] 追加情報: XController/XGroupController はビュー コントローラーです。「間違っている」と感じた理由は、ビューレイヤーがモデルレイヤーにあってはならないからです。したがって、@TechZen は最初の段落で正しいです。

しかし、その参照がない場合、どうすればよいでしょうか。私が見る方法は、XGroupController にすべての既存の XController を渡し (さらに、変更されたときにそれらを更新し)、XGroup 内の項目が変更されたときに、対応するコントローラーを見つけることです (その X エンティティの XControllers プロパティが XGroup にあるかどうかを確認することによって)。そして最後に XController と対話します。

モデルがすでに非常にうまく処理しているものについては、もう一度作業を行う必要があります。コントローラ レイヤでグループをもう一度処理しなければならない場合、モデル レイヤは意味がありませんか?

場所/複雑さの点での違いは非常に重要です。何か不足していますか? (おそらく、私のシナリオでは、モデルを介して XGroupController が XController に提供する必要がある情報を保存するのは意味がないことを追加する必要があります)。