Inheritance (object-oriented programming)

• 1. The 1967 Simula Breakthrough

  ›

  In 1967, Ole-Johan Dahl and Kristen Nygaard presented a design that allowed specifying objects belonging to different classes while sharing common properties. This idea first appeared in the Simula 67 programming language. The concept built upon earlier remarks Tony Hoare made about records in 1966 regarding record subclasses with private fields. Simula 67 collected common properties into a superclass where each subclass could potentially have its own superclass. Values of a subclass became compound objects consisting of prefix parts from various superclasses plus a main part belonging to the subclass itself. These parts were all concatenated together so attributes remained accessible via dot notation. The idea then spread to Smalltalk, C++, Java, Python, and many other languages.

  98

• 2. Single And Multiple Inheritance Types

  ›

  A class acquiring features from one superclass defines single inheritance. A derived class inherits the properties of another class without exception for constructors or destructors. One class can inherit features from more than one parent class through multiple inheritance. Multilevel inheritance occurs when a subclass is inherited from another subclass creating an inheritance path like ABC. Class B serves as an intermediate base class linking inheritance between A and C. The chain ABC represents this multilevel structure extending to any number of levels. Hierarchical inheritance happens when one class acts as a superclass for more than one subclass. Both B and C share parent class A yet remain separate subclasses. Hybrid inheritance mixes two or more types occurring when class A has subclass B which has two subclasses C and D.

  121317

• 3. Subtyping Versus Implementation Distinction

  ›

  Inheritance should not be confused with subtyping in programming language theory. Subtyping establishes an is-a relationship whereas inheritance only reuses implementation establishing a syntactic relationship. Inheritance does not ensure behavioral subtyping even if it commonly used for subtype relationships. Some statically-typed class-based OO languages like C++ and Java agree on both concepts while others differ. Subtyping sometimes referred to as interface inheritance acknowledges specialization of type variables inducing a subtyping relation. Inheritance defined here known as implementation inheritance or code inheritance focuses solely on reuse mechanisms. An instance of the reusing class cannot necessarily be substituted for an instance of the inherited class without assurance of polymorphic substitutability. It is entirely possible to derive a class whose object will behave incorrectly when used where parent class expected per Liskov substitution principle constraints.

  4520

• 4. Visibility Modifiers And Access Control

  ›

  The colon indicates that the subclass inherits from the superclass in C++ syntax. The visibility modifier is optional and may be either private or public if present. Default visibility remains private when no modifier appears in the declaration. Private derivation results in members not being inherited by the derived class. Protected derivation allows subclasses to access data without allowing external code access. Public derivation makes all base class features available to clients. Java and C# lack visibility modifiers for inheritance making them equivalent to public SuperClass in C++. A protected access modifier exists in modern languages including C++ and Java allowing subclasses to access data without exposing it outside the chain of inheritance. Client code generally has access to all object's superclass data even if superclass declared non-public through casting capabilities.

  1612

• 5. Fragile Base Class And Yo-Yo Problems

  ›

  Allen Holub identified the fragile base class problem as introducing unnecessary coupling through implementation inheritance. Modifications to base class implementation can cause inadvertent behavioral changes in subclasses breaking encapsulation. Complex inheritance within insufficiently mature designs leads to the yo-yo problem creating many very thin layers of code. Developers tended to break code into more layers of inheritance as system functionality grew during the late 1990s. Many layers consisting of only one or two lines of actual code make debugging a significant challenge. Too many layers make determining which layer needs debugging difficult for development teams combining multiple layers with single responsibility principle. Static hierarchy locks developers into original design standards preventing objects from changing type while retaining state at runtime.

  620

• 6. Composition Over Inheritance Alternatives

  ›

  Implementation inheritance has been controversial among programmers since at least the 1990s when critics advocated interface inheritance instead. The authors of Design Patterns favor composition over inheritance as an alternative technique requiring more programming effort but avoiding substitutability issues. Java inventor James Gosling reportedly stated he would not include implementation inheritance if redesigning Java today. Explicit delegation requires more programming effort yet avoids the substitutability issue entirely. Private and protected inheritance in C++ thought of as an is implemented in terms relationship rather than is-a relationship. Composite reuse principle supports polymorphism by separating behaviors from primary class hierarchy including specific behavior classes as required in business domain classes. This approach allows behavior modifications at run time enabling one class to implement behaviors buffet-style instead of restricted to ancestor class behaviors.

  1714