|
|
Re: I want know the Main Disadvantages using Inheritance
|
Posted: Jun 7, 2005 11:48 AM
|
|
responding to Parag
> Thats true inheritence does tightly couple the super and
> sub class. However... and I am just thinking aloud here...
> if we do not use inheritence, then we have to use
> composition, which also creates a coupling. So now the
> question is which of the two couplings is more
> maintainable.
Composition creates a substitutable coupling. That is whole depends on type of parts (not its actual implementaition). Moreover part can be used independently in another context. Without adding its own added behvaviour to its whole! Unless whole wants to expose those behaviour!
So if you look into current trends for better design there is growing trend for using composition than inheritance.
> Aspects that can change in any class are:
> - changing the method signature
> - adding a method
> - deleting a method
> - changing the implementation of a method
In OO smallest unit of re-usability, or substitutability is an object or a class.
When we abstract problem space in terms of behaviour of abstracted objects, we are sure/ ensure that one logic is abstracted only once within one object.
So when we talk of re-usability etc. naturally we dont talk of re-using a function outside scope of a class/ object.
If we just add/ delete a method its too low level changes to be talk about those things.
When we want to extend or add new behaviour to an object, we may like to extend its behaviour by adding a new type behaviour to it or add new role to an existing object. Or adding some behaviour directly to it. The later case is like extending a class.
In a better programming we call a class should be Open for extension for closed for modification.
In that sense, modifying method signature, adding/ deleting to make it better may be called as "refactoring". Not exactly an issue what we were discussing.
As no doubt better abstraction,design do always changes with time, exp, etc.
As for as better implementation is concerned, as said if that is available as substitutable part, we may not need to open the code of whole as it depends on type of part. and just replace older class with new one and instantiation code of part.
> 1. If a method signature is changed then we will be
> affected in both cases (inheritence & composition)
Too low level change.
> 2. Adding a method will not have a direct effect, unless
> we discover that the new method does something an old
> method did in a better way. In this case we may want to
> refactor our code to use the new method. I guess here the
> implication is again the same.
Extending a class/ object behaviour. Can be better done if this new behaviour could be abstracted as part of another object/ class.
> 4. Changing the implementation of a method should not have
> any effect either because the implementation is supposed
> to be a black box.
> To conclude inheritence creates a tighter coupling because
> of point 4.
Becomes more meaning ful when an object displays more than one role. Then displaying expected behaviour specific to a role or type requires more complex polymorphism, that is better writtten as composition than inheritance to avoid confusion in devlelopment, maintainenece, extense and have loose coupling.
So you rightly concluded that inheritance in this case creates tighter coupling so should be avoided and implemented as aggregation/ composition.
> Offcourse here we are assuming that we do not need to use
> polymorphism and we are using inheritence purely for code
> reuse.
This is the reason. We as inheritance adds up too much contextual information within inherited and may be base class. So try abstract the base class behavour or part of derived class behaviour as a part of some independent object.
------------
Shashank D. Jha
iCMG
e-mail : shashank@icmgworld.com
Phone : +91-80-98451 87302
|
|
Previous Topic
