From: Christian Neukirchen <chneukirchen@...>
Date: 2006-05-04T06:25:33+09:00
Subject: Re: [ANN] MinDI 0.3

Joel VanderWerf <vjoel@path.berkeley.edu> writes:

>> Isn't that a clear and obvious violation of encapsulation?
>
> Yes. Better to be clear and obvious about it ;)

*g*

> I'm not completely convinced by this style of DI. It may be no worse
> than others, though.

My DI library, Dissident, has a style that works similarily, but
services that should be injected need to be declared... personally
I like it.

    class Transformer
      inject :pattern
      inject :replacement
      
      def transform string
        string.gsub(pattern, &replacement)
      end
    end

(Note that this easily can be decoupled by adding "alias inject attr_accessor"
somewhere.)

That would work as you describe, I think:

> I suppose the Injected class could, instead of defining #method_missing,
> provide just a class method, called #uses or #uses_services, which lets
> you specify explicitly what services it uses (and defines a method for
> each one):
>
>   class Transformer
>     extend SomeModuleThatDefinesTheUsesServicesMethod
>     uses_services :pattern, :replacement
>     def transform string
>       string.gsub(pattern, &replacement)
>     end
>   end
>
> (This approach would still need the @__injectable__object__ hackery.)
>
> But I'm not sure that typos are a serious enough danger to require this
> much explicitness. It would be that much harder to subclass Transformer
> and add mocked versions of pattern and replacement, for example, or to
> mix in a module that provided pattern and replacement in some other way.
> I'd prefer the service not to have to know it is going to be used in a
> container and only to know that certain methods will be defined somehow.

> "Duck services" anyone?

IMO, PicoContainer-style constructor injection based on *argument name*
would be very nifty to have... to bad we can't inspect those in Ruby.

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org