CODEWITHSUNDEEP
oopuml
user2248828
user2248828

Reputation: 11

Misunderstanding of a sentence in "UML Reference Manual" book (Booch, Rumbaugh, Jacobson)

Recently, i go back to read some parts of the "UML Reference Manual" book, second edition (obviously by: Booch, Rumbaugh, Jacobson).

(see: http://www.amazon.com/Unified-Modeling-Language-Reference-Manual/dp/020130998X)

Meanwhile, i have found these "strange" words in the first chapiter "UML overview" at "Complexity of UML" section:

There is far too much use of generalization at the expense of essential distinctions. The myth that inheritance is always good has been a curse of object orientation from earliest days.

I can't see how this sentence can be fully in line with Object Oriented Paradigm which states that inheritance is a fundamental principle.

Any idea/help please?

Upvotes: 1

Views: 68

Answers (2)

Ted Johnson
Ted Johnson

Reputation: 4343

Everything is good in moderation. Remember that the quote is not saying do not use it, or avoid, etc. Rather it is saying it is an overused principal when other OO abstractions or principals work better. Inheritance is powerful but it's coupling is tight.

Wisely or rather randomly the author of the UML book is saying pointing out this current truism that inheritance is often over-used and over-referenced. What about all the other principals and abstractions. I find that developers typically only hit the OO highlights (inheritance being one) and use that abstraction to excess.

For me in UML it is a good reminder that UML is OO generally, but it is not limited to Java or .Net OO features. Many languages only offer of the abstractions available across all languages. UML attempts to help you model and express many of them.

Remember the author only said 'too much use', not bad or incorrect. Also remember that maybe you are an expert developer who does not apply inheritance incorrectly.

Upvotes: 0

Vidya
Vidya

Reputation: 30320

You seem to believe the two points are mutually exclusive. They are not. Inheritance is a fundamental and powerful principle of object-oriented programming, and it is overused.

It is overused typically by inexperienced developers who are so captivated with the idea of inheritance that they are more focused on the inheritance tree than solving the problem. They try to factor out as much code as possible to some parent base class so they can just reuse it throughout the tree, and as a result they have a brittle design.

One of the greatest evils of software engineering is tight coupling between classes. That's the sort of thing that causes you to have to work through the weekend after the customer asks for a simple change. Why? Because making a change in one class has an effect on another class, and fixing that class has an effect on another, and so on.

Well, there is no tighter coupling than inheritance.

When you factor too much out to the "top level," every derived class is coupled to it. And as you find more and more code you want to factor out to various levels, you eventually have these deep trees, and every change made at the top cascades throughout the tree. As a result, you start to have methods that return null or are empty. They're unnecessary for the class, but the inheritance contract demands they be there. This violates the Liskov Substitution Principle.

So use inheritance of course. But do it smartly. Favor delegation to inheritance if you have any doubt. And when you do use inheritance, make sure you aren't factoring commonalities to the top level (of the whole tree or a subtree) just to reuse common code, but rather do so because there is a commonality of behavior from top to bottom.

If your tree is more than two or three levels deep (and I think three is really pushing it), you are almost certainly setting yourself up for trouble.

Upvotes: 2

Related Questions