Re: DI/wiring
On 4/22/2013 12:03 AM, Daniele Futtorovic wrote:
In code terms, instead of:
class Actor {
void act( Context c ){ doSomethingWith( c.getXXX() ); }
}
Just to be clear, I was advocating using constructors, not method
parameters:
public class Actor {
private Context c;
public Actor( Context c ) {this.c = c}
public void act() { doSomethingWith( c.getXXX() ); }
}
This is really really different:
You'd have:
class Actor {
void act(){
doSomethingWith( ContextHelper.getThreadLocalContext().getXXX() );
}
}
Now actor does something different depending on what thread is invoking
a method. My class was invariant with respect to the thread invoking its
method. No matter who calls "act()" the result will always be the same.
Since modern systems often use thread pools and the worker threads are
supposed to be generic and often randomly assigned, I can't see too many
cases where your thread local context is going to be useful. Worse, if
an generic worker thread has a context and then is assigned to another
task... the results could be random and unpredictable, and really hard
to debug as well.
I'm sure you must have some use case in mind where a thread local is
useful, but I'm having a hard time seeing it. It feels like you push
the context/initialization problem into the threading system, where it's
actually going to be harder to manage. In a system that was designed
from the ground up to support contexts attached to threads, OK it might
work, but in many existing systems it seems difficult to add.