Hello,
I was wondering what is iPojo's mission in life: just to make it a bit
easier to code in OSGi or the grand idea to lift the Java language to a
higher abstraction. This philosophical question is important to me
because iPojo like most other DI frameworks seems highly viral.
For example suppose I start out with a single component class that
creates all it's collaborators with POJN (Plain Old Java New :). At this
point I will have to inject all service dependencies into this
uber-component and have it pass them on to the constructors of it's
collaborators. Soon I get sick of my bad style and decide to let iPojo
manage the collaborators and pass around the dependencies for me. And as
soon as the collaborators are under iPojo's wing all classes that need
them will also have to be iPojo managed. And so in no time almost all my
classes will be components. All that will be left are light-weight data
objects and static utilities. The former could soon acquire behavior of
their own and will inevitably become components because they will likely
need to collaborate with other components. As for the static utilities:
unless they are bundles of stand-alone purely functional methods they
are a bad style to begin with and should be re-cast as singleton
components. So if I go with the flow I should have a universe of components.
Is this the way to work with iPojo? Or should restrict iPojo to only the
core graph of long-lived objects that form the basis of my program and
manage the construction, and lifecycle of the more volatile object
generations by hand?
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
