>This is very basic, but imagine in our MagicKingdom project (and only there) >we need to have a Frog class that'll do something special when kissed. Wiring
> this is easy, and none of the classes will depend on each other. That's
>what i meant with flexibility.
new Girl(new Boy()).Kiss();
Girl girl = (Girl) pico.getComponentInstance(Girl.class);
The pico solution is clearer? I don't think so.
In my solution the classes don't depend on each other. One line.
Very simple. If i need to make it more complex then i can do:
Still simple. Still clear. I can add args and it's clear
what the args are and what they mean by looking at the
class doc. The factory gives a layer where i can do lots
of lookups, verifications, notifications, etc, and all that
is clear in the code.
Pico on the other hand has introduced a base class, a lifecyle that
has nothing to do with kissing yet is used to trigger kissing,
a container that i have to register with, i have to ask the container
for an instance and then it somehow constructed the object
using a rules that i can only guess at. Where did the boy
come from? What args were passed to the boy? What if need
to other things to the boy before he can be kissed?
How would i cache boys? Is the same boy used
every time? When i delete the boy what happens? The life cycle
is overly simplistic for components in an application. What
if i want a different lifecycle? Etc, etc.
Now, in reality you don't want just any boy and any girl. You
want to "wire" specific boys and girls. That may take a lot of
context to decide. I like that code immediately visible.
FYI, i've always liked the pico documentation.
>I am unable to disagree with you on this point, but why use these
>to implement your own proprietary pseudo-container when you
>can get tested third-party solutions for free that
>do the same thing better?
Well, i am still not sure that i need help "wiring" my application
together, so the benifit is unclear to me :-)
>Sure, but if you implement a new class to be construct with the
>factory or want to configure some constructed instances different
>in some cases, you have to extend the static factory method,
>may need to introduce some more parameters to its
For a lot of code you don't need factories of any sort. And for those
that do the code does what is necesary for that object so it
is very specific and clear what is happening. Trying to get
rid of this code is a phyrric victory.