First, some philosophical background. I subscribe to the notion of Paul Feyerabend that knowledge grows in an “anything goes” fashion. That applies to every individual. There is no one universal methodology that monopolizes our every individual action and decision. Individuality is subjectivity.
With individuality comes asymmetry. There is asymmetry in knowledge and action.
And that asymmetry is so prevalent in knowledge-based industries, especially in IT industry. Even Microsoft is powerless in an asymmetric and epistemological anarchistic world! Somebody knows technology A, others know technology B and a lot more others know the “other” technology. It is not a “one-technology-rules-them-all” world. The same applies with hardware, software, paradigm, theory and practice.
With the epistemology of knowledge out of the way, let’s get to the main issue:
Allen Holub post on JavaWorld:
I once attended a Java user group meeting where James Gosling (Java’s inventor) was the featured speaker. During the memorable Q&A session, someone asked him: “If you could do Java over again, what would you change?” “I’d leave out classes,” he replied. After the laughter died down, he explained that the real problem wasn’t classes per se, but rather implementation inheritance (the
extendsrelationship). Interface inheritance (the
implementsrelationship) is preferable. You should avoid implementation inheritance whenever possible.
He adds what implementation inheritance implies:
- fragile base class
To be fair with OOP though, implementation inheritance seems to bode well with relatively small tasks like UI widgets or RAD IDE (Delphi, anyone?). In short, implementation inheritance is fine with relatively static tasks in contrast with dynamic business problems.
The way I see it, the answer is not absolute. It depends on context.
For dynamic business problems, implementation inheritance breaks down.
Lambda the Ultimate listed the OOP indictments:
- unwieldy monolithic class hierarchies
- multiple inheritance
- ‘is a’ and ‘has a’ relationships
- he forgot to mention Steve Yegge’s classic “Execution in the Kingdom of Nouns” 🙂
Instead, it suggests the OOP alternatives:
- Interfaces for Polymorphism
- Composition for code sharing and encapsulation
- Delegation for extension
Every technology like OOP has its merits and demerits. But remember, technology carries with it a hidden bias. Every technology has a kind of lock-in (in terms of mind share, economics, market and all aspects of individuality). Technology, just like reality, is subjective and objective at the same time!
Objectivity is falsifiability, subjectivity is individuality.
It is not that OOP itself is flawed. If you use class-based OOP, be aware of its implications. On the other hand, there is prototype-based OOP. As with classes, same caveat with prototypes.