Different people seem to have different definitions of object composition. Let’s explore some ideas and figure out how this happened:

composition: [kom-puh-zish-uh n]

the act of combining parts or elements to form a whole.

By extension…

object composition:

the act of combining objects or properties to form a new object.

Makes sense, so why are people getting lost? Enter Wikipedia:

Wikipedia’s definition

object composition (not to be confused with function composition) is a way to combine simple objects or data types into more complex ones.

Here’s where people get confused. Wikipedia goes on to describe a specific method of modeling composite objects, where the newly composed object creates a nested tree structure with component objects as separate branches. That looks something like this:

import { a, b, c } from 'components'; composedObject = {

a: a,

b: b,

c: c

};

In this example, each component gets its own property. So where does Wikipedia get that? It’s essentially the composite pattern from the Gang of Four’s “Design Patterns” book, which is the canonical reference for OO design patterns. The composite pattern is one of several compositional design patterns, which also include aggregates, the strategy pattern, and so on…

The composite pattern is what lots of classical OO people think of when they think of object composition — but that’s not really a complete understanding.

Object nesting isn’t the definitive, salient feature of object composition.

In Java, this is the easiest way to create a composite object. That probably explains why it’s modeled that way in the GoF book, and it’s probably good enough to end your understanding of composition here if you only code in Java.

However, composite objects existed long before Java and the GoF, and that is not the only way to create a composite object in JavaScript.

The Brown Mouse Fallacy

Some people argue that different forms of object composition can’t be object composition because they don’t create object structures where components become self-contained child properties.

Imagine if the first time you saw a mouse, it was a brown mouse, and then somebody introduces you to a white mouse, but you argue that it can’t be a mouse because it’s not brown.

In other words, positive premises can’t lead to negative conclusions.

Prior Art

Since many people think that the GoF invented (and thus defined) composition, some prior art:

“Reliable Software Through Composit Design” by Glenford J Myers, 1975

“Programming Languages and Their Definition: Selected Papers” by H. Bekic, C. B. Jones, 1984

“The C Programming Language: Including Ansi C, Portability, and Software Engineering” by Douglas A. Troy, Jams D. Kiper, 1989

All (and many more besides) use a much broader definition of composition as it applies to modeling data structures in various forms.

The classic example of data structure composition that predates the popular adoption of OOP is the C language `struct`, which shares important features in common with objects in JavaScript. It’s referenced as a composite data type in dozens of books that predate “Design Patterns”.

Composite structures and composition in the context of building complex data structures from simple data structures was part of the popular programming language jargon decades before “Design Patterns” was a twinkle in the eyes of the GoF.

How do I know all this? I was programming for years before “Design Patterns” was released, and I remember it. I saw the white mice before the GoF ever introduced me to the brown mouse.

The composite pattern understanding of composition introduces a feature of composition that isn’t particularly relevant for the majority of practical use cases in JavaScript:

Object nesting isn’t the definitive, salient feature of object composition.

The act of combining component pieces to form a new object is.

Even the GoF used composition in a broader sense, defining several compositional design patterns. Near the beginning of the book, where they introduce the famous quote, “favor object composition over class inheritance”, they weren’t specifically referring to the composite pattern where this misunderstanding of composition was born, they were referring to whatever compositional design pattern is right for the problem at hand.

They were arguing for flexibility over strict hierarchical taxonomies. To think otherwise is completely missing the point.

Clinging to some narrow, infrequently required, Java-oriented understanding of object composition is not going to make you a better programmer. Favoring flexibility over rigid hierarchy will.