Answer.

Responsibility delegation through composition is a programming practice where an object of a class contains an object of another class (or classes) and uses them to implement part of its logic, instead of inheriting their interface.

Background

Early versions of OOP emphasized inheritance, but over time the practice showed that composition often provides greater flexibility, extensibility, and reduced coupling between components.

Problem

Inheritance tightly binds objects: changes in the base class affect all subclasses, hierarchies become complex, and architectural fragility arises. Composition alleviates these issues, allowing the construction of more reliable and maintainable systems.

Solution

In C++, delegation is implemented by including an object of one class as a member of another class. In the wrapper class, methods of the nested object are called.

Code example:

class Logger {
public:
    void log(const std::string& msg) {
        std::cout << msg << std::endl;
    }
};

class FileProcessor {
    Logger logger; // Composition
public:
    void process(const std::string& filename) {
        logger.log("Processing file: " + filename);
        // ...
    }
};

Key features:

Weaker coupling, flexibility
Ability to change the delegated object on the fly
Easier to test and maintain

Trick Questions.

Can composition completely replace inheritance?

No, inheritance is needed where the "is-a" relationship is required, composition is used when there is a "has-a" relationship. For example, Button inherits Widget, but Car "has" Engine (composition).

Can the behavior of the delegated method be changed in composition?

Yes, delegation methods can be adapted without touching the original class. You can also dynamically change the delegated object (for example, through a pointer or a unique pointer).

Is composition slower than inheritance?

No, there is usually no difference in performance. Sometimes inheritance adds overhead due to virtual calls (vtable), whereas composition only adds the object size.

Common Mistakes and Anti-Patterns

Using inheritance where composition would suffice
Overcomplicating composition with unnecessary nested objects
"Bloating" classes with many fragmented dependencies

Real-Life Example

Negative Case

In the project, all dialog windows inherited a common DialogWindow. Adding new business logic led to non-functioning code in all subclasses.

Pros:

Quick creation at the start
Code reuse

Cons:

Rigid structure
Any change affects the entire tree

Positive Case

Common functions are extracted into separate classes (logging, validation) which are injected into each dialog through composition.