(a) would be a good idea anyway, because it would make it possible to
use other null objects than the default ones the dep. mgr. provides.
For example, in some cases i would like to have a "null" object for a
LogService that prints to system out. Other examples are proxies that
throw exceptions on any invoked method, etc.
Hi marcel,
Thank you very much for your quick response and very constructive feedback.
I agree with both Peter and Richard, (a) seems the most flexible
approach and even serves additional purpose, I can't think of a smarter
approach.
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.
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!
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 :)
As for iPojo (I know I won't be making new friends with this..),
although i've tried to use it, i haven't quite understood its true benefits:
- the xml syntax has the usual drawbacks (no compilation error: so we
spend ages debugging typos)
- and annotations are just another form of API that all my classes end
up depending upon.. also the description of my service bindings is
spread out everywhere in the code instead of being clearly gathered in
an xml (like SCR) or a piece of code (like DependencyManager)
Arjun (please don't beat me!)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
