Re: DI/wiring
On 22/04/2013 19:59, markspace allegedly wrote:
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() ); }
}
Yes; this is why I spoke of "constructor or method parameters".
See, the problem, or issue, with this approach is that you make the
context part of the actor's state. Meaning the actor is bound to the
context, rather than being context-independent. For instance, the
component wouldn't be reusable for a different context.
Now, there may be situations where that would be the right thing to do.
Yet, because of that, this approach to me is inferior to passing the
context to the main actor method (the method that encapsulates the unit
of work).
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'll have to disagree with you here. All systems that use thread pools
will involve some sort of dispatch mechanism that consumes a queue of
work units. I do not believe it is far fetched to imagine that the
dispatch mechanism would run as exemplified in the following:
while take-from-queue
set-up-context
try {
execute-task
} finally {
clean-up-context
}
The only situation, then, where the ThreadLocal wouldn't work is when
the work units are executed on multiple threads. I may be wrong, but I
do not see this as being the majority of cases -- to the contrary.
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.
It is true that it is more fragile, and for that reason alone may be
legitimately rejected, I'll grant you that. But it is not difficult to
add; quite the contrary, it is much easier to add to an existing system
than the one you suggested, because it does not involve any change in
the API (only to the implementation).
Now, don't get me wrong, I'm not trying to suggest this is anywhere the
be-all and end-all of programming techniques. Indeed, because it is
fragile and less explicit (and hence more difficult to grasp) than the
other way (passing a context to the actor's method), the latter is my
preferred and indeed the standard approach I opt for when designing a
piece of code that involves a dispatch mechanism (which is most of
them). I merely intended to mention that other possibility for the record.
--
DF.