This was first published in April 2006. Spring was a novelty. Even more so in a British life assurance company – that’s not your West Coast start-up. So please take it in context. I only re-post this, because it was the most linked to page on my old blog (with both positive and negative comments). I actually tried to recreate the same permalink for it but failed – WordPress won’t let you alter the date. I still think it illustrates DI and its spirit better that the Spring documentation. Also, do not take this as an endorsement of Spring. Spring is now mainstream and some bits of it are as vexatious as J2EE, nowadays I’d probably go for Lift on Scala. That does not invalidate the DI advantages though – testability, clarity, fail-fast mentality, clear contracts, etc. But the Scala version emphasizes my point here – if you have it in the language you don’t need a framework. Scala has it all in the language. Java had a lot of it in the language, but we failed to pay attention. Everything you can write in XML you can write in Java. And it’s type safe. As Dave Thomas put it, Java developers just don’t like writing Java. I sympathise. Oh, and nowadays, I’d go for constructor injection with eager assertions.

Here it comes, as it was, not one letter altered:

Dependency Injection Without Frameworks

Posted on 04/16/2006

I had to do this really small app recently. I wanted to use dependency injection, which I have come to really like now, but it seemed absolutely ridiculous to dump the spring jar and the few megs of dependencies in a project that only consisted of 20-odd classes.

So I decided to roll my own.

Initial thoughts

The main thing is – I want the classes to be unconcerned about their collaborators – they just declare a property of some interface type with getters and setters, and leave somebody else to assemble the whole thing. Thus, in the spirit of DI, you achieve very loose coupling between the objects, which simplifies the design and improves testability.

So, I need to design and write my classes as if for a framework – they would only depend on interfaces and not bother with the implementation. I decided to use setter injection. The only problem was: How do I assemble the whole thing? Looking at Spring again, I decided to have one servlet, which accepts all the requests and delegates their handling to request handlers. On initialisation,the servlet would build the whole application. True to the single responsibility principle, though the servlet would not do this itself – I decided to have an ApplicationAssembler interface and implementation, which would be responsible for the wiring of the components.

It was obvious, that the ApplicationAssembler would be the equivalent of Spring’s XML wiring declarations, except for simplicity, my implementation would just build them using Java. Note that this means there’s a compile-time dependency between ApplicationAssembler and just about everything, but I can live with this just fine, because it’s logically correct, and the individual classes are still very loosely coupled. If I wanted to remove the compile-time dependency, I could always make some XML or Groovy based application assembler.

Here’s a more specific scenario – The servlet has a map of requestHandlers, mapped against their urls. When it loads (init method), it makes an ApplicationAssembler and asks it to populate all the handlers with fully injected collaborators. From then on it’s easy – once a request arrives, the application looks up the fully populated handler and asks it to do the job. Some sort of abstract handler could provide the recipe for the common bits (validate, do business, redirect), and concrete handlers could implement the details if relevant.

At this point I got a bit worried – am I going to do more work than if I had just used Spring? Hm…. we’ll see. Also, it seemed a bit odd, that all I had in my whole application (at the top level) are request handlers. Is really everything in a simple web app a request handler? Or does this approach hide the rest… Hm… As I said, we’ll see.

Design

I sketched a small picture, and it did look quite neat – Mostly the fact that the dependencies were quite minimal. The ApplicationController (that’s how I named the servlet – I know – somewhat unimaginative) depended only on the ApplicationAssembler interface and the abstract RequestHandler. This really is the whole thing:

I have two request handlers in this example, RegisterUserRequestHandler and ShowUserHoldingsRequestHandlers. The two business objects are DataStore – to save the new registration and Mailer – to send the reg confirmation.

Here’s one request handler:

 public class RegisterUserRequestHandler extends BaseRequestHandlerAdaptor {

 // Collaborators
 private Mailer mailer;
 private DataStore dataStore;

 public void setDataStore(DataStore dataStore) {
 this.dataStore = dataStore;
 }

 public void setMailer(Mailer mailer) {
 this.mailer = mailer;
 }

 public void handleRequest(HttpServletRequest request,
 HttpServletResponse response)
 throws IOException, ServletException {

 ....
 dataStore.insertUser(userData);
 mailer.sendConfirmation(userId);
 .....
 }
}

