OO Design

[A Kumar]

Hi,

Suppose i have a design where in the parent class has a set of attributes and there are few child classes derived from the parent class.

Now I have a req where i would like to inherit an attribute from the parent in one of the child classes but not in other child classes.



Thx,
A Kumar

[Andrew Nomos]

It's difficult to give you an anwser without knowing the exact circumstances you are facing.

Anyhow, I guess you should re-think your desing:
- can you separate the responsibilities of your root class so that problem will not arraise?
- can you introduce an additional layer to avoid it?
- perhaps you can use object composition instead of inheritance?

[miguel lisboa]

there are several ranchers that for sure will have an expert view about your case

for me, just my two cents:

why dont you remove your atribute from super class and put in the child class that needs it?

[A Kumar]

Suppose I were to have a parent class A- with 3 attr..

Now There are two child classes of this...

I inherit them,,,and do the necessary logic...Later on...the client

asks for certain modifications...which makes it necessary for me..to change my parent class...

What i want to know is that...

Its easy if we want to add attributes to an existing design structure but not scale down an existing parent class more so if there are
numerous sub classes...

Except of course if u are willing to spend time on lot of refactoring ..

Thnk u

[miguel lisboa]

Later on...the client

asks for certain modifications...which makes it necessary for me..to change my parent class...

once again, just my two cents

i guess in that case the use of interfaces is much better then inheritance; have a look at Strategy Pattern

[A Kumar]

Thank u..

[Stan James]

Changes to a parent class are risky and sometimes expensive. There are pretty good reasons to prefer "implements" or composition over "extends", especially when you are tempted to extend a concrete class or build a deep tree of inheritance.

The Liskov Substition Principle tells us that any code written to use class A should work equally well with any class B that extends A. If you write B so it doesn't provide all the functionality of A you'll break the rule at your own peril. This may be telling you that B shouldn't extend A, or maybe nothing should extend A and you should build up the "child" classes through composition.

Give us a holler if any of that raises more questions than it answers.

[Ilja Preuss]

Originally posted by A Kumar:
Except of course if u are willing to spend time on lot of refactoring ..

I'd spend as much time refactoring as necessary to make sure that the next time a similar feature request comes, it would be dead easy to implement.

Can you tell us more about the kind of requests you get?