ALL-CLAS1001 · inheritance_design
Judge whether inheritance is preferable to composition.
This is a contextual rule for all languages. Read its implementation.
Definition
Section titled “Definition”Judge one direct inheritance link from its resolved base and derived declarations and their
exact member source. Accept it as a subtype when the derived class preserves the base role, as
a focused mixin when the base contributes one narrow reusable role, or as framework
inheritance only when supplied names, decorators, and source establish that extension point.
Choose composition when the derived role is orthogonal to the base role and its declarations
use inherited members as implementation services. That mismatch is sufficient local evidence
and does not require proof about unseen clients. Use uncertain only when a specific missing
fact could distinguish two otherwise supported categories, and name that fact in the
reasoning.
Evidence
Section titled “Evidence”Findings cite the resolved inheritance link and the declarations that establish the verdict.
Exceptions
Section titled “Exceptions”Small protocol mixins and required framework base classes may be appropriate.
Examples
Section titled “Examples”CsvReport(Report) is a subtype when every client holding a Report can be handed one.
A SalesReport inheriting from DatabaseClient and calling its inherited query helper is
composition, since the derived domain role is not a kind of database client. A small
TimestampMixin contributing one method is a mixin, and a base a framework requires is
framework.
References
Section titled “References”- Cites “Fluent Python”, Inheritance For Better or For Worse
- Cites “Design Patterns”, favor object composition over class inheritance
- Cites “Refactoring”, Replace Superclass with Delegate