It seems to be fashionable to disparage OO lately — or at least it is on the aggregation sites I frequent. If I can be allowed a few over-generalizations, these “critiques” tend to share the following characteristics:
- They begin or end with a caveat that the best tool for the job should always be used. They then choose a problem for which OO is not especially well-suited and show how, in fact, it is not the best tool in this case. They then conclude that OO is just no good.
- They tend to be written by either:
- Advocates of fringe languages
- Web programmers
Today I’m not going to delve into attacking fringe languages or web programmers. Much. But I am going to discuss a few specific arguments/statements about OO that I’ve read recently that I think are unfair if not downright incorrect.
Many critiques boil down to over-use of inheritance. Examples are given of over-conceptualized hierarchies that quickly become brittle and unmaintainable. But these are critiques of particular designs, or approaches to design using the OO toolset — they are not critiques of OO itself. Every single programming language can be used poorly. It’s a special genius of programmers…
These critiques also miss the point in that OO is an organizing principle as much as a design principle: package data and functions that are tightly coupled together. Data abstraction is, IMO, a key tool used to manage and isolate complexity. (Again, the fact that data abstraction can be done poorly is no surprise — it’s a hard thing to do.)
Another OO-hating faction seems to think that all problems can be solved by lists and dictionaries. The thinking seems to be that no problems warrant the use of strong typing. I think there is some merit to this position, but only when thinking in terms of fairly small problems — for instance, creating a web page. Not to disparage the field unnecessarily, but many web programmers seem to have only ever programmed for the web and have no experience with truly large, complex programs. I don’t mean systems — lots of content management systems are very very complex — but individual programs, where the ability to isolate behavior by breaking it out into its own program is limited.
Now I’m a big fan of dictionaries, lists, meta-programming, and many other features favored by the Python and Ruby set, but they are not incompatible with OO. How data is represented to make implementation easy is a core design skill. But it isn’t data abstraction or encapsulation. OO layers that on top of implementation. So if your problem is simple enough not to warrant data abstraction, then OO probably isn’t the best tool for the problem.
Another post I read claimed that OO increased coupling unnecessarily, because when you pass an object to a function, you are including all the data in the object, not just the bits and pieces necessary. I have two responses to this. First, OO doesn’t require you to pass the whole object; you can pass just the necessary bits if you want. Second, in cases where you pass in the whole object it is usually likely that you already have fairly deep coupling between the object and the receiver of the object.
The fallacy behind this argument is that coupling is bad. But it is only through coupling that anything gets done at all! The problem with coupling is when there is too much of it. Granted, that’s a harder problem to solve than a simple proscription against all coupling, but that’s why we get the big money.
Not everything in the world benefits from decoupling!
Finally, some guy claimed that OO was not “fundamental”. Not sure what he meant by that, but in what way is data abstraction not fundamental to programming, software engineering, and computer science? I just don’t see it…
OO is not the be-all end-all programming/design construct; then again, none of them are.