My god, your mind must have been completely warped by Spring! :-) There have
been eons before Spring when you still had to wire your app with this old
fashioned out of style keyword call 'new'. :-)
Kidding aside, I actually do not recognize the problem. In general I just
create the private objects with 'new' and lazily. I.e. I do not go out of my
way to make them separate. One thing I learned about dependencies is that it is
all or nothing. You should not look at each dependency an-sich but look what it
means for the people that depend on you. Each class in your bundle is fair game
since you're already coupled. There is no use trying to protect yourself from
changes because you already in the same boat. So inside your bundle you use the
normal Java access rules for getting some local privacy. And other than that,
any external reference is a service.
In my experience, I find I have quite a large number of components that have a
set of private adjoint classes. If I have a public API, I do not mind talking
to my siblings in the same bundle through the service registry since quite
often this turns out to be useful, if only for debugging. Realize that a
service is really cheap, there are installations with ten thousands of services.
The trick here is cohesion. Inside a service I normally have small to medium
sized program, using between a few to a 100 classes. I feel I've succeeded when
that complexity looks really simple through the service API, with only a few
adjoint classes. This is what modularity s all about, putting a lot of
complexity inside and only showing an API to allow collaboration.
Don't hesitate to contact me if you have an actual use case and want to discuss
it.
Kind regards,
Peter Kriens
On 18 feb. 2014, at 10:16, Christian Schneider <ch...@die-schneider.net> wrote:
> I think you are right that the number of classes to wire inside a bundle is
> much lower than the number of classes in a spring application. So there is
> less need for a DI solution.
>
> The question is though how to do the wiring with java in practice. Do you
> have some larger examples for this? What I am especially concerned with is
> the handling of instance creation and DI setup when classes are partly
> created by hand and partly by DS.
>
> Christian
>
> On 17.02.2014 20:19, Peter Kriens wrote:
>> I do not think this is the idea of DS. Spring was invented to handle the
>> byzantine complexity of an average Java application at the time. Trying to
>> wire it all together had become a nightmare because there are ordering
>> issues in initialization. The complexity of apps exploded because the
>> complexity increases exponentially with the number of dependencies. So
>> Spring provided a fantastic solution to this problem. However, it also
>> introduced XML programming which is fundamentally bad (it is probably the
>> worst language to code in ever devised by mankind). In the early naughties
>> this was ok since Spring solved a real problem.
>>
>> I think a natural DS application uses normal plain run of the mill Java code
>> to wire the private beans. Since these are normally a small number, there
>> are in general no ordering issues, specifically since the scope is private,
>> no unexpected surprises. Also the wiring is much better done in Java because
>> it gives you 100% type safety, error checking in the compiler, and lots of
>> context help in your IDE. Since the problem is so much smaller and all your
>> types are in private scope and you really want automatic wiring then there
>> are lots of solutions: Picocontainer, Guice, etc.
>>
>> DS works so well because it is highly cohesive. It basically does one thing,
>> wiring services, and it does that extremely well. I would really think it
>> would be shame if we try to turn it into another bloated monster ... :-)
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
