The Lego Brick Metaphor
Our first metaphor helps us think of important object characteristics, such as composability, simple interfaces, and comprehensibility (limited number of forms). It also illuminates important aspects of the object-oriented software development process, most notably the fact that two distinct but
Let s express the metaphor as a dictum:
software should be
On its face, this seems to be a restatement of Brad Cox s software IC metaphor. But there are depths and
By focusing on the composable nature of Lego bricks, the metaphor reminds us of how object thinking views the importance of decomposition and composition. (Remember Plato s views, quoted earlier in this book.) The metaphor also reminds us of the importance of composability across contexts, a generalization of the concept of reuse. Removing a Lego brick from a dinosaur and using it to shore up the antenna on your space station is an example of composability (reuse) across contexts.
More important, perhaps, the metaphor reminds us that simple and obvious interfaces are required if our objects are to be as composable and as useful as Lego bricks. (The standard physical dimensions of a Lego brick are but another aspect of its public interface.) Further exploration of the metaphor and its implications suggests ways to discover, design, and build truly reusable and composable objects. This alone would make the metaphor extremely
Almost all software development has focused on a very limited concept of reuse instead of the composability implicit in the
Exploration of the metaphor begins with considering what it implies about the development process: that there is a necessary separation between the process required to create objects (Lego bricks) and the process of assembling those objects into useful products (software, in our case). The metaphor suggests that
Creatorsare (probably) adults working for the Lego Company.
Users are children (at least at heart), ages 4 to adult.
Creators have specific concerns and use specialized processes to accomplish their goals.
Users care little about the components, as components. Their concerns focus on what can be built with the components and the ability of the artifact to
engineersneed to be very concernedwith the internal structure of the bricks, what kind of plastics will yield the correct degree of malleability, colorfastness, friction to keep them together, spacing of the pips at the top of the brick, and so on. They also have to create components that transcend particular applications because their goal is to build bricks equally useful for dinosaur and spaceship construction. More important, they want bricks that can be used successfully by unknown end users to build whatever it is that they have imagined.
Users want to move easily from concept to construction without the need to concern
themselveswith technical details. They want rapid feedback, they want to be able to change their mind in mid-construction, and they want the artifact constructed to operatein their world as it is.
Applied to software, the metaphor suggests separation of domain decomposition and object definition from the tasks of assembling applications and solving specific operational problems. To some degree, with some implementation languages, this separation has started to occur. Consider the class libraries that come with a language such as Smalltalk or Visual Basic. Many of the classes (the collection and magnitude classes, for instance) in such libraries reflect the same kind of general and abstract thinking that leads to good software Legos. Another example of this separation is the attempt to create visual programming environments for application assembly that are at least quasi-independent of the underlying implementation language. Such attempts are but a start toward an object-mature world, where the two
I would like to bring to the reader s attention a nuance of this metaphor as something to think about without attempting to fully develop the idea. The metaphor suggests differentiation between users and creators that, in the case of the Lego brick, is very different from the similar distinction made in this book. A Lego
If we were to be completely consistent with the Lego metaphor, we would have to argue in favor of delivering objects to end users, those filling roles in business and organizational
Another, critically important, aspect of the metaphor is the ability of users to successfully
Software objects cannot even approximate this degree of composability, but the metaphor suggests that full realization of object potential requires satisfaction of this characteristic.
The fact that two different groups of people, and two different processes, are involved in brick creation and artifact assembly, one
The Legoland store in the Mall of America periodically sponsors two events. (Located in Bloomington, Minnesota, the MOA is the largest shopping mall in the United States.) In the first event, children are invited to use the unlimited set of bricks at hand to construct various things. Prizes are given to the best constructions. The second invites professional
As should be expected, there was a large qualitative difference between the constructions of the architects and those of the children. The building bricks remained the same. The architects, however, were able to bring to bear other skills ”proportion, geometry, aesthetics, and so on ”that the children did not yet possess. The architects were domain experts (end users) who were able to use the bricks to build solutions that fully exploited their domain knowledge. They were able to use the Lego bricks to simulate the way they wielded girders and bricks in the real-world domain where they worked.
Following up the immediately
Two other items suggested by the metaphor are related. Objects should be simple, and there should be relatively few of them. There are fewer than 10 basic Lego brick types. (Kits contain additional parts, each of which is highly specialized, such as tiny human figures and motors, but these cannot be
One of the heuristics for object discovery is Find the nouns. Each noun in a domain description is a potential object class. Estimating the minimal class set could involve a simple count of nouns employed in a domain.
Expanding on this heuristic, how many classes would be required to model the universe? Well, how many nouns are required?
The Oxford English Dictionary has about 550,000 words. An English teacher once told me that about 40 to 45 percent of the words in a dictionary will be nouns.
If we eliminate proper nouns and synonyms, that percentage will be reduced to around 25 to 30 percent of the words describing potential objects. Eliminating archaic nouns ”bodkin and amanuensis, for example ”will reduce the percentage still further, to 15 or 20, perhaps. This
Instead of the OED, however, a better estimate might be obtained using the vocabulary required to read the average daily newspaper. Most things are quite adequately described in a newspaper.
Vocabulary required to read a typical newspaper: about 1400 words!
Using the 30 percent estimate (we don t have archaic terms to eliminate, hopefully) suggests a need for only 420 classes. Allowing
If your problem domain ”or
This suggests that there are a similarly small number of objects from which we can construct any type of software needed to model any domain or organization. (See the sidebar How Many Objects? )
It s frequently
The last item suggested by the metaphor deals with process. Watching a child work with the bricks reveals a process of discovery filled with a certain amount of trial and error and supportive of rapid change as
XP development closely resembles playing with Lego bricks in the sense that it too allows discovery and emergent solutions, tolerates and
Both XP and the metaphor suggest a need for a development environment that supports this kind of development process model. Smalltalk and visual programming environments, such as Visual Studio, provide examples of development environments and tools that are