Thursday, August 28, 2008

OO Desillusion

I have read many inspiring books about object oriented programming. I find B. Meyer Object Oriented Software Construction one of the best in the lot. B. Meyer tries to explain in a progressive way why OO is better, by introducing it bit by bit. I have read different related design patterns book, the GoF one, Martin Fowler ones. I have been programming Java for about 10 years now. And yet, today, I feel unconvinced.

Maybe it is because I have been recently on different bigger projects, maybe it is because I have worked with different people. What I see today, is a tendency to overcomplexity. A simple example is you need a code to do only 3 different things in particular cases. Instead of using if-then-else, because it reminds you of the devils of procedural programming, you write 3 classes and 1 interface. Now the usual excuse for such a behavior is to say, we don't know, maybe there will be a 4th one, my code will make it easy to handle the 4th one. Often when there are requirements change, you don't expect at all where it will be, and it is not what a developer thought would change that actually changes. So the dev with the 3 classes has now to change its interface, update the 3 classes, and create a 4th one. The "procedural" guy has no such problem because he did not try to abstract something that did not need any abstraction in the first place.

Now on millions lines of code software, it is important to have a few basic principles in the overall design, to identify components that talk to each other, to define a global structure. But at the developer dimension, there is often no need for that, except in the few cases where it makes sense.

I do use design patterns sometimes, when I feel it is the simplest flexible way, but it is quite rare overall. There are 2 common jokes about design patterns. One is from people who don't know what they are. They often take the piss of architects doing design patterns all the time that in the end don't really know how to do things and spend a lot of time and money on crap. Other is from Pythonists and Rubyists. They say that you do not need design patterns if the language is done right.

The Java language, with the Generics, and the propositions for Java 7 is also evolving in the overcomplex side (ok, the Generics are probably much worse than Java 7 propositions). Soon people will be more confortable reading Haskell. Joke aside, Haskell while being different to read, has really something for it. It brings a new way of writing programs, moves the complexity somewhere else.

I still think lots of ideas in B. Meyer book are valid today. But an essential part must be missing. Overdesign seems to be too recurrent in OO projects.


  1. I think the desillusion you describe is more of the desillusion concerning design patterns.

    I like design patterns. But as you said when after reading the GOF-Book suddenly everybody sees patterns everywhere, your whole code base can explode because of all those factories, proxies, adapters and so on. I have the impression that this seems to happen more often in the Java world where design patterns are some kind of lingua franca (without them your code looks too simple, too understandable). One example that always pops up to my mind the Spring Framework where you can find killer class names like 'ContextSingletonBeanFactoryLocator' or 'SimpleRemoteStatelessSessionProxyFactoryBean'. Yet Spring is very successful and I'm surely in a minority but my brain buzzes when it must dig through all those abstract concepts to grasp the flesh & bones of a program. I left this programming world a while ago and am now happy in C#-Land.

    Don't blame OO for these outgrowths, the problem always sits in front of the computer.

  2. It's important to remember that, while the popularization of OOP may have begun with Meyer's book in the late 80's, object oriented design itself preceded relational technology. The marketing was so good that people now think it's the other way around... but to me a relational model is more powerful, and an object model is a special case of a relational one.

  3. You don't really have a problem with OO, you have a problem with OO *abuse*.