Composition
Composition is the design style where one object owns or holds other objects as parts and delegates work to them to form the larger behavior. The important shift is that reuse happens through collaboration rather than through parent-child hierarchy.
βΆArchitecture Diagram
π StructureDashed line animations indicate the flow direction of data or requests
When inheritance becomes the only reuse tool, classes stay attached to parent internals just to gain shared behavior. That creates deep hierarchies where a small parent change can shake distant children.
Object-oriented practice repeatedly discovered that inheritance-heavy designs were often more fragile than expected. After the GoF era, the design instinct shifted toward preferring composition for many reuse problems because it offers more flexible assembly.
In composition, the higher-level object keeps collaborators as fields. When it receives a request, it coordinates the overall flow and delegates focused tasks to the appropriate collaborators, combining their results into the final behavior.
Composition and inheritance both address reuse, but composition keeps collaborators replaceable and separately owned, while inheritance reuses behavior by binding children directly to parent structure. Composition is usually the looser and more adaptable option.
Composition works especially well in service layers, policy objects, strategy objects, and widget trees where you want to divide responsibilities into replaceable parts. If objects are split too aggressively, however, the runtime flow can become difficult to follow because behavior is scattered across too many collaborators.