Skip to main content

Can XML capture the Dependency Injection pattern ?

Posted by unoinpiu on December 6, 2006 at 2:15 PM PST




Can XML capture the Dependency Injection pattern ?

Xml is a great language for describing structured data. But it works
less well when people use it to describe control flow. Even worse when people
treat it as a complete programming language (e.g.: ANT, XSLT)

So my question is, does XML fit naturally when used to capture the dependency
injection pattern ?

Following the 'dependency injection'
pattern (setter method) every time we design a
class A which needs (depends on) the services of an object B we add a 'setB'
method.
If our class A needs a collection of objects B (typically an ordered list or
a set) we add a 'setBs' method.This pattern is then repeatedly applied to
any injected class (which itself is dependant on the services of one or more
objects) until we reach objects with at most setter methods for strings,
collections or primitive types.

Spring, the most popular IOC container, uses XML to do it in this way:

<beans>
   <bean id="a" class="com.foo.A">
      <property name="b" value="b" />
      <property name="c" value="c" />
   </bean>
   <bean id="b" class="com.foo.B">
      <property name="e" value="d" />
      <property name="f" value="f" />
   </bean>
   <bean id="c" class="com.foo.C">
      <property name="e" value="d" />
      <property name="f" value="f" />
   </bean>
   ...
   ...
<beans>

The example above shows a class A which needs classes B
and C. In turn B and C need respectively classes E and F, and classes D and F.
Note that good design should ensure class A to be totally agnostic of D,E and F. A needs B and C services so to function but does
not care how those are provided (i.e. by using D,E and F)

This procedure of creating and assembling beans via the spring configuration
is easily depicted by a picture.

graph.gif

 

This picture is a graph. More precisely it is a directed
acyclic graph (http://en.wikipedia.org/wiki/Directed_acyclic_graph
)

Each node is a class and each unidirectional arrow
represents a dependency. The absence of cycles in the graph ensures there are no
circular dependencies amongst the components.  So while developers see the
Spring-XML-Configuration as the place where their components are
created,assembled and managed (and in doing so they are correct) come from
another angle and you can see the Spring-XML-configuration as nothing more than a
graph.

In this sense, I dispute those people who criticize it claiming it is too
complicated and unwieldy.



Related Topics >>