The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

OO design

Hi all

In object orient language, lets consider method overwritten  in hierarchical design. The overwriten method which invokes its base class method and then does its specifice function.

is it good design aproach.

thx in adv

-arul maran
Arul Maran Send private email
Thursday, May 17, 2007
Generally I don't think so because it is so brittle. It depends on chaining methods which is hard to do as there's no way even to make it a requirement in the class spec.
son of parnas
Thursday, May 17, 2007
Is it good practice? Absolutely!

This takes me back to the days of "inheritance" with VB.

If you have a dialog box with 10 labels and you want to inherit that dialog to create a new one, you need to copy the entire dialog into another file.

With true inheritance, just inherit, override the correct method/event, call the base, and show/hide what you want.

Done deal with minimal code.

Hope this helps.
Jonathan Danylko Send private email
Thursday, May 17, 2007
> If you have a dialog box with 10 labels

Better to use a abstract interface and the use HASA to delegate to the common functionality. It's clearer and is easier to change strategies.
son of parnas
Thursday, May 17, 2007
Are you asking in fact if one should prefer aggregation over inheritance? If so, yes... I found out that it is quite easier to design with the "I prefer aggregation" ideea in mind than to dig for a perfect ISA hierarchy... But it is perfectly normal to reuse the base class method in a specialized type. And no, this fact alone doesn't say that a design is bad :)
Radu Chindris Send private email
Thursday, May 17, 2007
IT really starts to get ugly when you start chaining inheritance.  If you have (IMHO) 1-2 levels of inheritance, you're probably OK.  Once you get past that, you really start to get into structure dependency, which turns bad really fast.

If there is common code, why not refactor that into its own method, and make the base class method abstract?  You avoid the deep inheritance, and avoid the depencency on the parent class implementation.
Another Anonymous Coward
Thursday, May 17, 2007
I think inheritance is taught at the wrong time in many OO design courses. People tend to start off with a class, which is fine. And then they go on to inheritance. Usually the example is taxonomical - you have an animal class, and then you have a cat class and a dog class that inherits from it. And all three classes are concrete. In practice this design often isn't great.

It would be far better to teach composition before inheritance. It would be best to teach the interface / implementation split early as it rarely works out badly. But not concrete inheritance.

When should concrete class X inherit from concrete class Y? For me the canonical textbook example is about the worst time to do it. Before you know where you are, dog and cat are intimately bound into the specific working of animal, and the whole thing only gets messier as you try to add extra animals and 'reuse code' by moving it into subclasses. The whole thing can easily become a Gordian knot of code.

When to inherit from one concrete class to another ? For me it only seems to work out in a few cases.

1. X is a trivial specialisation of Y
If it's more than trivial, Y should specialise by using an interface Z from which X inherits.

2. X and Y are very different, but X uses services of Y.
In this case, X could be a class about widgets, and Y would describe a memory management strategy or a doubly linked list element. X and Y then remain essentially separate even though they inherit.
Duncan Sharpe
Thursday, May 17, 2007
> the canonical textbook example is about the worst time to do it.

Very good point. Taxonomies are about naming. Objects are about software. The examples sort of get OO off to a bad start from the very beginning.
son of parnas
Friday, May 18, 2007
Thanks eveyone to thier intputs.

I agree with  Duncan Sharpe.
Arul Maran Send private email
Friday, May 18, 2007
In general, I find it better to only override abstract functions.  I prefer that there only be a single implementation of a function in a particular inheritance path.
Wayne M.
Friday, May 18, 2007
Hi All,

I have one more query in Hierarchical Inheritance.

Lets consider the overwritten methods are implemented as dumpy method in the Base class since it require to be overwrite only a limit  derived class.

Alternatively we can make as abstract methods and then we can implement those dummy methods its appropriate derived class.

From the above two approach(keeping dummy method in Base or making abstract method in base) , which design is good ?   


-arul maran
Arul Maran Send private email
Friday, May 18, 2007
There is risk in extending any concrete class. Google for "Liskov Substitution Principle" and Alan Holub's "Extends Is Evil" article. Holub is deliberately over the top and provocative, I think, but his examples of fragile hierarchies are appropriately frightening.

Extending abstract classes is common in frameworks that do part of a function for you and call abstract methods that you must override to allow customization. It's common for a derived class to call super.sameMethod() if the base class provides useful behavior.

I've run into people who avoid creating and extending abstract classes for some of the same reasons that we avoid extending concrete classes, but I haven't bought into that part yet.

BTW: A gentle, friendly correction: Where the OP said "overwritten" I think you meant "overridden".
Stan James Send private email
Friday, May 18, 2007
"What would you recommend as a best-practices OO book?"

I think Object Oriented Software Construction (OOSC), by Bertrand Meyer, is the best book for laying a solid conceptual framework for pursuing the OO method.  (His new book, "Touch of Class," which targets the early stages of a software engineering curriculum might be even better, when it's finally complete).

OOSC not littered with practical examples, so you aren't going to copy code out of the book and paste it someplace, learning by example.  It's power comes from a clear and lucid exposition of OO concepts.  And this is what sets it apart from most other books I've read on the subject.  Most others talk about the concepts in an offhanded way, never giving clear guidance on exactly when and where a given concept is applicable.  Meyer's book does the opposite.  He describes each important concept with almost mathematical rigor.

As an example, inheritance, especially multiple inheritance, is looked at these days as a big liability.  The usual advice is to avoid it whenever possible, preferring composition instead.  If you study Meyer's treatment of the subject, though, you should be convinced that inheritance, USED PROPERLY, is a valuable asset - a powerful tool in your arsenal. You'll realize that most of the myth surrounding inheritance as a liability stems from the poor support offered by most popular languages and from the even poorer advice on how best to leverage it that permeates most discussions of the topic.

I don't think that OOSC by itself is enough to remove all of the mystery, but if you are serious about learning to do OO right, it's a great place to start.  Good Luck!
Franklin Send private email
Friday, May 18, 2007
P.S.  To stick with the theme of the current discussion, chapter 24 ("Using Inheritance Well") of the OOSC book I mentioned above discusses the proper use of inheritance, as well as misuses of it.  In particular, the chapter considers a number of cases where inheritance may be appropriate:

• Subtype inheritance.
• View inheritance.
• Restriction inheritance.
• Extension inheritance.
• Functional variation inheritance
• Type variation inheritance.
• Reification inheritance.
• Structure inheritance.
• Implementation inheritance.
• Facility inheritance (with two special variants: constant inheritance and machine

(p. 822 of OOSC)

The details of each case can be found in the book.  Note that some of these cases do not apply to languages like C# or Java because these languages lack support for important features which the discussion in the book presume to exist.  Even in this case, the discussion is still worth studying.
Franklin Send private email
Friday, May 18, 2007
"Better to use a abstract interface and the use HASA to delegate to the common functionality. It's clearer and is easier to change strategies."

That strategy results in poor productivity and code bloat! Furthermore, you need to look up the word "taxonomy." “Taxonomy" is a classification scheme, not a naming scheme.

Friday, May 25, 2007
+1 to OOSC

-1 to OOSC for the length of the book. Sometimes the book goes into much theory without any practical application. It does define exactly what it meant by Objects and inheritance, but it sometimes leaves the reader completly exhausted trying to cross reference all the point he bring.

Not saying its a bad bood, its actualy a great book for benginners getting a understanding with the subject matter. But the length and the constantly theory within the book without any real practical advantage drives you batty sometimes.
entity Send private email
Monday, May 28, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz