2012-03-02 17 views
0

私はロボットの足を使っています。基本クラスを拡張し、パーサー、IParserに依存するServiceResponsesがたくさんあります。私は、サブクラスに固有のパーサーで配線する必要があります。次に例を示します。基本クラスに属する依存関係を配線する

ModuleConfigResponseはSimpleServiceResponseを継承し、IServiceResponseを実装します。

最初の部分は、コンテキスト内の配線が容易であり、ここでの例です:

injector.mapClass(IServiceResponse, ModuleConfigResponse); 
injector.mapClass(IServiceResponse, SimpleServiceResponse, "roomconfig"); 
..etc 

各応答は、基底クラスによって使用され、パーサー使用しています。

injector.mapValue(IParser, ModuleConfigParser, "moduleconfig"); 
injector.mapValue(IParser, RoomConfigParser, "roomconfig"); 

の質問はどのようにありますこれらを結びつける。基本クラスは次のようになります。

[Inject] 
public var parser : IParser 

しかし、私は事前に型を定義することはできません。私は文脈でこれを配線する良い方法があるのだろうかと思っています。現時点では、レスポンスファクトリーでレスポンスをインスタンス化することで、これを結びつけることにしました。そのため、パーサーをコンストラクタで手動で渡すようにしています。

injector.mapValue(IParser、ModuleConfigParser、 "moduleconfig");

答えて

1

は私ではない、すべてがコンテキストにマッピングすることができることを実現し、RLは、この考え方に私を閉じ込められました。しかし、私は非常に特定の依存関係を持つこれらのオブジェクトを生成するために工場をマッピングするほうがはるかに優れていることに気がついた。

0

一つの解決策は、あなたのベースクラスに次のようにすることです。

​​

はその後ModuleConfigResponse

[Inject(name='moduleconfig')] 
public function set parser(value : IParser) : void{ 
    _parser = value; 
} 

しかし、TBHで、たとえば、名前の注射を使用することは強くお勧めし、あなたにも使用することがありますマーカーインタフェース:

public interface IModuleConfigParser extends IParser{} 

基本クラスは同じですが、M oduleConfigResponseはその後、使用します。

[Inject] 
public function set parser(value : IModuleConfigParser) : void{ 
    _parser = value; 
} 
+0

Mmh私は注射と呼ばれる別の開発者文脈や工場ではっきりと見える状況によってはそれほど悪くない。私はマーカーのインターフェイスがちょうど悪いと思う。あなたの最初の例は大丈夫でしょうが、いくつかの応答では再利用性の異なるパーサーを使用できます。今のところ私は文字列名もカプセル化するファクトリに固執します。 :)。 – serenskye

+0

彼らは確かに理想的ではありませんが、彼らはCTのタイプチェックの恩恵を受けています。しかし、TBH私は上記のような状況に遭遇したことはありません。多分異なるコーディング/デザインスタイルのせいかもしれません。 – Creynders

関連する問題