The Concept of Inheritance

Inheritance represents one of the fundamental pillars of object-oriented programming, enabling code reuse through class relationships. To grasp its essence, consider how we build software components: when implementing a container class, we might first create a basic push_back operation. Later, when implementing insert, we discover that push_back essentially performs an insertion at the end. Instead of reimplementing the logic, we can reuse the insert functionality within push_back. This principle of reuse extends to class design through inheritance.

When should inheritance be applied? A practical guideline is the "is-a" relationship: if one class represents a specialized version of another, inheritance becomes appropriate. For instance, a Student is a Person, and a Teacher is also a Person. In such scenarios, the specialized classes (derived classes) inherit the common characteristics from the general class (base class).

class Person {
public:
    void DisplayInfo() {
        cout << "Name: " << _name << endl;
        cout << "Age: " << _age << endl;
    }

protected:
    string _name = "alex";
    int _age = 25;
};

class Undergraduate : public Person {
protected:
    int _studentId;
};

class Instructor : public Person {
protected:
    int _facultyId;
};

The Person class contains attributes and behaviors common to all people. These members are inherited by both Undergraduate and Instructor, allowing us to extend functionality while reusing existing code. Inheritance enables us to build upon existing classes without modifying them, making our code more maintainable and extensible.

Syntax and Inheritance Modes

The syntax for inheritence follows a straightforward pattern: the derived class name appears first, followed by an access specifier, and then the base class name. The access specifier determines how base class members are accessible in the derived class and its instances.

class DerivedClass : access_specifier BaseClass {
    // Derived class members
};

Access Control in Inheritance

The relationship between base class member access and inheritance mode creates different accessibility levels for derived classes:

Private members of the base class remain inaccessible in derived classes regardless of the inheritance mode. This restriction exists because private members are inherently tied to their declaring class's encapsulation. Think of it as a contract: some aspects of the base class are implementation details that should not be exposed or modified through inheritance.

Protected members occupy a special position in inheritance. They remain inaccessible outside the class hierarchy but are accessible within derived classes. This makes protected ideal for members that derived classes need to access or modify while preventing external code from directly manipulating them.

class Base {
public:
    int publicData;
protected:
    int protectedData;
private:
    int privateData;
};

class PublicDerived : public Base {
    void AccessMembers() {
        publicData = 10;    // Accessible: public in base → public in derived
        protectedData = 20; // Accessible: protected in base → protected in derived
        // privateData = 30; // Error: private members never accessible
    }
};

class ProtectedDerived : protected Base {
    void AccessMembers() {
        publicData = 10;    // Accessible: public in base → protected in derived
        protectedData = 20; // Accessible: protected in base → protected in derived
    }
};

class PrivateDerived : private Base {
    void AccessMembers() {
        publicData = 10;    // Accessible: public in base → private in derived
        protectedData = 20; // Accessible: protected in base → private in derived
    }
};

A useful mnemonic for determining member accessibility in derived classes is: Min(base_member_access, inheritance_mode), where public > protected > private. Public inheritance preserves the base class's access specifiers, protected inheritance reduces accessibility by at least one level, and private inheritance effectively makes all inherited members private.

Default inheritance behavior depends on the type declaration: class declarations use private inheritance by default, while struct declarations use public inheritance by default. Explicitly specifying the inheritance mode improves code clarity and prevents accidental access restriction.

In practice, public inheritance dominates real-world applications. Protected and private inheritance serve niche scenarios where you want to restrict the derived class's interface or create implementation inheritance without exposing the base class relationship publicly.

Assignment Compatibility Between Base and Derived Classes

C++ establishes specific rules governing conversions between base and derived class objects, references, and pointers. These rules reflect the "is-a" relationship: a derived class object contains all the members of a base class, so it can be treated as a base class instance in many contexts.

class Contact {
protected:
    string _fullName;
    string _phoneNumber;
    string _identification;
};

class Researcher : public Contact {
public:
    int _badgeNumber;
};

void DemonstrateConversions() {
    Researcher scholar;

    // Derived-to-base conversions: allowed
    Contact basicInfo = scholar;           // Object slicing: copies base portion
    Contact* basePtr = &scholar;           // Pointer to base addresses derived object
    Contact& baseRef = scholar;            // Reference to base binds to derived object

    // Base-to-derived conversions: not allowed without explicit casting
    // scholar = basicInfo;              // Error: cannot assign base to derived
    // Researcher* derivedPtr = &basicInfo; // Error: base pointer cannot point to base object

    // Safe downcast with checking
    Contact* ptr1 = &scholar;
    Researcher* researchPtr1 = static_cast<Researcher*>(ptr1);
    researchPtr1->_badgeNumber = 1001;

    // Dangerous downcast: base pointer pointing to base object
    Contact baseObj;
    Contact* ptr2 = &baseObj;
    Researcher* researchPtr2 = static_cast<Researcher*>(ptr2); // Undefined behavior
    researchPtr2->_badgeNumber = 2002;
}

