On Sep 19, 2008, at 16:03 , Arjun Panday wrote:
Now, the NullObject pattern as such, i never quite figured out a
real life use case for it:
Either my dependency is "required" and this means i do need it to
work, and a NullObject won't do the trick,
or my dependency is "optional" and it means my code should handle
the loss of service.
So basically my code always needs to handle the loss of service.
If a dependency is "required" the DM never generates a NullObject,
that is correct.
If it is "optional" then you can use it in some cases, mostly if you
"don't care" if something actually happens or not.
Logging is a good example. If there is no log service, you might not
care that nothing gets logged. So code that uses LogService might have
lots of log statements embedded. If you do not use the NullObject
pattern, you might need to check for null every time. Basically, this
pattern saves you that extra code.
Without:
class A {
volatile LogService m_log;
public void myMethod() {
// log something
LogService log = m_log;
if (log != null) {
log.log(LogService.LOG_WARNING, "important message");
}
}
}
With:
class A {
volatile LogService m_log;
public void myMethod() {
// log something
m_log.log(LogService.LOG_WARNING, "important message");
}
}
But I fully agree in a lot of cases you do want to be notified
explicitly if your optional dependency becomes (un)available. In those
cases, you can turn off "auto config" and use callbacks instead. Your
call ;)
I even find the NullObject pattern dangerous for it lets me think
that everything goes smoothly while actually it doesn't.. honestly
i'd rather see a big ugly NullPointer stack trace so at least i know
where i screwed up!
That's the downside.
Personally I find all this magic with automatically plugged random
stuff extremely confusing when debugging.. but that's probably
because i'm old fashioned and a bit slow :)
Agreed, even though I don't use byte code manipulation, the reflection
based injection does introduce some "magic". I did want to keep the
POJOs as simple as possible, so even requiring plain setters is
something I did not want. Of course, you're free to use them and turn
off the automatic injection.
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
