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.
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.
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.
Subscribe to:
Posts
(
Atom
)