OO 2.0: Reuse

25. February, 2010

What’s the most important feature of OO? Reuse.

What’s the biggest problem of Java? Reuse.

In Java, it’s considered good practice to make everything private or even final. This goes along the lines “when I open part of my API, someone might use it and this might cause problems for me later when I have to change the API”. So all fields are private. Which leads to huge lists of getters and setters which you don’t need most of the time. But you can’t omit them because if you need them, you can’t retrofit them. I guess all of us have a story where we wanted to use a class and everything was fine until we needed one more thing from that class and that thing wasn’t public or protected.

The underlying problem is that Java is based on the idea that the code is simple to parse and read. Which means that things like templates, patterns or pre-compilers aren’t supported. Even when you use annotations, you can’t modify the output at compile time. You can use load time byte-code manipulation but at compile time, the code is about as flexible as a bridge pillar.

But there is hope. The guys from the Object Teams project (OT) have created a Java-like language where you can reach into existing code and manipulate it in various ways. If you’re wondering if this is AOP with a new name or just delegation on steroids, this post will help to understand what OT is and what it’s not.

In a nutshell, OT is about reuse. If some class doesn’t provide a getter for a private field, OT can insert one for you. To get a feeling if OT can help you, I suggest to browse the blog and the examples. The stop watch example is probably the most simple to understand. The other examples look a bit incomplete or they might show that OT still has some issues with the syntax (which you’ll remember from AOP but it’s certainly not as extreme).

I, for one, will keep an eye on this project.