I’ve removed the details, but the main concept is shown well – it declares the mailer and dataStore as interfaces, and setters for them, and that’s it. It’s down to the assembler to set the actual instances. Not only is this simple, but when writing testing this class, it’s easy to just set some mocks instead of the real implementations.

I will write the application assembler to wire it all together as shown on this diagrams for RegisterUserRequestHandler:

and ShowUserHoldingsRequestHandler:

The code that wires it all together is actually quite simple:

 ...
public class SimpleApplicationAssembler implements ApplicationAssembler {

 public Map buildRequestHandlers() {

 // Make the map for the request handlers
 Map requestHandlers = new HashMap();

 // Make a mailer
 SimpleMailer simpleMailer = new SimpleMailer();
 simpleMailer.setSmtpServerUrl("mail.supplesoftware.com");

 // Get a datasource
 DataSource dataSource = null;
 try {
 dataSource = (DataSource) (new InitialContext()).lookup("jdbc/MyDataSource");
 } catch (NamingException e) {
 throw new RuntimeException("Datasource jdbc/MyDataSource not found");
 }

 // Make a data store
 SimpleDataStore simpleDataStore = new SimpleDataStore();
 simpleDataStore.setDataSource(dataSource);

 // Make the request handlers
 RegisterUserRequestHandler registerUserRequestHandler = new RegisterUserRequestHandler();
 registerUserRequestHandler.setDataStore(simpleDataStore);
 registerUserRequestHandler.setErrorView("/regform.jsp");
 registerUserRequestHandler.setSuccessView("/registered.jsp");
 registerUserRequestHandler.setFormView("/regform.jsp");
 registerUserRequestHandler.setMailer(simpleMailer);
 requestHandlers.put("/register.shtml", registerUserRequestHandler);

 ShowUserHoldingsRequestHandler showUserHoldingsRequestHandler = new ShowUserHoldingsRequestHandler();
 showUserHoldingsRequestHandler.setErrorView("/error.jsp");
 showUserHoldingsRequestHandler.setSuccessView("/showfunds.jsp");
 showUserHoldingsRequestHandler.setDataStore(simpleDataStore);
 requestHandlers.put("/showholdings.shtml", showUserHoldingsRequestHandler);

 return requestHandlers;
 }
}

And this is the controller that uses it all:

 ...
/**
 * Dynamic request handler for the DIWF example
 */
public class ApplicationController extends javax.servlet.http.HttpServlet implements javax.servlet.Servlet {

 /**
 * RequestHandlers mapped on url
 */
 Map requestHandlers; 

 /**
 * Uses the ApplicationAssembler defined in the applicationAssembler
 * parameter to populate the requestHandler map
 */
 @Override
 public void init() throws ServletException {
 String applicationAssemblerName = getInitParameter("applicationAssembler");
 ApplicationAssembler applicationAssembler;
 try {
 applicationAssembler =
 (ApplicationAssembler) Class.forName(applicationAssemblerName).newInstance();
 } catch (InstantiationException e) {
 throw new ServletException("Can not make an ApplicationAssembler", e);
 } catch (IllegalAccessException e) {
 throw new ServletException("Can not make an ApplicationAssembler", e);
 } catch (ClassNotFoundException e) {
 throw new ServletException("Can not make an ApplicationAssembler", e);
 }
 assert applicationAssembler != null;
 requestHandlers = applicationAssembler.buildRequestHandlers();
 }

 protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
 service(request, response);
 }   

 protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
 service(request, response);
 }

 /**
 * Looks up the request handler by the request url and delegates to it
 */
 protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
 RequestHandler requestHandler = requestHandlers.get(request.getServletPath());
 if (requestHandler != null) {
 requestHandler.handleRequest(request, response);
 }
 else {
 System.out.println("Request path " + request.getServletPath() + " not mapped");
 response.sendError(404);
 }
 }
}

