Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail
From: Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: DI/wiring
Date: Mon, 22 Apr 2013 09:03:32 +0200
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <kl2n6i$3l5$1@dont-email.me>
References: <DI-wiring-20130418174944@ram.dialup.fu-berlin.de> <kkpgls$6aq$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 22 Apr 2013 07:00:34 +0000 (UTC)
Injection-Info: mx05.eternal-september.org; posting-host="b455eddc43cd335ec99b64d1f5addc5a"; logging-data="3749"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/IT07rkC+UGwbDpcqupZ2T"
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
In-Reply-To: <kkpgls$6aq$1@dont-email.me>
Cancel-Lock: sha1:GfcYZgHYTYNlCjprPV3XDQTqcq0=
Xref: csiph.com comp.lang.java.programmer:23565

On 18/04/2013 21:16, markspace allegedly wrote:
> On 4/18/2013 9:03 AM, Stefan Ram wrote:
>>    I have »invented« myself something that also seems to be
>>    known as »dependency injection« or »wiring«. I am doing it
> 
> I should have a look at Joerg's answer myself, but here's another idea.
> 
> Make an app context object that holds the state of your app.
> 
> class Context {
>   Engine getEngine()....
>   Printer getPrinter()...
> }
> 
> Inject that into submodules in the code.  Submodules are larger than
> classes and can treat the context as immutable.  The context then
> becomes global but only for that module.  The idea is that you still get
> dependency injecting, but you can still test reasonably as well.
> 
> class SomeConfig {
>   Context context;
>   public SomeConfig( Context c ) { context = c; }
> 
>   public init() {
>    Component c0 = new Component( context );
> 
> ....
>   }
> }
> 
> class Component  {
>   Context context;...
>   public printIt() {
>     context.getPrinter().do something...
>   }
> }
> 
> This reduces boilerplate but doesn't eliminate it.  For some projects it
> might be better to get a real dependency injection framework.

As a side note, since this approach has the drawback of requiring
additional constructor or method parameters (and hence targeted
factoring), I have in such cases often found it useful to provide the
context object via the threadlocal functionality.

In code terms, instead of:
  class Actor {
    void act( Context c ){ doSomethingWith( c.getXXX() ); }
  }
You'd have:
  class Actor {
    void act(){
      doSomethingWith( ContextHelper.getThreadLocalContext().getXXX() );
    }
  }

-- 
DF.