Spring (and other DI frameworks) can inject dependencies into private fields. It looks like people like to use this because it combines some compelling properties:

• Very little boilerplate code. All you need is a simple annotation on the field.
• Since the field is private nobody outside the class can change it.

But now when you want to test your class and want to assign e.g. a mock to the field you have to either setup a Spring context in your tests or use reflection in order to access the field (just as Spring does).

Now something is really starting to smell bad here. One of the purposes of Dependency Injection is to decouple code, which in turn should make the code easier to test. Now that didn’t work out to well.

So how can we clean up this mess? We can write a setter for the field. That solves the testing problem. It adds a little boiler plate code, but hey we are talking Java here, so you should be used to that. But now we have a setter which anybody can call at any time. At the very best that doesn’t make any sense at all in the production environment. In the worst case somebody actually uses it and creates some ugly bug.

So what do you do when you don’t want anybody to change a field? Correct you make it final. Great, now you have a compile time error in the setter.You can only set a final field in a constructor. This leads naturally to the solution of all our problems (and possibly to world peace): Make your dependency a constructor argument!

This is the only place where dependencies really belong. If you try to stick to that rule I’d expect you’ll encounter the following two problems.

1. You’ll find classes with lots and lots of constructor arguments. I’ll bet that class does a lot of different things and really needs to get broken down into smaller pieces.
2. You’ll find cases where a class A needs an instance of B and B needs an instance of  A. This is a typical case of a circular dependency and is obviously bad. In my experience the solution is either to make B a part of A when the two are so strongly dependent that they really should be one class. More often though there is at least one more class C hiding in there so that B doesn’t need A but only C.

So really the problems you’ll find when doing constructor based dependency injection are problems that are present in your current code already. So don’t shoot the messenger, but fix the problems in your code and go for constructor arguments for dependency injection.

This metaphor works well to communicate the need for refactorings if at least one person realized the need for it.

But in various cases nobody in the project realizes that there is a problem until the team face a huge debt which seems impossible to pay back.

I see two possible reasons:

Being blind: There is a different level of cleanliness people consider clean enough. In interviews I have repeatedly talked to people considering a 20 line method a good thing and don’t have problem with nested control structures 5 levels deep. Those developers wouldn’t notice anything smelly when looking at code which I would consider CMD (Code of Mass Destruction). This problem is most of the time fairly easy to fix by teaching and coaching. But there is a more insidious possible reason:

Being a frog in boiling water: There is a theory that a frog which sits in cold water doesn’t jump out of the water if you heat it realy slow until it dies. Wikipedia isn’t decisive if this is actually true, but I definetly see this effect in software development. It looks like this: At some point you find something in your code that looks like it has an easy abstraction. So you build a little class encapsulating that behaviour and use that class instead. It works great, so that little class gets used a lot. Sometime later the class gets a new feature to handle a variation of the original case. And it goes on like this, until one day what was a simple abstraction has turned in a complex library, possibly even a framework. And now that framework is a problem on its own. Its getting hard to understand how to use it.

And you realize you are a poor little frog sitting in boiling water with no idea how he got there. Hint: It’s a good idea to jump even when it is a little late.

Why does this happen? Just as the frog has a problem sensing the small change in temperatur and realizing he is getting into trouble the developer doesn’t see he is hurting the quality of the code base until it is to late.

Again: Why? Let’s make the example a little more specific. You have blocks of 10 lines of simple repetitive code in N places in your code base. You replace it with a call to a simple class of 40 lines of code. So you save (9*N – 40) lines. On the call site your code gets significantly simpler, of course the class is a little more complex but thats ok. Now while implementing a new feature you are about to create another of those 10 line blocks. Obviously you want to use the helper class. But it’s not fit for the job. You need to add a feature to it. That’s ok. You also have to add something to the public API to turn that feature on or of. Maybe it’s a new constructor, a new method or an additional parameter. That’s not ok. Until you changed the API of your class the changes where local to the helper class and its usage at the new site. But when you changed the API, you added complexity to all the call sites of your class. Whenever you now call that helper you have to think a little more about the correct API to use. This unfortunatly isn’t easy to see. So it can easily happen that your API turns slowly so complex that using it is more painfull then just writing the 10 lines it replaces down.

Apart from being utopian the idea of a single quality measurement might actually hide a dangerous attitude: The attitude that clean code has a value on its own! It doesn’t. Even if you don’t like it: The only things that count in the end are measured in dollars, euro and yen.

In this sense clean code is only a crutch. We do it in order to get somewhere where we can’t go without, or at least not as easy.

We are convinced that improving our code, and writing tests

• makes us faster (and therefore our work cheaper) in the not to long run.
• makes the code easier to maintain.
• makes it easier to add features tomorrow.

And as long as I’m convinced it is helping with these aims I’ll continue to do so, and so should you.

But if your are doing it just because it is in some fuzzy sense the ‘right thing to do’ you are doing it for the wrong reason and you might be doing the wrong thing.

So the natural thing to do is to factor out common code into separate methods, classes and finally libraries. Great. But there is a downside to it.

Often code doesn’t get copied around as it is. It gets tweaked and adapted to the new environment in order to do its work. If you have factored out the code into some kind of library this library needs to support all the various ways of tweaking via some kind of API. This of course makes the library more complex.

As long as we consider only a single project where everybody has access to all the code and at least some basic understanding of it this is all fine. And I vote for extracting almost all duplicated code in a project. The story changes a lot though when we are talking about code reuse between projects. Now you have to maintain a library that is used by multiple independent groups of people. People that you might not even know. This implies that you have to combine way more requirements in your library. At the same time it gets harder to change, because every breaking change will cause work for projects no matter if they needed that new feature that caused the change. Also for a given project which might have a problem with the library it gets way slower to fix the problem, since they  can’t do it on their own. They have to consult with the owner of the library which has to weigh the issue at hand against the complexity of the library and the requirements of other projects.

