Sun . 19 Feb 2019

Inheritance (object-oriented programming)

In object-oriented programming, inheritance is when an object or class is based on another object prototypal inheritance or class class-based inheritance, using the same implementation inheriting from an object or class or specifying a new implementation to maintain the same behavior realizing an interface; inheriting behavior; programming by difference Such an inherited class is called a subclass of its parent class or super class It is a mechanism for code reuse and to allow independent extensions of the original software via public classes and interfaces The relationships of objects or classes through inheritance give rise to a hierarchy Inheritance was invented in 1967 for Simula The term "inheritance" is loosely used for both class-based and prototype-based programming, but in narrow use is reserved for class-based programming one class inherits from another, with the corresponding technique in prototype-based programming being instead called delegation one object delegates to another

Inheritance should not be confused with subtyping In some languages inheritance and subtyping agree, whereas in others they differ; in general, subtyping establishes an is-a relationship, whereas inheritance only reuses implementation and establishes a syntactic relationship, not necessarily a semantic relationship inheritance does not ensure behavioral subtyping To distinguish these concepts, subtyping is also known as interface inheritance, whereas inheritance as defined here is known as implementation inheritance or code inheritance Still, inheritance is a commonly used mechanism for establishing subtype relationships

Inheritance is contrasted with object composition, where one object contains another object or objects of one class contain objects of another class; see composition over inheritance Composition implements a has-a relationship, in contrast to the is-a relationship of subtyping


  • 1 Types of inheritance
  • 2 Subclasses and superclasses
    • 21 Uninheritable classes
    • 22 Methods that cannot be overridden
    • 23 Virtual methods
  • 3 Visibility of inherited members
  • 4 Applications
    • 41 Overriding
    • 42 Code reuse
  • 5 Inheritance vs subtyping
    • 51 Design constraints
  • 6 Issues and alternatives
  • 7 See also
  • 8 Notes
  • 9 References
  • 10 Further reading

Types of inheritance

Single inheritance Multiple inheritance

There are various types of inheritance, based on paradigm and specific language

Single inheritance where subclasses inherit the features of one superclass A class acquires the properties of another class Multiple inheritance where one class can have more than one superclass and inherit features from all parent classes

"Multiple Inheritance object-oriented programming was widely supposed to be very difficult to implement efficiently For example, in a summary of C++ in his book on objective C BrdCox actually claimed that adding Multiple inheritance to C++ was impossible Thus, multiple inheritance seemed more of a challenge Since I had considered multiple inheritance as early as 1982 and found a simple and efficient implementation technique in 1984 I couldn't resist the challenge I suspect this to be the only case in which fashion affected the sequence of events"

— Bjarne Stroustrup Multilevel inheritance where a subclass is inherited from another subclass It is not uncommon that a class is derived from another derived class as shown in the figure "Multilevel inheritance" Multilevel inheritance The class A serves as a base class for the derived class B, which in turn serves as a base class for the derived class C The class B is known as intermediate base class because it provides a link for the inheritance between A and C The chain ABC is known as inheritance path

A derived class with multilevel inheritance is declared as follows:

Class A; //Base class Class B : public A; //B derived from A Class C : public B; //C derived from B

This process can be extended to any number of levels

Hierarchical inheritance where one class serves as a superclass base class for more than one sub class Hybrid inheritance a mix of two or more of the above types of inheritance

Subclasses and superclasses

A Subclass, "derived class", heir class, or child class is a modular, derivative class that inherits one or more language entities from one or more other classes called superclass, base classes, or parent classes The semantics of class inheritance vary from language to language, but commonly the subclass automatically inherits the instance variables and member functions of its superclasses The general form of defining a derived class is:

class derived-class-name : visibility-mode base-class-name ;

  • The colon indicates that the derived-class-name is derived from the base-class-name The visibility-mode is optional and, if present, may be either private or public The default visibility-mode is private Visibility mode specifies whether the features of the base class are privately derived or publicly derived

Some languages support the inheritance of other constructs also For example, in Eiffel, contracts that define the specification of a class are also inherited by heirs The superclass establishes a common interface and foundational functionality, which specialized subclasses can inherit, modify, and supplement The software inherited by a subclass is considered reused in the subclass A reference to an instance of a class may actually be referring to one of its subclasses The actual class of the object being referenced is impossible to predict at compile-time A uniform interface is used to invoke the member functions of objects of a number of different classes Subclass may replace superclass functions with entirely new functions that must share the same method signature

