魅力四射的“小玩意”——PicoContainer (轉)

魅力四射的“小玩意”——PicoContainer (轉)[@more@]

Jon Tirsen在他的log裡說，他看到一個叫PicoContainer的有趣專案，並立刻投身其中。這個自稱“IoC（Inversion of Control）type 3”的微容器有什麼吸引人的魅力？

PicoContainer / NanoContainer I've recently joined two new projects:

The founders of the project are Paul (Alt, Enterprise Broker) and Aslak (XDoclet, MiddleGen). Actually they pair-programmed most of it at Paul's place and a lot of beer was involved. The end result: a neat, simplistic and wonderfully TDDed piece of work. Joe (SiteMesh, QDox), my unit-testing guru, is also in on it.

It's basically an Inversion-of-Control-container//micro-kernel. Pico will be the simplistic micro-kernel and Nano will be a bunch of containers serving different purposes (most built on top of Pico).

I'm not an IoC-expert by any means, and, well, I didn't know much about it before chatting with Paul and Aslak. The cool (and quite controversial) thing is that Pico (at least by default) implements style 3 IoC, which means constructors are used to define dependencies. Smart!

I will implement some Nanning support in Nano so that ects can define dependencies on services and the container will resolve them proy, the aspects will also be able to aspectify the components transparently. The details are far from finalized, just a bunch of semi-digested as. I'll give you a couple of use-cases though. An aspect implementing transparent persistence with could retrieve it's Prevayler-instance just by declaring it in its constructor:

public class PrevaylerAspect { public PrevaylerAspect(Prevayler prevayler) { /* ... */ } /* ... */ }

A declarative transaction aspect could declare it's dependency on a TransactionManager by:

public class TransactionAspect { public TransactionAspect(TransactionManager transactionManager) { /* ... */ } /* ... */ }

Put these aspects along with their services in a container, Pico does it's work and all components are properly assembled:

PicoContainer pico = new HierarchicalPicoContainer.Default(); pico.registerComponent(RemoteTransactionManagerImpl.class); pico.registerComponent(PicoPrevayler.class); pico.registerComponent(PrevaylerAspect.class); pico.registerComponent(TransactionAspect.class); pico.start();

Neat and simple. No , no runtime attributes, no fuss.

Another great thing is that it's brilliant to mock-test the things. Say you want to mock-test your TransactionAspect to see that it actually demarcates it's transactions properly:

MockTransactionManager mockTransactionManager = new MockTransactionManager(); // ...set up expectations and so forth... TransactionAspect transactionAspect = new TransactionAspect(mockTransactionManager); AspectSystem aspectSystem = new AspectSystem(); aspectSystem.addAspect(transactionAspect); TestObject testObject = (TestObject) aspectSystem.newInstance(TestObject.class); // ...run your tests on your testObject... mockTransactionManager.verify();

Check it, you'll like it! (-06-20 11:25:47.0)

無獨有偶，我的另一位偶像Rickard Oberg也看上了這個專案。他在自己的weblog上介紹了PicoContainer和IOC，還為這個跟人吵起來了。這個小玩意的價值在哪裡？我很信賴Oberg的見地。

Why IoC? From the comments on the PicoContainer entry it seems like people are not quite getting what's so great about IoC (Inversion of Control). "If all it does is lookup, what's the point?".

To me this question is like saying "What's the point with aircraft? The only thing they do is fly", but I'll give you an example that might highlight why IoC is nice to have. Let's say you have a component A that uses a component B to do something. In the first iteration of your application both are just POJO's registered in a PicoContainer. Here's the code for A:

public class A { B comp; public A(B comp) { this.comp = comp; } public String helloWorld() { return "Hello "+comp.world(); } }

PicoContainer will, using IoC, get a reference to B and hand it to A so that it can run. Let's say that we now change so that B is a service that is located using Jini divery. The code for A now looks like this:

public class A { B comp; public A(B comp) { this.comp = comp; } public String helloWorld() { return "Hello "+comp.world(); } }

Looks familiar, doesn't it? But, Jini isn't all that popular these days so we changed B into a and put some failover on top of it using grid computing. With all of this new high-tech stuff running the show, the code for A now looks like this:

public class A { B comp; public A(B comp) { this.comp = comp; } public String helloWorld() { return "Hello "+comp.world(); } }

See my point? The code for the A component has not changed one bit even though the lookup and discovery infrastructure has changed radically over the lifetime of our application. This is what IoC brings to the table, and which is what PicoContainer has implemented in a such an elegant way that you don't have to read a lengthy architectural document to grasp how it works.

That's the point.

(NOTE: For those who want to be picky about the above example and say that changing a service to a remote one and evolve it to use transactions and whatnot which would change the code for A, all I can say is: 1) you're missing the point 2) use AOP) (2003-06-29 09:36:39.0)