These additional costs only pay of if the reduction of work by reusing the library is pretty big. Or if it is a real stable library without many requests for change.

In typical enterprise settings very often these criteria aren’t met. So my recommendation is: Just use cut and paste, i.e. make the actual source code available to projects. These projects can use the code as it is or modify to their tasting. If they have problems with their code, they have everything they need to fix it. But they also have to do it on their own. No mommy to run to.

If you are really lucky you can get some kind of feedback from the users of the code. This would allow to improve it so the next project grabbing it gets an improved version. And if finally thing solidify you might turn it into a library which gets distributed in binary form and maintained by a central team.

This might result in code like the one below. It is actually Scala code, but that shouldn’t matter much. The only piece that is a little special are the calls to Binder, which is a little Swing Binding Framework which I introduced a couple of weeks ago.

What is so bad about this piece of crap … ähm … code?

The method is long. 38 lines is about 10 times longer than healthy for a method.

There is tons of code duplication.

The method does lots of different things: creating components, adding them to a panel, configuring the layout.

There is a strong dependency on the order of commands. We can’t just move stuff up or down in the method and still hope the result will be something reasonable, even if we stick to rearrangements allowed by the compiler.

All this together makes the method extremely hard to understand. How long does it take to understand what kind of GUI results? Don’t bother to much, I help. It looks like this:

and if you resize it, it looks like this

Arguably the result looks just as ugly as the code, but once the code is clean we might be able to improve on the visual design as well.

If you don’t see it in the code, you might see it in the images: There are three different ways JComponents are handled by the method: JLabels are in the left column and don’t resize. The JTextFields are in the right column and do resize and the JButton doesn’t resize and is in the buttom right. In the code this is completely hidden in the manipulation of the GridBagConstraint. So lets make it explicit in the code:

I introduced three methods. One for adding a JLabel, one for adding a JComponent and one for adding JButtons. These handle the arrangement of components on a JPanel. The total length of the code increased because we create the GridBagConstraints insided the methods and have to set all properties and don’t rely anymore on the previous step to leave the constraint in a specific state.

If we now look at the createPersonPanel we’ll get a strong fealing of repetition in various places:

• each call to add* methods takes the same JPanel as an argument. We can improve on this by creating a Builder wich crates the panel, contains the add* methods and can return the fully configured panel at the end.
• for each property we create a JLabel, a JTextField, bind the property to the later and add both to the JPanel. We can fix this by encapsulating it in a seperate method.

The result might look like this:

The PanelBuilder has now two simple public add methods. In order to imitate the method signitures in Java we would have to create a couple of helper classes and interfaces. It would make the code less compact but this shouldn’t be a serious problem. Creation of the various components is just as the binding extracted in two create Methods. The createPersonPanel has now only 5 lines of code. Adding another property to the form should be trivial. Changing the extremely simplistic layout should be trivial and is at least limited to a single small class. I think this is pretty much OK for a first step toward clean swing code. So I leave it like it is right now. Although I do have further plans for this.

I hope most of you agree that the code is much easier to understand and maintain in the form it is right now. But is it really worth the effort? Some might say no. If the whole application would consist of only this little panel. I would agree. But a Swing application typically does not have a single panel with two textfields and a button. But tens or even hundreds of panels. Many consisting of large collections of components. If you have to maintain such a monster, would you prefer createPersonPanel methods like the last one, or would you prefer the first version? What if the customer if finally fed up with your crappy layout and insists on proper spacing between the labels and the JTextFields or other components?

All this is pretty nice when you start a new Swing application. But what if you have an existing Swing application? One with convoluted code just as the Swing Tutorial taught you? Well … start changing it now. Don’t sit down for two months and rewrite all your code, but find pieces of code duplication and extract them. It will be a long way, but you wont reach the end if you don’t start walking.

But what if you are not using Swing, but writing a web application? Well it really shouldn’t matter much. Your PanelBuilder might be written in JavaScript, or create HTML, but the principle is the same: Seperate creation of components, layout of components and binding of components to properties and actions.

Fireworks

In a couple of days I’ll start working on a new project. Actually it is an project that I worked one or two years ago. I think I did decent job last time. But there is always lots of room for improvement. So today I want to list a couple of things I want to do bettern than the last time.

More Tests – When working on that project I was the only person with real experience in automated testing. I am proud that we had a test suite and that this test suite still exists and put to good use and actually grew during the last months. Yet I consider the coverage of the tests not sufficient by far. So for every code I write, I will add an extensive set of test. I’ll also add tests for existing code, when refactoring.

Earlier Tests – One reason we didn’t produce as many tests as I would wish today is that we didn’t do TDD. It probably was a correct decission the last time, since it would have been just to much. But this time I will practice TDD as good as I can.

Cleaner Code – One of the first tests I wrote back then was a test to ensure that we don’t have circular dependencies. We succeeded in this, but still parts of the system a pretty tangled. We gonna improve that. Appart from the knowledge I took from Clean Code I’ll plan to use the toxicity metric as an important tool for that.

Dependency Injection – We considered using Spring and decided against it, because we already had about 20 libraries we hardly knew in the project. Again at that time it was a reasonable decision. But in the meantime I learned what we could have gained by using Spring. I’ll propose using it, but even when the team declines again, I’ll be able to use the concept in order to improve the code base.

So these are the things I want to improve on in the next project. What are the things you want to improve on in your next project?