Understanding these conversion rules is crucial for writting safe polymorphic code. Object slicing—the automatic copying of only the base portion during assignment—can lead to unintended data loss. When working with pointers and references, always verify the actual object type before performing downcasts to prevent undefined behavior.

Scope and Name Hiding in Inheritance

Each class maintains its own scope, and this principle extends to inheritance hierarchies. When a derived class defines a member with the same name as a base class member, name hiding occurs. The derived class member "hides" the base class member, making the base version inaccessible without explicit scope resolution.

Hidden Member Variables

class Employee {
protected:
    string _name = "john_doe";
    int _identifier = 11111;
};

class Manager : public Employee {
public:
    void ShowDetails() {
        cout << "Name: " << _name << endl;

        // _identifier here refers to Manager's member
        cout << "ID: " << _identifier << endl;          // Manager's _identifier (99999)
        cout << "Base ID: " << Employee::_identifier << endl; // Explicit base access
    }

protected:
    int _identifier = 99999;
};

Hidden Member Functions

Function hiding requires only matching function names; parameter differences do not create overloads across scopes. This behavior differs from regular function overloading, which occurs within the same scope.

class Configuration {
public:
    void Setup() {
        cout << "Default configuration" << endl;
    }
};

class AdvancedConfig : public Configuration {
public:
    void Setup(const string& profile) {
        cout << "Configuration profile: " << profile << endl;
    }
};

void DemonstrateHiding() {
    AdvancedConfig adv;

    // The base class Setup() is hidden; this calls the derived version
    adv.Setup("high_performance"); 

    // To access the hidden base version, use scope resolution
    adv.Configuration::Setup();
}

Name hiding in inheritance can lead to subtle bugs, especially when derived class developers are unaware of base class members with similar names. Best practice involves carefully reviewing base class interfaces when deriving new classes and considering alternative designs when name conflicts seem likely.

Default Member Functions in Derived Classes

The compiler generates default versions of special member functions when not explicitly defined. In inheritance hierarchies, these functions interact with base class components in specific ways that developers must understand.

Constructors

Derived class constructors must initialize base class members through base class constructors. The base class constructor executes before derived class members are initialized, reflecting the "base-first" construction order.

class Individual {
public:
    Individual(const char* name = "michael")
        : _fullName(name) {
        cout << "Individual constructor" << endl;
    }

    Individual(const Individual& original)
        : _fullName(original._fullName) {
        cout << "Individual copy constructor" << endl;
    }

    Individual& operator=(const Individual& source) {
        cout << "Individual assignment operator" << endl;
        if (this != &source) {
            _fullName = source._fullName;
        }
        return *this;
    }

    ~Individual() {
        cout << "Individual destructor" << endl;
    }

protected:
    string _fullName;
};

class Scholar : public Individual {
public:
    Scholar(const char* name, int badge)
        : Individual(name)         // Base constructor must be called explicitly
        , _badgeNumber(badge) {
        cout << "Scholar constructor" << endl;
    }

    Scholar(const Scholar& other)
        : Individual(other)        // Base copy constructor
        , _badgeNumber(other._badgeNumber) {
        cout << "Scholar copy constructor" << endl;
    }

    Scholar& operator=(const Scholar& source) {
        cout << "Scholar assignment operator" << endl;
        if (this != &source) {
            Individual::operator=(source);  // Base assignment
            _badgeNumber = source._badgeNumber;
        }
        return *this;
    }

    ~Scholar() {
        cout << "Scholar destructor" << endl;
    }

private:
    int _badgeNumber;
};

Destructor Considerations

Destructors in inheritance hierarchies execute in reverse order of construction: derived class destructors run first, followed by base class destructors. This automatic chainning ensures proper cleanup regardless of how the object is destroyed. The compiler transforms all destructor names to a统一 identifier, creating a hidden relationship between base and derived destructors.

void ConstructionSequence() {
    cout << "Creating scholar..." << endl;
    Scholar s("sarah", 54321);
    cout << "\nCopying scholar..." << endl;
    Scholar copy = s;
    cout << "\nAssigning scholar..." << endl;
    copy = s;
    cout << "\nDestroying objects..." << endl;
}

Output demonstrates the construction and destruction order:

Creating scholar...
Individual constructor
Scholar constructor

Copying scholar...
Individual copy constructor
Scholar copy constructor

