Redirected from Inheritance in object-oriented programming
Complex inheritances may cause Yo-yo problem.
The concept of inheritance is also used in other areas of computer science, such as Cascading Style Sheets.
|
Another form of specialization occurs when an inherited class specifies that it has a particular behavior but does not actually implement the behavior. Each class which inherits from that abstract class must provide an implementation of that behavior. This providing of actual behavior by a subclass is sometimes known as implementation[?] or reification.
Many object-oriented programming languages permit a class or object to replace the implementation of an aspect—typically a behavior—that it has inherited. This process is usually called overriding. Overriding introduces a complication: which version of the behavior does code from the inherited class see—the one that is part of its own class, or the overriding behavior? The answer varies between programming languages, and some languages provide the ability to indicate that a particular behavior is not to be overridden.
Extension is often used when incorporating the new features into the inherited class is either not possible or not appropriate. It can also be used at the object level, such as in the Decorator pattern.
In most quarters, class inheritance for the sole purpose of code re-use has fallen out of favor. The primary concern is that implementation inheritance does not provide any assurance of polymorphic substitutability—an instance of the re-using class cannot necessarily be substituted for an instance of the inherited class. An alternative technique, delegation, requires more programming effort but avoids the substitutability issue.
The notion that implementation inheritance should be avoided is not universal. One prominent object-oriented programming expert who believes that implementation inheritance has its place is Bertrand Meyer[?]. In his book Object Oriented Software Construction, 2nd ed., Meyer lists twelve different uses of inheritance that he considers to be legitimate, most of which involve some amount of implementation inheritance.
A Java program might have a class Animal that contained such data elements as whether the animal was presently alive, where it is currently located, etc.; as well as methods instructing the animal to eat, move, mate, etc. If we wanted to create a class Mammal, most of those data elements and functions would be the same as for most animals, but a few would change. We therefore define Mammal as a subclass of Animal (we then say that Animal is Mammal's superclass or parent class):
class Mammal extends Animal { Hair m_h; Breasts m_b;
Mammal reproduce() { Mammal offspring;
super.reproduce(); if (self.is_female()) { offspring = super.give_birth(); offspring.breastfeed(m_b); } care_for_young(offspring); return offspring; } }
Note here that we don't need to specify that a mammal has all the usual animal things: a location, ability to eat, move, etc. We do add some additional features such as hair and breasts that are unique to mammals, and we redefine the reproduce method to add functionality. Within the reproduce method, note the call super.reproduce(). This is a call to the superclass method which we are redefining. This roughly means "do whatever a member of my superclass would do", which is then followed by code specific to our new subclass.
See Multiple inheritance.
See also:
Search Encyclopedia
|
Featured Article
|