Cycles in dependency injection

9. November, 2010

There is an old argument in DI: How to handle dependency cycles?

Say you have logging and reading of configuration files. Logging needs the config (how should I log?) and the config needs to log (where was the config read from?). How do you solve that?

It gets worse when people insist that DI fields have to be final (i.e. immutable) or that dependencies must be injected via constructors. How on earth can you create the logger if it needs a config instance as constructor parameter and the config instance needs a logger in the constructor?

The “solution”: Proxies. You create the config instance with a proxy to the real logger, then create the logger with the config instance and finally, you replace the proxy with the logger.

Why is that solution bad?

Because your code now has two bugs: You have a cyclic dependency (bad but sometimes necessary) and you’re trying hard to pretend you don’t have one. If someone will have to fix a bug in there, they won’t expect that the “final” instances can actually change.

On top of that, it makes your code inflexible. My gut feeling is that there is a reason why you can’t add plug-ins to Eclipse without having to restart the whole IDE. The infrastructure to manage plug-ins can add and remove them at runtime – unless you prevent that by using “solutions” code like the one outlined above.

Or as Yoda would have said: Much fear in you I sense.

Get over your fear. Write better unit tests (which will also become more simple if you don’t use final fields). Avoid “final” unless Java forces you to use it.


Dependency Injection and Reference Passing

21. July, 2010

When you start using dependency injection (DI), you probably come from the painful world of singletons. Singletons are a lie. When we were doing structured programming (remember? What we did before OO?), that was called “global variable” and everyone knew they were bad. But hey, OO came along and we had the same problem and to solve it … we used global variables. Only we didn’t name them that. We said “It’s a Singleton!” and everybody was happy.

Except that the mighty singleton has the same problems as the global variable – because they are the same thing.

A solution was sought and DI was invented. When people start to use DI, they are still in the “Singleton” mind because you can’t get rid of an idea that has served you (more or less) well over many years. Since a human can’t simply forget what he’s been doing for a long time (it’s traditional), singletons leaked into DI leading to odd design which felt wrong.

Software developers are paid for their brains. If something feels wrong, it usually is. Most of the early code we come up with then starting with DI violates the Law of Demeter.

A common solution to the problems with many singletons is to replace them with a single singleton (for example one which loads and offers the application context in Spring). While this is convenient, we still have a global variable left.

Another solution is to write constructors that take 27 parameters so you can pass in all the parameters. If you avoid that trap, then your class will have 27 setters. Holy Ugly, Batman.

How to solve that? Use more DI. Most of the 27 ex-singletons will be passed on to other worker classes. So instead of passing on the singletons to create the worker classes deep down in the code, create the worker classes using DI (so the DI framework can fill in all the ex-singletons they need) and then pass in the 2-3 workers.

For some code, see this article: Dependency Injection Myth: Reference Passing


Jazoon 2010 Day 1

2. June, 2010

So, this is the great wrap-up of Jazoon 2010, day 1. What did I have?

The keynote by Danny Coward

Java SE and JavaFX: The Road Ahead. After the acquisition by Oracle, everyone was curious as to what happens to Java. Unfortunately, the slides aren’t online, yet but from my faint memory, we might get closures after all and with a sane syntax, too. Plus all the stuff mentioned on Sun’s JDK 7 page. ATM, this stuff is a bit fluent and it’s hard to get a definitive list but something is moving at least.

From my point of view, closures and all the other language features are too late for the Java language (important companies won’t upgrade to Java 7 and time soon, some of them even cling to 1.4!) but the implementation in the main language of the Java VM will allow to build better and faster non-Java languages on top of the VM. Now if the VM would include a compiler API to build JNI code for native libraries on the fly, we would have a worthy challenger for .NET. Yeah … I know. A man can have dreams, okay?

And there was some talk about JavaFX. It seems that the technology is starting to reach its beta-phase, soon (see my notes for the second day). He showed one demo: Geo View of Vancouver 2010. It’s a world map with which country won how many medals and when you open one of the blobs, you get the names of the athletes in a fan-out widget. You can click on the name to get more information (like the photo) or you can compare the results against countries with the same number of athletes or population or closest GDP or just closest geographically. It gives a nice example how to visualize a lot of data and wade through them intuitively.

Client / Server 2.0 with Java and Flex by James Ward

James showed how you can use Flash and a Java server to build really nice web apps. He showed several examples: A few lines of code to build a UI which runs on an Android mobile phone, in the web browser and on the desktop. All with really nice performance. One was the insurance company demo. Just enter some arbitrary data until you come to the damage details and incident report. They show new ways to enter information which make the tool usable to anyone who can recognize a car and a top-view of a street.

If you like what you see, you should probably take the Tour de Flex. It shows off a whole lot of stuff. Also try the Tour de Flex Dashboard. It shows you in real time who looks at what part of the TdF right now.

Blueprint – Modern Dependency Injection for OSGi by Costin Leau

Another DI system, this time tied to OSGi. Nothing really exciting here. The talk was okay but the speaker soon lost my interest.

One thing to note: Eclipse 4 comes with a different DI system. I wonder if they will drop that in favor of the new OSGi standard in 4.1.

Patterns and Best Practices for building large GWT applications by Heiko Braun

I went to see this but quickly realized that I’ve heard the talk before at the JUGS. Here is the link to the slides. As a result of his experience he started project errai which collects best practices to build large GWT applications.

Objects of Value by Kevlin Henney

One of the main weak points on software development is that we don’t know what we’re talking about. When my project manager comes to me and asks “When are you done?” my answer is “Soon” … Right 😉 Or think about strings. Everyone else on the planet calls it “text”.

Obviously, Kevlin had a lot of fun on stage and so had we. In essence, “Objects of Value” or “Value Objects” are even more simple than POJOs (think Integer class). The main reason to use them is to make your code more expressive and readable. Instead of

public User (String name, String firstName, int age, String zipCode, String city)

you (can) create a couple of value objects:

public User (Name name, FirstName firstName, Age age, ZipCode zipCode, City city)

This may sound ridiculous (and it is in this example) but in a lot of places, using String is just a form of bad laziness (the kind of laziness which leads to maintenance problems later). One of the advantages of the approach above is that you notice when you mix last and first name because the compiler will tell you. The major disadvantage is that it leads to a class explosion. Not to an instance explosion since we just replace a String value object with something that tells us what we have, though.

In addition to that, Java isn’t really meant for these kinds of objects. There is a lot of boiler plate code to define value objects and to use them. But if you have a system that is sufficiently complex and you use a value with a unit in many places (think of a currency value), you should really consider to replace the String+BigDecimal combination with a value object.

Many important points of his talk can be found in the paper Objects of Value on his homepage.

This concludes the first part of my Jazoon 2010 report. Go on with part 2.