I noticed that some of the functionality is common between request handlers, so put a base abstract class between the interface and the concrete classes to implement it, like this:

From here you can go as simple or complex as needed. Even in this simplest of all examples, there’s some repetition, which can be easily refactored using the Recipe pattern, eg. The error messages must go in a resource bundle. Some of the request handlers functionality can be abstracted. The validation can be handled by predefined validators. The views can be rendered into XML and transformed using XSL. The definition of the app structure can be XML-ised instead of hard-coded, and so on, until it starts looking like you’re building your own DI framework.

At which point it’s probably wise to switch to an existing one.

Afterthoughts

• I could have used a groovy script to do the wiring (ApplicationAssembler). That would mean I could change some implementations without recompiling. Don’t think that would happen in reality, though.
• There’s a clear distinction here between two main sorts of objects – the main players – request handlers and business logic objects, which are durable and stay there for the life of the app and the bits that you just pass around and dispose of, such as Price, or UserFeedbackForm. The main players are built by the ApplicationAssembler and there are limited number of instances of them. The disposable ones are made on the fly. It’s allright for an object to make one of them, because it is not in any form of compositional or aggregational relationship with it.

Advantages over using a framework

• It’s simple
• The wiring is strongly typed. Compare to XML.
• It’s easy to sell. In some companies, the mention of Spring or Pico will earn you nothing but pain. This allows you to do DI without irritating the elderly. Because the objects are still written the DI way, it’s easy to migrate to a framework later.
• This approach is much simpler than using a framework, but at the same time the whole mechanism is exposed for all to see and understand. The less experienced developers do not face some incomprehensible thing that works as if by magic, and actually have some chance of understanding the actual meaning of DI and IOC.

Disadvantages

• When the app starts getting big, the ApplicationAssembler will get messy. Although in the tiny example I provide here, it’s still quite neat. I suppose it could be split into parts, but a framework has all these considerations sorted already.
• The frameworks offer various strategies for instantiating objects (beans). Here it’s done once, so all your objects will be, for all intents and purposes, Sin*&%#ons. Or Moretons. But you can’t get it to create a new one every time, or maintain a pool, at least not easily. You’d have to give factories to your objects, instead of other objects, which in some ways defies the point.
• The previous point raises questions about concurrency – I’m not going to think about this now, because it’s out of scope, but clearly, state should be avoided and as the app grows you’ll have to think about pooling and stuff.
• Some frameworks, notably Spring actually give you a lot more than just dependency injection, including, transaction management, aop, etc. goodies, you’ll have to go a long way to write these yourself.

I was delighted to find my old blog neatly folded and archived on the marvelous Wayback Machine. I spent hours trying to convert it to WordPress and eventually gave up and just dumped it, blogging some lofty nonsense about detachment. It turns out the Wayback Machine’s got it all – you can just get it there. So, what I am going to do over the next few weeks is re-post some of the posts I had there that seemed to be reasonably popular. Especially that controversial Roll-Your-Own-Dependency-Injection one….

I’ve been thinking about the way Log4J, commons logging, SLF4J, Logback and the related libs blatantly swap classes with the same qualified names. Like, you take this jar out, put the other jar in and you’ve got a different implementation. One example is the StaticLoggerBinder.

The interface is defined in the API and there’s a default implementation there too, but if you want to change it, you make a class with the same qualified name and then swap another jar into your dependencies. A few years ago I would have said that’s way dodgy and shouldn’t be done. But now that I’ve used it for some time, I don’t really see what the big deal is. It’s the ultimate case of convention over configuration.

I have had the odd problem where transitive dependencies filter in and spoil the party, but largely, it’s as pain-free way to change the logging implementation as any. You just change your dependencies! It does get confusing occasionally, but once you get your head round your dependencies (which you should anyway), it seems a lot simpler than having even more configuration items. See this for an intuitive clarification of how it works with Log4J, SLF4J and a bizarre faking of Log4J that re-routes it to SLF4J.

