Dependency Injection Part II: Arguments For Dependency Injection

Before we dig in too deeply to Dependency Injection (DI), we need to ask an important question: Should we even be doing this in the first place?

There are arguments for and against using DI and DI containers, and considerations of when to use it versus when not to use it. This post will deal with the advertised advantages of DI. In the spirit of objectivity, some disadvantages and consideration of them will be in a follow-up post.

There are four main advantages I will be dealing with here:

1. Link using class to an interface rather than an implementation
2. Facilitate testable code
3. Manage scoping rules for your object graph
4. Reduce boilerplate code

Instantiating members inside a parent class permanently links the parent class to an implementation instead of an interface. Now one might counter that when declaring a member, assigning an implementation to an interface keeps the parent class from being linked to the member’s implementation. However, the parent class itself still depends knowing that the concrete class exists to assign the member. If this assignment is made in 100 different classes and you want to change the signature of the implementation’s constructor, you will quickly find that parent class really is tied to the implementation instead of the interface.

Injecting dependencies facilitates testable code because small portions of your application are easy to instantiate. You can instantiate the subject under test directly, specify mock objects or stubs for its dependencies (things that are not easy to instantiate, or things that have side effects like network calls or database calls) and unit test to your heart’s content! When the dependencies are hard-wired inside the subject under test, testing like this becomes impossible and you are reduced to integration tests, or worse, manual tests. The advantages of unit testing are left for another blog entry...

The DI Container can easily manage complex scoping rules. If you have portions of your application’s object hierarchy that need to be instantiated only for certain scopes (say, for a single request, or one per thread - request scope and thread scope) the DI container will manage the instantiations at the right time rather than your code having to manage it. Guice provides session scope, request scope and custom scopes, and Spring 3.x provides a thread scope in addition to its other scopes.

DI Containers reduce the boilerplate of setting up dependencies. You can provide a dependency to potentially many client classes rather than each client class instantiating it. This way you do not have to repeatedly write the code to do additional work that a dependency needs before it can be used (like calling setters, calling initialize methods, etc). You can also avoid writing the code to wire other dependencies that the original dependency might have. The container will provide the entire hierarchy of dependencies with the appropriate scope.

I think these four points (Link client class to an interface rather than an interface, Facilitate testable code, Manage scoping rules for your object graph, Reduce boilerplate code) are good arguments for using a DI container. In the next post we will look at arguments against using a DI container.

Dependency Injection Part I: A Basic Introduction

There has been much debate around Dependency Injection (DI). In this series I will explore dependency injection: what it is, the arguments for and against it, when to use (or not use) it, and some code samples.

First of all: What is Dependency Injection? You can read the Wikipedia article on it as well as I can, but to put it in plain english: Instead of a class instantiating its own member instances (dependencies), the dependencies are given to it. This is easiest to see with a little sample code.

// without DI
public class Parent {
  Something s = new ConcreteSomething();
}

// with DI
public class Parent {
  private Something s

  // constructor injection
  public Parent(Something t) {
     s = t;
  }

  // setter injection
  public void setSomething(Something t) {
     s = t;
  }
}

