2

これは、以前の質問 ( 「new」と「gen」の違い) からのフォローアップの質問です。

生成が行われる前に依存関係を構造体に渡す方法はありますか?

簡単にテストできる方法でコードを書くことに興味があります。現在、私たちのコードベースは get_enclosing_unit() を頻繁に使用して、トランスレーター/パラメーターなどのヘルパー構造体へのポインターを取得します。これにより、コードベースに双方向の依存関係が多数存在します。これは、他の構造体から独立してピースをテストするのが難しいことを意味します。

これは私が避けようとしているものの例です。

pregenerate() is also {
  var translator : my_translator_s = get_enclosing_unit(some_enclosing_unit).get_translator_pointer();
};

some_enclosing_unit に依存することは避けようとしています。これは、構造体とは関係がなく、単体テストの邪魔になるためです

e にコンストラクターがないため、get_enclosing_unit() を使用せずに、呼び出し元のユニット/構造体から依存関係を渡す方法がわかりません。「new... with」は役立つように思えますが、最後の質問で学んだように、それは基礎となるフィールドを生成せず、「gen... keep」は世代が必要とする依存関係を後まで設定しません。世代が完成しました。

4

1 に答える 1

2

アーキテクチャがすでに絡み合っているように見えるため、簡単な答えはありません。インスタンス ツリー内のこれらの双方向の垂直方向の依存関係について疑うのは正しいことです。一般に、上からの制約 (CFA) 戦略に従う必要があります。

unit child_u {
    p_tr: translator_s;
    keep soft p_tr == NULL; // safety catch, in case you forget to constrain it
};

unit parent_u {
  tr: translator_s;
  child: child_u is instance;
  keep child.p_tr == tr;
};

また、ユニット間の世代依存を持たないことをお勧めします。このようにして、ユニットへのすべてのポインターを生成不可のままにし、生成後に呼び出されるユニットの connect_pointers() メソッドでそれらを接続できます (ドキュメントを参照)。

extend child_u {
  !p_parent: parent_u;
}
extend parent_u {
  connect_pointers() is also {
    child.p_parent = me;
  };
};

childしかし、もちろん、そのポイントに制約を設定することはできませんparent。生成されたポインターが絶対に必要な場合は、keep soft <ptr> == NULLそれを制約するのを忘れた場合に失敗を引き起こすために使用します。

ちょうど私の2セント。

于 2015-07-01T13:50:20.930 に答える