Uninheritable classes

In some languages a class may be declared as uninheritable by adding certain class modifiers to the class declaration Examples include the "final" keyword in Java and C++11 onwards or the "sealed" keyword in C# Such modifiers are added to the class declaration before the "class" keyword and the class identifier declaration Such sealed classes restrict reusability, particularly when developers only have access to precompiled binaries and not source code

The sealed class has no subclasses, so it can be easily deduced at compile time that references or pointers to objects of that class are actually referencing instances of that class and not instances of subclasses they don't exist or instances of superclasses upcasting a reference type violates the type system subtype polymorphism Because the exact type of the object being referenced is known before execution, early binding or "static dispatch" can be used instead of late binding also called "dynamic dispatch" or "dynamic binding", which requires one or more virtual method table lookups depending on whether multiple inheritance or only single inheritance are supported in the programming language that is being used

Methods that cannot be overridden

Just as classes may be sealed/finalized method declarations may contain method modifiers that prevent the method from being overridden ie replaced with a new function with the same name and type signature in a subclass A private method is unoverridable simply because it is not accessible by classes other than the class it is a member function of this is not true for C++, though A "final" method in Java, a "sealed" method in C# or a frozen feature in Eiffel cannot be overridden

Virtual methods

If the superclass method is a virtual method, then invocations of the superclass method will be dynamically dispatched Some languages require methods to be specifically declared as virtual eg C++ and in others all methods are virtual eg Java An invocation of a non-virtual method will always be statically dispatched ie the address of the function call is determined at compile-time Static dispatch is faster than dynamic dispatch and allows optimisations such as inline expansion

Visibility of inherited members

Base class visibility Derived class visibility
Public derivation Private derivation Protected derivation
  • Private →
  • Protected →
  • Public →
  • Not inherited
  • Protected
  • Public
  • Not inherited
  • Private
  • Private
  • Not inherited
  • Protected
  • Protected


Inheritance is used to co-relate two or more classes to each other


Main article: Method overriding Illustration of method overriding

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 an instance of the inherited class use—the one that is part of its own class, or the one from the parent base class The answer varies between programming languages, and some languages provide the ability to indicate that a particular behavior is not to be overridden and should behave as defined by the base class For instance, in C#, the base method or property can only be overridden in a subclass if it is marked with the virtual, abstract, or override modifier An alternative to overriding is hiding the inherited code

Code reuse

Implementation inheritance is the mechanism whereby a subclass re-uses code in a base class By default the subclass retains all of the operations of the base class, but the subclass may override some or all operations, replacing the base-class implementation with its own

In the following Python example, subclasses SquareSumComputer and CubeSumComputer override the transform method of the base class SumComputer The base class comprises operations to compute the sum of the squares between two integers The subclass re-uses all of the functionality of the base class with the exception of the operation that transforms a number into its square, replacing it with an operation that transforms a number into its square and cube respectively The subclasses therefore compute the sum of the squares/cubes between two integers

class SumComputerobject: def __init__self, a, b: selfa = a selfb = b def transformself, x: raise NotImplementedError def inputsself: return rangeselfa, selfb def computeself: return sumselftransformvalue for value in selfinputs class SquareSumComputerSumComputer: def transformself, x: return x x class CubeSumComputerSumComputer: def transformself, x: return x x x

In most quarters, class inheritance for the sole purpose of code reuse has fallen out of favor The primary concern is that implementation inheritance does not provide any assurance of polymorphic substitutability—an instance of the reusing class cannot necessarily be substituted for an instance of the inherited class An alternative technique, explicit delegation, requires more programming effort, but avoids the substitutability issue In C++ private inheritance can be used as a form of implementation inheritance without substitutability Whereas public inheritance represents an "is-a" relationship and delegation represents a "has-a" relationship, private and protected inheritance can be thought of as an "is implemented in terms of" relationship

Another frequent use of inheritance is to guarantee that classes maintain a certain common interface; that is, they implement the same methods The parent class can be a combination of implemented operations and operations that are to be implemented in the child classes Often, there is no interface change between the supertype and subtype- the child implements the behavior described instead of its parent class

Inheritance vs subtyping

Further information: Subtyping