Note the two different ways of getting Something into Parent: via a constructor or setter. There are other ways to accomplish this (Martin Fowler's DI Post includes Interface Injection) but these are the techniques that I have seen used the most often. I favor constructor injection in particular because I like having the object constructed in a usable state, and think it’s good practice to make dependencies explicit. That way if the constructor argument list gets too long, it’s a good clue that your class might be trying to do too much!

Next, there is a difference between DI and an DI Container, and many people confuse the two. DI is just the design pattern, the idea of arranging classes in such a way that a dependency is given to a using class instead of the using class instantiating it. A DI container, on the other hand, is a framework that facilitates DI to the point where you can construct an entire application using dependency injection. When people argue for or against DI, they sometimes are actually arguing for or against the idea of using a DI container vs the design pattern of DI itself (or vice versa). For purposes of this blog, I will use DI to mean using a DI container to structure an entire application. Arguments revolving around this should be a superset of arguments revolving around DI as a design pattern.

Finally, some things to note about how to use DI in Java: The javax.inject package (aka, CDI or “Context and Dependency Injection) is a standard in Java EE 6, so it’s not hard to get started with using this in your own code. The related JSR’s JSR-330 and JSR-299 (which are different from each other) have various implementations available, such as Dependency Shot, Spring, and Pico. Guice 3.0 is the Reference Implementation for JSR-330. Later we will be looking at working samples using Spring and Guice.

In the next post, we’ll examine the arguments revolving around DI, and get a feel for when it is appropriate.

Running Tomcat Without Root Privileges

There are a number of security considerations for running Tomcat (indeed, for any web server). The documentation at OWASP and the Tomcat security docs do a pretty good job of outlining the major considerations.

One frequently mentioned best practice is that your web server should not be run as root and should instead be run as a non-privileged user. However, programs run with non-root privileges can’t bind to lower standard ports (below 1024), and we would generally like to serve our site on the standard ports (like 80 and 443).

Since tomcat should be run without elevated privileges, and access to port 80 requires elevated privileges, we need to resolve this issue. There's no single best way per se on how to do this, you need to understand the options and make the most suitable choice for your situation.

Here are some options arranged (in my opinion) by ease of use, with caveats as sub-points. Note that this presumes Tomcat on Linux.

• Use authbind to enable a non root user to bind to ports below 1024. This solves the problem very directly and it is available on Ubuntu with sudo apt-get install authbind.
• Caveat: Available only on debian linuxes
• Caveat: Doesn’t work with ipv6
• Use firewall software on the host to configure port forwarding.
• Run Tomcat as root, but in a chroot jail
• Use setcap to set capabilities
• Caveat: Doesn’t work if starting from a script (starting with #!)
• Caveat: JDK 1.6 did not work when using capabilities, but it works with JDK 1.7
• Use Apache running on port 80 and AJP to send requests to Tomcat. Using Apache would probably be a better choice if you have other reasons for choosing it like serving static content or load balancing.
• Caveat: need to set up Apache if you haven’t already
• Caveat: with virtual hosts that share an ip address you need to set up SNI (which might not have a full browser support)
• Port forwarding with iptables
• Caveat: NAT is not supported in ip6tables (IPv6 version of iptables)

Propagating Best Practices in Code

Recently during a code review, I mentioned to my colleague that a certain method could be eliminated by just implementing the appropriate marker interface so our framework would run the equivalent code at the right time. Not having encountered that technique, he appreciated the comment and said “Is there an easier way to learn about what's available rather than through code reviews?” Good question.

I’ve noticed that within the context of a particular codebase, there are accepted best practices. In the previous example, the best practice was knowing what your codebase or framework already provided vs what you needed to write, but there are other examples such as which classes should begin transactions, how to get a database session, and using programmatic transactions vs declarative transactions.

As a software product is developed, the team develops a standard for how to accomplish particular things in code. But you know what they say: the nice thing about standards is that there are so many to choose from.

On a large project (say, 1+ million LOC) I’ve found that often one practice in code is improved or modified resulting in two ways of doing something (since the previous technique is not removed). This can happen again and again, resulting in multiple practices in the code. When someone who’s not familiar with that practice looks for examples, it becomes impossible to tell which is the “best” or “accepted” way to do something.

At first I thought of this as a refactoring problem. If only we had enough code reviews, such cases would be caught and older duplicate techniques would eventually be refactored away, right? But I think the issue is more general than that, that this is actually a case of methodological organizational knowledge being lost. People change jobs, people unknowingly duplicate effort, and with a large codebase it becomes difficult to propagate every practice or know what every other person is doing.

This raises some questions: How do we build up best practices or established ways of doing things in the code? If we want to update a practice, should we fix the old practice incrementally as we see it, or migrate it all at once?

For the first question: knowledge management is a well-known process. In the context of software development, I imagine that spreading knowledge would ideally include a variety of communication techniques such as code reviews, learning sessions, mentoring, and pair programming. Last on the list (but still on the list) would be documentation, since developers generally look to code for examples rather than static documentation.

For the second question, note that developers generally reference the code rather than static documentation. If we try to slowly migrate one practice to another, there is a danger of developers propagating the old practice. That is an argument for refactoring a practice all at once, but depending on the scope of that change it could carry significant cost and risk (that the old practice covered a case not covered by the new practice). So there is a balance to be had between incremental updates to a practice and migrating a practice all at once. To make the decision on that balance, I would say that if the refactoring is small enough to be accomplished in, say, a single sprint, then it’s worth it to refactor. Beyond that, the cost and risk may be too high. Such a change should be accomplished incrementally by changing the old practice as you come across it, and by noting this as a larger task in your backlog.

And hey, maybe sharing knowledge would best be done with tweets! "Hey I just started using ActiveButton instead of HoverableButton, you should use it too". Wait, that’s too many characters, it should be more lolcatz. "yo dawg i jus strted usin ActiveButton FTW! u shld use it 2! OMGLOL”