Developing an IOC-Container for Dependency Injection Part I
Part I | Part II | Part III
Before we start: If you don't know whats behind IOC and Dependeny Injection, then read Martin Fowlers Article or jump to Wikipedia.
A couple of months ago i played with lots of IOC-Containers out there. Two of them interested me in the long run: Spring and Picocontainer. Spring because of its clean concept (yeah, i know, sometimes xml sucks, but if you make it intuitive...) and Picocontainer because of its "lightweight" concept. But both of them have there drawbacks.
Picocontainer has great code, as you can expect it from the codehaus (the guys with groovy), but nearly zero documentation. Spring, on the other side, is far to big for small projects that like to have an IOC-Container. You can separate the Container in Spring from the O/R-Mapping and MVC Stuff, but its still big. And where would be the fun without writing an own Container?
So what do we want? I'd say, we like to have a really, really lightweight container implementation. It should be extendable and testable. For configuration (for the wiring-together) we use simple xml. Really simple.
To "see" what we want, we write a tiny Test:
First, we want to instantiate an IOC-Container with a given config-File. The IOC-Container should have an interface and an implementation class, so we can change the implementation later on if we want to.
Then we want to create an instance of a class via the container.
Ok, lets test wether customer holds the correct object
We don't want to tell the Container which implementation class (say, CustomerImpl) is behind the interface (Customer) via code, cause then you have to change the code every time you want to change your implementation. The implementation should be wired over a small, easy to mantain config-file, where you can change the implementation from the outside.
But that should be enough for the first part, the next will be up soon ;-)
Before we start: If you don't know whats behind IOC and Dependeny Injection, then read Martin Fowlers Article or jump to Wikipedia.
A couple of months ago i played with lots of IOC-Containers out there. Two of them interested me in the long run: Spring and Picocontainer. Spring because of its clean concept (yeah, i know, sometimes xml sucks, but if you make it intuitive...) and Picocontainer because of its "lightweight" concept. But both of them have there drawbacks.
Picocontainer has great code, as you can expect it from the codehaus (the guys with groovy), but nearly zero documentation. Spring, on the other side, is far to big for small projects that like to have an IOC-Container. You can separate the Container in Spring from the O/R-Mapping and MVC Stuff, but its still big. And where would be the fun without writing an own Container?
So what do we want? I'd say, we like to have a really, really lightweight container implementation. It should be extendable and testable. For configuration (for the wiring-together) we use simple xml. Really simple.
To "see" what we want, we write a tiny Test:
First, we want to instantiate an IOC-Container with a given config-File. The IOC-Container should have an interface and an implementation class, so we can change the implementation later on if we want to.
IOCContainer ioc = new IOCContainerStandardImpl("example-config.xml");
Then we want to create an instance of a class via the container.
Customer customer = (Customer)ioc.getInstance("Customer");
Ok, lets test wether customer holds the correct object
customer.logik()
We don't want to tell the Container which implementation class (say, CustomerImpl) is behind the interface (Customer) via code, cause then you have to change the code every time you want to change your implementation. The implementation should be wired over a small, easy to mantain config-file, where you can change the implementation from the outside.
But that should be enough for the first part, the next will be up soon ;-)
add to del.icio.us
submit to reddit
1 Comments:
At 6:38 AM,
Anonymous said…
Excellent, love it! general electric circuit breaker 15a 240v ground fault Withdrawal klonopin Universal radar detector power cord Land rover discovery gs windscreen wiper Copenhagen furniture arizona Printer scanner copier diagrams Lipitor plavix
Post a Comment
Links to this post:
Create a Link
<< Home