def qsort(list:List[Int]):List[Int] =
{
 list match {
 case x::xs => qsort(xs filter(_<x) ) ::: x :: qsort(xs filter(_>x))
 case Nil => Nil
 }
}

print(qsort(List(4,6,5,0,2,3,1,7,8,9)))

Short and sweet!…

OK, I was unfair on Google. The site had been hacked. I (or my ISP) should have been more careful. Yet, I don’t see what I could have done better, short of hiring a bunch of hackers to verify my ISP’s security procedures. Cause, really, there’s nothing in that web site as such that would allow it to be hacked through code injection or something. Or at least I don’t think there is, but I’m not a hacker. I am very apprehensive now, and totally daunted by the massive consequences. I can apply for a review of the site, but I can’t imagine a bunch of people on the other site dealing with these very efficiently. And how would they be in a position to verify a site’s security, unless they are better hackers than the best out there. So, once you’re hit, you are, through no fault of your own, destroyed. You may question that bit about the no fault, but as much as I can educate myself on hacking techniques, I’ll never be as good as the kids out there, I have a day job to do too. Beyond maintaining good passwords and choosing your ISP carefully, I don’t really see what Joe-the-webmaster can do to stop it. So, anyway, once you’re hit, you’re practically destroyed. That site will probably never show up at the top, the way it used to. Even if they wanted to not be evil and investigate and judge what’s right or wrong, there’s no way they’ll have the capacity, there’s probably millions like me out there. Not to mention the moral responsibility of being the judge of something that will ultimately result in actual wealth redistribution. Grumble, grumble, grumble. Simple life in the woods seems like a tempting proposition.

I’ve been asking this question for some time now. When will Google become the next corporate monstrosity that we all love to hate? Two events from the past 24 hours tell me that time is coming.

First event. I got an email from “adwords-support”, saying that “Your account XXX-XXX-XXXX has been suspended because we’ve determined that there’s a high probability your site may be hosting or distributing malicious software.” The site sells window blinds! Honestly?! Malicious software? All you can get from that site is plain, standards compliant HTML and CSS! What a bunch of plonkers! Oh, sorry, it’s not humans that do that, is it? Or should this be, what a bunch of plonkers wrote that rubbish? Then I go to the site, and I see that it’s been blacklisted. It’s a reported “attack site”. Wait to be attacked by the avalanche of designs of blinds and awnings we have, it will blow your mind and make you fall in love with a penguin.

Anyway, that’s not the problem. Everyone gets it wrong. But this is a paid service. I have come to expect from the real world, that when I pay for service, any glitches in it would not affect my friend’s company in this MASSIVELY detrimental way. MASSIVELY detrimental. No warning! Nothing! Bang – game over! You have been shot.

The other problem is, what do I do now?? There’s a link in the e-mail, saying, if you believe this is wrong, contact us. I won’t be contacting a human though, will I? They don’t do “Customer service” there. That’s for the old fashioned, stupid companies that like to take an evening off once in a while. Plus, the damage has been done. I hope it ends up in the papers (Bulgaria is a small country).

Second event. I was busy at work, so I had forgotten about that. At lunch, I thought I’d have a look at my email on my internet enabled phone. Gmail, to be precise. I use the phone’s browser to read it, because I’m not that hot on the email client. So, only several hours after the adwords rubbish, I get a “We’re sorry, but Google Mail is temporarily unavailable. We’re currently working to fix the problem. Please try logging into your account in a few minutes.” Well, you know what, Google, I have come to rely on your Gmail thingy. Not just for email. For remembering things. It’s my external RAM. Because your search is so good. But is it, now?… It certainly was. But so was its reliability. I hear it blew up recently too, though I didn’t get caught in that. Now, I’m thinking, hang on…. I will be a very, very, very sad boy if my email data goes down the drain. Like, properly sad. Like The Little Prince for his rose, that caliber of sadness….. VERY sad! Can I trust this thingy out there somewhere in the cloud???

I tried to illustrate how you convert between the two. This is what came out. Probably not entirely correct, but it works. It can be mixed and matched for legacy apps.