Inheritance is similar to but distinct from subtyping Subtyping enables a given type to be substituted for another type or abstraction, and is said to establish an is-a relationship between the subtype and some existing abstraction, either implicitly or explicitly, depending on language support The relationship can be expressed explicitly via inheritance in languages that support inheritance as a subtyping mechanism For example, the following C++ code establishes an explicit inheritance relationship between classes B and A, where B is both a subclass and a subtype of A, and can be used as an A wherever a B is specified via a reference, a pointer or the object itself

class A ; class B : public A ; void UseAnAA const& some_A void SomeFunc

In programming languages that do not support inheritance as a subtyping mechanism, the relationship between a base class and a derived class is only a relationship between implementations a mechanism for code reuse, as compared to a relationship between types Inheritance, even in programming languages that support inheritance as a subtyping mechanism, does not necessarily entail behavioral subtyping It is entirely possible to derive a class whose object will behave incorrectly when used in a context where the parent class is expected; see the Liskov substitution principle Compare connotation/denotation In some OOP languages, the notions of code reuse and subtyping coincide because the only way to declare a subtype is to define a new class that inherits the implementation of another

Design constraints

Using inheritance extensively in designing a program imposes certain constraints

For example, consider a class Person that contains a person's name, date of birth, address and phone number We can define a subclass of Person called Student that contains the person's grade point average and classes taken, and another subclass of Person called Employee that contains the person's job-title, employer, and salary

In defining this inheritance hierarchy we have already defined certain restrictions, not all of which are desirable:

Singleness Using single inheritance, a subclass can inherit from only one superclass Continuing the example given above, Person can be either a Student or an Employee, but not both Using multiple inheritance partially solves this problem, as one can then define a StudentEmployee class that inherits from both Student and Employee However, in most implementations, it can still inherit from each superclass only once, and thus, does not support cases in which a student has two jobs or attends two institutions The inheritance model available in Eiffel makes this possible through support for repeated inheritance Static The inheritance hierarchy of an object is fixed at instantiation when the object's type is selected and does not change with time For example, the inheritance graph does not allow a Student object to become a Employee object while retaining the state of its Person superclass This kind of behavior, however, can be achieved with the decorator pattern Some have criticized inheritance, contending that it locks developers into their original design standards Visibility Whenever client code has access to an object, it generally has access to all the object's superclass data Even if the superclass has not been declared public, the client can still cast the object to its superclass type For example, there is no way to give a function a pointer to a Student's grade point average and transcript without also giving that function access to all of the personal data stored in the student's Person superclass Many modern languages, including C++ and Java, provide a "protected" access modifier that allows subclasses to access the data, without allowing any code outside the chain of inheritance to access it

The composite reuse principle is an alternative to inheritance This technique supports polymorphism and code reuse by separating behaviors from the primary class hierarchy and including specific behavior classes as required in any business domain class This approach avoids the static nature of a class hierarchy by allowing behavior modifications at run time and allows one class to implement behaviors buffet-style, instead of being restricted to the behaviors of its ancestor classes

Issues and alternatives

Implementation inheritance is controversial among programmers and theoreticians of object-oriented programming since at least the 1990s Among them are the authors of Design Patterns, who advocate interface inheritance instead, and favor composition over inheritance For example, the decorator pattern as mentioned above has been proposed to overcome the static nature of inheritance between classes As a more fundamental solution to the same problem, role-oriented programming introduces a distinct relationship, played-by, combining properties of inheritance and composition into a new concept

According to Allen Holub, the main problem with implementation inheritance is that it introduces unnecessary coupling in the form of the "fragile base class problem": modifications to the base class implementation can cause inadvertent behavioral changes in subclasses Using interfaces avoids this problem because no implementation is shared, only the API Another way of stating this is that "inheritance breaks encapsulation" The problem surfaces clearly in open object-oriented systems such as frameworks, where client code is expected to inherit from system-supplied classes and then substituted for the system's classes in its algorithms

Reportedly, Java inventor James Gosling has spoken against implementation inheritance, stating that he would not include it if he were to redesign Java Language designs that decouple inheritance from subtyping interface inheritance appeared as early as 1990; a modern example of this is the Go programming language

Complex inheritance, or inheritance used within an insufficiently mature design, may lead to the yo-yo problem

Another issue with inheritance is that subclasses must be defined in code, which means that program users cannot add new subclasses Other design patterns allow program users to define variations of an entity on runtime

