Yes, this is an open-ended question and there is likely no single answer.
The mission of iPOJO is to make creating dynamic applications simpler.
Precisely how you use it to accomplish this depends on your use case.
The main debate, it seems, is when to use an object and when to use a
component. Since iPOJO components handle dynamism (among other things),
you may choose to use it for those pieces of your application that
require dynamism, for example, but it is difficult to say when to decide
between object vs component. Granularity is another metric.
iPOJO is a full-blown, hierarchical component model built on top of an
object-oriented language. In the end, it leaves these decisions up to you.
-> richard
Todor Boev wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