Assigning scholar...
Scholar assignment operator
Individual assignment operator

Destroying objects...
Scholar destructor
Individual destructor

Friend Relationships and Inheritance

Friendship is not inherited in C++. A function or class declared as a friend of the base class gains access only to the base class's private and protected members, not to those of derived classes. This behavior maintains encapsulation boundaries across the inheritance hierarchy.

class AdministrativeBase {
friend void ProcessRecords(AdministrativeBase&);
protected:
    string _department;
};

class AdministrativeOfficer : public AdministrativeBase {
friend void ProcessRecords(AdministrativeOfficer&);
protected:
    int _clearanceLevel;
};

void ProcessRecords(AdministrativeBase& admin) {
    // Can access AdministrativeBase protected members
    admin._department = "Finance";
    // Cannot access _clearanceLevel here
}

void ProcessRecords(AdministrativeOfficer& officer) {
    // Can access AdministrativeOfficer protected members
    officer._clearanceLevel = 5;
    officer._department = "Operations"; // From base via friendship
}

Static Members in Inheritance

When a base class declares a static member, that member is shared across the entire inheritance hierarchy. Regardless of how many derived classes exist, only one instance of the static member exists, accessible through any class in the hierarchy using scope resolution.

class Institution {
public:
    static int _institutionCode;
    static void ShowInfo() {
        cout << "Institution code: " << _institutionCode << endl;
    }
};

int Institution::_institutionCode = 1000;

class AcademicDepartment : public Institution {
    // Shares Institution::_institutionCode
};

class ResearchDivision : public Institution {
    // Shares the same _institutionCode
};

void DemonstrateStatic() {
    Institution::_institutionCode = 2000;
    AcademicDepartment::_institutionCode = 3000;
    ResearchDivision::ShowInfo();  // Outputs: 3000
}

Virtual Inheritance

Multiple inheritance introduces complexity, particularly when derived classes share a common base class through different paths. The diamond problem exemplifies these challenges: ambiguity arises when accessing members present in the shared base, and unnecessary data duplication occurs.

class Person {
public:
    string _name;
};

class Professor : virtual public Person {
public:
    int _facultyId;
};

class Administrator : virtual public Person {
public:
    int _adminCode;
};

class DepartmentHead : public Professor, public Administrator {
public:
    string _department;
};

void DemonstrateVirtualInheritance() {
    DepartmentHead leader;

    // Without virtual inheritance, this would require:
    // leader.Professor::_name = "Dr. Smith";
    // leader.Administrator::_name = "Dr. Smith";

    // With virtual inheritance, unambiguous access
    leader._name = "Dr. Smith";
    leader.Professor::_name = "Dr. Smith";  // Also valid
    leader.Administrator::_name = "Dr. Smith"; // Also valid

    // Both point to the same _name member
    cout << (leader.Professor::_name == leader.Administrator::_name) << endl; // true
}

Virtual inheritance modifies the inheritance structure so that the shared base class subobject appears only once in the most-derived class. Implementation typically involves virtual base table pointers that store offsets to the shared base subobject, enabling derived classes to locate the virtual base regardless of their position in the inheritance hierarchy.

Virtual inheritance carries runtime and memory overhead, so its use should be limited to situations where diamond inheritance is unavoidable. The C++ standard library provides examples of appropriate virtual inheritance use, such as in the iostream hierarchy where ios_base serves as a virtual base.

Design Considerations: Inheritance versus Composition

Choosing between inheritance and composition significantly impacts code maintainability and extensibility. Public inheritance establishes an "is-a" relationship: every derived class instance is fundamentally a base class instance. Composition establishes a "has-a" relationship: objects contain instances of other classes as components.

// Inheritance: is-a relationship
class Engine { /* ... */ };
class ElectricVehicle : public Engine { /* ElectricVehicle is an Engine */ };

// Composition: has-a relationship
class BatteryPack {
    int _capacity;
};
class ElectricVehicle {
    BatteryPack _powerSource;  // ElectricVehicle has a BatteryPack
};

Composition generally offers superior design characteristics: reduced coupling between components, greater flexibility in runtime behavior, and easier testing through dependency injection. Inheritance creates tight coupling between base and derived classes, making changes to base classes potentially disruptive to all derived classes.

The principle "favor composition over inheritance" suggests starting with composition and introducing inheritance only when the "is-a" relationship genuinely applies. When every derived class truly is a specialized version of the base class, and the base class's interface matches the derived class's interface, inheritance provides appropriate modeling power.

Consider the trade-offs: inheritance enables polymorphism through virtual functions, allowing runtime dispatch based on actual object types. Composition achieves similar flexibility through interface segregation and dependency injection patterns, often with better maintainability outcomes.