For the gawkers, I added some clarifications:
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.
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 more broad definition of composition as it applies to modeling data structures in various forms.
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.
People today with shorter memories don’t realize this, but I’m not redefining composition. For many, The GoF did.
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 newer understanding 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 exact, pedantic, classical 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