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.

2 Comments | Software | Tagged: , , , , , , | Permalink
Posted by digulla

Why WYSIWYG doesn’t work II

7. December, 2009

In my old post “The Space Between Two Characters“, I wrote about some flaws of WYSIWYG. Since then, I got some feedback.

The real issue behind the issues with WYSIWYG is that it doesn’t work while you edit the document. The concept is flawed, not the implementation. It is flawed because it omits some vital information that you need for editing. The information is omitted because it doesn’t make sense anymore as soon as you print the document on paper. And WYSIWYG means “if you don’t see it, you won’t get it.”

So it makes sense to omit feedback on where ranges start and end, what kind of break follows after a line, there the handles for a table are. But most WYSIWYG editors today have a “show invisible” option. Word can show you all those invisible characters so you can see “oh, this is a tab and not a space”.

For this to work, we need a tight integration between the editor model, the renderer and the view. The problem here is, as usual, performance. If you add all the hooks you need to be able to show nice visual feedback in the view, printing to a printer will be slower.

How much? Well, not much. Anymore. You’re quadcore will be 95% bored. It will need memory. How much? Well, to remember the bounding boxes for all letters rendered on the screen takes at most 4’608’000 bytes (“i”, 8px font, 30″ display with 3840×1200). That might seem like a lot but almost no PC sold next year will have less then 4GB of RAM, not even the Netbooks. My mobile phone comes with 32GB!

For printing, the values are usually much smaller. A normal page of text has around 1’500 to 2’500 characters per page and for printing, you just need to remember the current and maybe the next page (unless you need a page count but with todays CPUs, you can layout the pages twice).

So the final obstacles is code complexity. OO has helped a lot to cut down complexity in algorithms but there are problems which you can’t solve nicely with OO, for example “run this algorithm but replace line 5 with …” or “before … run …”.

AOP has come to solve this but it has failed to deliver so far. Maybe this is because point-cuts are too complicated to formulate, maybe because the debuggers can’t handle this case well, maybe because the setup is too complex or the resulting code is too fragile. Or because people are afraid of the leap of faith it takes to use it.

Leave a Comment » | Software | Tagged: , , , | Permalink
Posted by digulla

%d bloggers like this: