Dependency Injection Frameworks: What Java does to be Interpreted
My current task is customizing JIRA, an enterprise issue tracking system. JIRA is a fine application that makes bug tracking easy and fun. The JIRA source code is 22MB of compressed Java code that makes customization (outside of plugin or JSP modifications) neither easy nor fun. After a week, I managed to get the source into Eclipse in such a way that Eclipse's auto-build feature inserts new class files into the currently running tomcat. Tomcat automatically refreshes modified class files, so after saving some changes in Eclipse, you can go straight to your web browser and test them.
Now that the introduction is out of the way, lets get on to PicoContainer. In a tiny nutshell, Pico is a framework for stuffing methods into Plain Old Java Objects. You create your native objects (Plain Old Java Objects) with constructors that take in any object links - ie an MVC controler takes in view and model objects. Then, you set up a container that defines the object relationships - which objects are related, and their setup parameters. Now when you instantiate the container, you can ask it for one of the POJOs that will now have its relationships fufilled.
The end goal of the system is to fufill abstract object dependencies with objects that implement the abstractions. In Martin Fowler's Constructor Injection example (he covers other related injection methods), a MovieLister class uses a MovieFinder class to return all the movies directed by Sergio Leone. The MovieFinder class is an abstraction implemented by ColonMovieFinder, which takes in a filename of a colon delimited database. They are tied together in a container by a setup function.
What amazes me is that there is a framework for doing this - many frameworks, in fact. PicoContainer, Spring, and Apache Avalon (closed, but a common ancestor of a handful of other projects) all do basically this, either by constructors, setters, or interfaces. If I were working in a language that wasn't statically typed, I could use an advanced factory design pattern. Clearly Java is a statically typed environment - hence the need for these frameworks. But every time someone codes a dynamic extension to a static system, it makes me wonder - why are we using a static system in the first place? To contrast, Objective-C can treat any object as a generic object type ("id"), but can also be statically allocated. Doesn't that sound a lot easier than writing frameworks that ram square pegs into round holes? What were the Java people thinking?
References:
http://www.martinfowler.com/articles/injection.html
http://timothyfisher.javadevelopersjournal.com/read/1232766.htm
Now that the introduction is out of the way, lets get on to PicoContainer. In a tiny nutshell, Pico is a framework for stuffing methods into Plain Old Java Objects. You create your native objects (Plain Old Java Objects) with constructors that take in any object links - ie an MVC controler takes in view and model objects. Then, you set up a container that defines the object relationships - which objects are related, and their setup parameters. Now when you instantiate the container, you can ask it for one of the POJOs that will now have its relationships fufilled.
The end goal of the system is to fufill abstract object dependencies with objects that implement the abstractions. In Martin Fowler's Constructor Injection example (he covers other related injection methods), a MovieLister class uses a MovieFinder class to return all the movies directed by Sergio Leone. The MovieFinder class is an abstraction implemented by ColonMovieFinder, which takes in a filename of a colon delimited database. They are tied together in a container by a setup function.
What amazes me is that there is a framework for doing this - many frameworks, in fact. PicoContainer, Spring, and Apache Avalon (closed, but a common ancestor of a handful of other projects) all do basically this, either by constructors, setters, or interfaces. If I were working in a language that wasn't statically typed, I could use an advanced factory design pattern. Clearly Java is a statically typed environment - hence the need for these frameworks. But every time someone codes a dynamic extension to a static system, it makes me wonder - why are we using a static system in the first place? To contrast, Objective-C can treat any object as a generic object type ("id"), but can also be statically allocated. Doesn't that sound a lot easier than writing frameworks that ram square pegs into round holes? What were the Java people thinking?
References:
http://www.martinfowler.com/articles/injection.html
http://timothyfisher.javadevelopersjournal.com/read/1232766.htm
0 Comments:
Post a Comment
<$I18N$LinksToThisPost>:
Create a Link
<< Home