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.
In my opinion, OO was derailed by the idea that OO was all about using dynamic dispatching to do cool stuff.
ReplyDeleteThere seem to be two major schools of thought about object orientation. One school holds that a class models something, while the other holds that a class encapsulates behaviors along with any necessary state.
One obvious distinction between the former school—sometimes called the Scandinavian School—and the latter school—sometimes called the American school—is that in the Scandinavian school a class is typically designed as a collection of data along with some methods to support that data, while in the American school a class is typically designed as a collection of methods along with some data to support those methods.
Meyer was (is?) basically of the Scandinavian School, although with a strong interest in the "reuse" aspects stressed by the American School. Neither the Scandinavian school nor Meyer's modified view prevailed, though. Instead the American school—promoted by Robert C. Martin and the Gang of Four among others—won out.
Some practitioners of the American school got carried away in their zeal that OO=good and procedural=evil. This led to bizarre (IMHO) practices such as you've mentioned of trying to refactor every "if" and "case" into a dynamically dispatched method call.
(It has been argued, and I'm inclined to agree, that there is a third school of OO championed by Alan Kay. From what I can tell, that school tends to be more concerned with objects than classes.)
I think the desillusion you describe is more of the desillusion concerning design patterns.
ReplyDeleteI 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.
Hi,
ReplyDeleteI totally agree with you, I've been using java for 6 years and now coding in PHP for two more years feels like I've been doing lot of plumbing when using java.
Take a look at my RCP like framework http://www.microcalls.org where I take a simplistic approach to DB connections using XML
My prefered pattern is MVC which is usefull in all the projects.
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.
ReplyDeleteYou don't really have a problem with OO, you have a problem with OO *abuse*.
ReplyDelete