See also

  • Circle-ellipse problem
  • Defeasible reasoning
  • Interface computing
  • Method overriding
  • Mixin
  • Polymorphism computer science
  • Protocol
  • Role-oriented programming
  • The Third Manifesto
  • Trait computer programming
  • Virtual inheritance


  1. ^ This is generally true only in statically-typed class-based OO languages, such as C++, C#, Java, and Scala


  1. ^ https://wwwcsemsuedu/~cse870/Input/SS2002/MiniProject/Sources/DRCpdf
  2. ^ Mike Mintz, Robert Ekendahl 2006 Hardware Verification with C++: A Practitioner’s Handbook United States of America: Springer p 22 ISBN 0-387-25543-5 
  3. ^ Cook, William R; Hill, Walter; Canning, Peter S 1990 Inheritance is not subtyping Proc 17th ACM SIGPLAN-SIGACT Symp on Principles of Programming Languages POPL pp 125–135 CiteSeerX 10111028635 doi:101145/9670996721 ISBN 0-89791-343-4 
  4. ^ Cardelli, Luca 1993 Typeful Programming Technical report Digital Equipment Corporation p 32–33 SRC Research Report 45 
  5. ^ a b c Mikhajlov, Leonid; Sekerinski, Emil 1998 A study of the fragile base class problem PDF Proc 12th European Conf on Object-Oriented Programming ECOOP Lecture Notes in Computer Science 1445 pp 355–382 doi:101007/BFb0054099 ISBN 978-3-540-64737-9 
  6. ^ Tempero, Ewan; Yang, Hong Yul; Noble, James 2013 What programmers do with inheritance in Java PDF ECOOP 2013–Object-Oriented Programming pp 577–601 
  7. ^ Bjarne Stroustrup The Design and Evolution of C++ p 417 
  8. ^ Herbert Schildt 2003 The complete reference C++ Tata McGrawhill Education Private Limited p 417 ISBN 0-07-053246-X 
  9. ^ E Balagurusamy 2010 Object Orientedprogramming With C++ Tata McGrawhill Education Pvt Ltd p 213 ISBN 0-07-066907-4 
  10. ^ http://msdnmicrosoftcom/en-us/library/ebca9ah3aspx overrideC# Reference
  11. ^ "GotW #60: Exception-Safe Class Design, Part 2: Inheritance" Gotwca Retrieved 2012-08-15 
  12. ^ Dr K R Venugopal, Rajkumar Buyya 2013 Mastering C++ Tata McGrawhill Education Private Limited p 609 ISBN 9781259029943 
  13. ^ Cook, Hill & Canning 1990
  14. ^ Mitchell, John 2002 "10 "Concepts in object-oriented languages"" Concepts in programming language Cambridge, UK: Cambridge University Press p 287 ISBN 0-521-78098-5 
  15. ^ a b c Holub, Allen 1 August 2003 "Why extends is evil" Retrieved 10 March 2015 
  16. ^ Seiter, Linda M; Palsberg, Jens; Lieberherr, Karl J 1996 "Evolution of object behavior using context relations" ACM SIGSOFT Software Engineering Notes 21 6: 46 CiteSeerX 1011365053 doi:101145/250707239108 
  17. ^ America, Pierre 1991 Designing an object-oriented programming language with behavioural subtyping PDF REX School/Workshop on the Foundations of Object-Oriented Languages Lecture Notes in Computer Science 489 pp 60–90 doi:101007/BFb0019440 ISBN 978-3-540-53931-5 

Further reading

  • Object-Oriented Software Construction, Second Edition, by Bertrand Meyer, Prentice Hall, 1997, ISBN 0-13-629155-4, Chapter 24: Using Inheritance Well

Inheritance (object-oriented programming) Information about

Inheritance (object-oriented programming)

  • user icon

    Inheritance (object-oriented programming) beatiful post thanks!


Inheritance (object-oriented programming)
Inheritance (object-oriented programming)
Inheritance (object-oriented programming) viewing the topic.
Inheritance (object-oriented programming) what, Inheritance (object-oriented programming) who, Inheritance (object-oriented programming) explanation

There are excerpts from wikipedia on this article and video

Random Posts

Body politic

Body politic

The body politic is a metaphor that regards a nation as a corporate entity,2 likened to a human body...


Kakamega is a town in western Kenya lying about 30 km north of the Equator It is the headquarte...
Academic year

Academic year

An academic year is a period of time which schools, colleges and universities use to measure a quant...
Lucrezia Borgia

Lucrezia Borgia

Lucrezia Borgia Italian pronunciation: luˈkrɛttsja ˈbɔrdʒa; Valencian: Lucrècia Borja luˈkrɛsia...