[Grok-dev] Alternatives to Grok for Interface based dependency injection

[Alec Munro]

Hi Patrick,

I should have something figured out by Monday, so I will post it to this thread.

On Thu, May 21, 2009 at 7:43 PM, Patrick Gerken <do3ccqrv at googlemail.com> wrote:
> Hi Alec,
>
> first, if some are interested in your results of the evaluation, is there
> some place where one can read something about the results? I am curious.
>
> On Thu, May 21, 2009 at 19:38, Alec Munro <alecmunro at gmail.com> wrote:
>>
>> Hi List,
>>
>> (I believe this is known as a GBCW message, though I'm not sure what
>> that stands for)
>>
>> After wrestling with Grok's installation on and off for the past 6
>> months, I have finally come to accept that it currently doesn't
>> provide us a compelling enough reason to accept that pain (and I got
>> real tired of troubleshooting when people would be unable to install
>> my software because of one of Grok's dependencies). Our primary use of
>> Grok is the adaptation mechanism, and we specifically use it as an
>> interface driven dependency injection tool. However, I realized today
>> that the way we had been doing that, with adapter lookups as needed,
>> often in the middle of other code, reduced our code clarity and
>> testability, by adding an additional dependency that was not easily
>> apparent to someone looking at initializer or method signatures.
>
> If I understand you correctly, you have two issues, one is the installation
> issues under windows, about which I can't say a thing.
> Your other issue is about the dependency of your code to the component
> architecture, and that you would like to be able to test code without that
> dependency, at least this is what I understood.
> You might be able to solve this by writing your own grokkers, that could
> inject your dependencies during grokking time. For testing you could fill
> the dependencies in another way. That functionality is part of martian. Have
> you taken a look into that?
>

I think I'm using overloaded terminology here. :)
When I say "dependency", I'm talking about a run-time dependency of
the object under test, rather than a compile-time module dependency.
My recent readings on testability have convinced me that these types
of dependencies should be in initializer or method signatures, so
anyone wanting to use an object or method has a clear specification of
what it depends on. What I found with the adapter pattern is that I
would often have adapter lookups in the middle of a method block,
which would mean that method depended on an appropriate adapter being
registered. I'm sure best practices could be established that would
avoid this ever becoming problematic, but if possible, I would rather
use a dependency injection framework that will insist I keep my
dependencies properly specified.

Thanks for your interest, and your suggestions,

Alec