The Open Minded Explorer’s Guide to Object Composition
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.
“Absorb what is useful, discard what is not. Add what is uniquely your own.” — Bruce Lee
JavaScript Supports Object Concatenation (aka Concatenative Inheritance)
With object concatenation, it’s possible to mix the properties of multiple component objects into the root of the new composite object. That looks like this:
import { a, b, c } from 'components';composedObject = Object.assign({}, a, b, c);
You don’t have to use `Object.assign()`. There are lots of ways to accomplish the goal, including stamps.
Object composition:
- the act of combining objects or properties to form a new object.
It doesn’t matter if you use aggregation, object nesting, or object concatenation. What matters is that you compose new objects from multiple component objects instead of inheriting a whole hierarchy in one big lump. The result of composing from smaller components is a composite object.
“Favor object composition over class inheritance.” ~ GoF “Design Patterns”
Now go make more flexible software with composition.
Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly), and “Learn JavaScript Universal App Development with Node, ES6, & React”. He has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more.
He spends most of his time in the San Francisco Bay Area with the most beautiful woman in the world.
