0

I'm using robot legs, I've got a bunch of ServiceResponses that extends a base class and have a dependency on a Parser, IParser. I need to wire in a parser specific to the subclass. Here's an example:

ModuleConfigResponse extends SimpleServiceResponse and implements IServiceResponse.

The initial part is easy to wire in the context, here's an example:

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

Each Response uses a parser that is used by the baseclass:

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

The question is how to tie these together. The base class could have:

[Inject]
public var parser : IParser

But I can't define the type ahead of time. Im wondering if there a nice way of wiring this in the context. For the moment I've decided to wire this up by instanciating responses in a ResponseFactory instead so that I pay pass the parser manually in the constructor.

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

serenskye
  • 3,467
  • 5
  • 35
  • 51

2 Answers2

1

I realised that not everything can be mapped in the context, RL trapped me into this way of thinking. But I've realised that its far better to map a factory to produce these objects which have very specific dependencies, than littler the codebase with marker interfaces or strings :)

serenskye
  • 3,467
  • 5
  • 35
  • 51
0

one solution is to have the following in your base class:

protected var _parser : IParser

Then for instance in ModuleConfigResponse

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

But TBH, using named injections is STRONGLY discouraged, you might as well use a marker interface:

public interface IModuleConfigParser extends IParser{}

the base class stays the same, but ModuleConfigResponse would then use:

[Inject]
public function set parser( value : IModuleConfigParser ) : void{
    _parser = value;
}
Creynders
  • 4,573
  • 20
  • 21
  • Mmh I came to the conclusion with another developer that named injections are not so bad depending on the circumstance, where it is clearly seen in a context or factory. I think that marker interfaces are just as bad. Your first example would be okay, however some responses can use different parsers - re-usability. For now I'll stick to a factory which encapsulates the string names too. :). – serenskye Mar 02 '12 at 14:25
  • Yeah they're definitely not ideal, but they do have the benefit of CT typechecking. But TBH I have never encountered the situation you describe above, probably due to a different coding/design style, so I just gave an answer to solve the question as-is. – Creynders Mar 02 '12 at 16:13