PerlMonks has a healthy rant against OOP. It carries some valid points, like the conceptual overhead involved in OO design. I think this is at the center of all other rants, and the root cause is the approach of making everything into an object. Or for OOP-sake making everything part of an object.
Should everything be an object
Does OOP mean everything should be an object? Maybe there is no absolute answer to this question because there is no one sitting up there governing it. But I think if we try to model everything into objects, we are turning the problem of procedural programming on its head. I remember the quote from the patterns book
Objects that represent a process or algorithm do not occur in nature.
I believe OOP seems natural a lot of times because answers to most of the design questions like what and who turned out to be objects. And these objects carry a lot of implied data and unsaid preferences with them. OOP let us model that as close as possible to the real world.
However, one question that can bloat your design is how. Trying to forcibly model this into an object can result in a host of new objects which are trying to make this work. And at this time OOP ceases to be natural.
Scope
One of the aims of using objects is to control how you build them and this means you have to be able to decompose them and know them from the inside. And there are also objects which you just use, and do not need to build yourself. Sometimes an integer is an integer is an integer, nothing more, nothing less. It can be waste of an effort and time, and possibly even harmful if we always try to model it into an object.
A lot of frameworks do this, perhaps for programming convenience, but it does impose a lot of conceptual overhead. Scope is something that can guide you, unfortunately it is still unknown enough to cause most of the failures.
There are benefits
Apart from this, I think OOP is extremely useful, even without the syntax and the keywords.
It is perhaps using the same approach for all problems that causes the problems. OOP concepts and principles do help us decompose the problem, automate better and build flexible software. But when it starts serving itself more than the software, I start disliking it too.
October 24th, 2007 at 3:09 am
OOP is a way of thinking - sometimes it works, sometimes it doesn’t. There are other paradigms for programming languages: Functional, where everything is a function; Concurrent, where everything is a process; etc.
It doesn’t have to be. Though then again, if you think of an Object as a collection with an ability to sort itself.. or sort similar collections — that’s an algorithm in an Object form.
October 24th, 2007 at 9:54 am
My theory:
Good programmers find it easy and natural to apply polymorphism and encapsulation to their design in the most appropriate way, because those things come easily to them on a conceptual level. Lesser programmers don’t think or design at such a high level naturally, but OO provides a recipe by which they can implement such things without such a good understanding of the abstract concepts. It doesn’t really work for the harder design problems, and doesn’t tend to give the _best_ solution to any problem, but it works good-enough for most problems.
Of course even OO is hard to digest for the worst programmers, and can really get in the way of the good programmers capable of coming up with a better design from first principles
October 24th, 2007 at 11:00 am
Thanks for your comments.
Tony, I agree with you that OOP is a way of thinking and is related more to concepts. However, most of the times the disadvantages come out of implementing OO concepts the wrong way.
I looked at algorithms and processes as verbs, and objects are natural for noun. The question to be asked is do we have to model these verbs as objects. I think there are a lot of objections to this.
Greg, good point there. Abstraction, I think, is the core benefit of OOP. However, its value is realized when you do the right level of abstraction. This is not a problem of OOP, but the OOP designers and programmers. Unfortunately OOP becomes subject of the discussion.
October 26th, 2007 at 7:49 am
I think OOP and OOP languages tend to lock you into a particular level of abstraction that isn’t always appropriate. OK you can still have multiple levels, but it’s pretty coarse-grained.
October 27th, 2007 at 9:43 am
[...] criticism, unfortunately, most of it not constructive! Actually we have seen this a lot with OOP as well. There are some common elements to such kind of [...]