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 related processes are required.

Let s express the metaphor as a dictum: software should be assembled from a finite set of composable units the way that dinosaurs and castles and spaceships are constructed from a common set of Lego bricks . It is no accident that the first special issue of the Communications of the ACM devoted to objects had a cover photo of stacked red and yellow Legos.

On its face, this seems to be a restatement of Brad Cox s software IC metaphor. But there are depths and nuances to this metaphor that are missing from the simpler software IC idea. Like Cox s metaphor, this one tells us that we should be able to construct an arbitrary number of software artifacts from a finite set of standard parts. This is a characteristic of many other aspects of nature as well as of mass-produced products. For example, the world around us is constructed from a very finite set of parts ” atoms of the periodic table or, below them, quarks ” especially given the variety and complexity of the things manifest in the world. Houses are constructed from two-by-fours, nails , 4-by-8- foot sheets of plywood, and so forth. Even societies are built from butchers, bakers, and candlestick makers .

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 valuable . Given that developers have pursued the dream of reusable code libraries from the very advent of computing ”with very limited success ”a way to actually accomplish that goal would be invaluable.

Note  

Almost all software development has focused on a very limited concept of reuse instead of the composability implicit in the axiom of Witt, et al. and Plato s philosophy of taking apart and putting together again. Some would claim that the industry track record with reusable libraries, class libraries, components , and widget libraries suggests that reuse across contexts is impossible . At issue, however, is not the possibility of composability but the means of achieving it. Reuse efforts (as opposed to composability efforts, which have been almost nonexistent) have been characterized by a focus on the solution space ”computer code, algorithms, and data structures. True composability will require an understanding of the problem space ”of the natural world as advocated by object thinking. In Chapter 10, we will explore the issue of composability further in a discussion on the future of objects.

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

• Creators are (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 satisfy their needs.

• The component engineers need to be very concerned with 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 themselves with 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 operate in 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 tasks are as clearly separated as they are in the world of Legos.

Note  

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 user is a child ”a kind of ultimate consumer. In the case of objects and software, we are treating other programmers as users.

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 worlds , and not to programmers. The objects would have to be directly usable without the need to use programming environments and compilers. Each component would need to be a small executable program, modifiable via user messages, not modules of source code made available to programmers.

Another, critically important, aspect of the metaphor is the ability of users to successfully employ the bricks based solely on their intuitively obvious external characteristics. A child can look at a brick and instantly tell whether it is suitable for inclusion in the project at hand. It is not necessary to know anything about the chemistry of plastics or whether this particular brick was made at Sun BuildingBlock Corporation or Microsoft BuildingBlock Corporation. There is no need to read a complex user manual that explains either the brick or how to use it. There are, however, patterns: diagrams suggesting proven ways that you can construct a family of similar artifacts ”houses, for example.

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 group being adults and the other children, might lead one to believe that the metaphor de-skills the task of application assembly ”after all, it can be done by children (or end users, perhaps). This would be a misleading conclusion.

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 architects and designers to use the same bricks to create various structures, which are then sold as part of a charity auction.

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.

Note  

Following up the immediately preceding note, perhaps the users of objects would not have to be the ultimate end user but could be a new kind of professional assembler or collage artist, with a set of skills not available to the end user but quite different from those required by traditional programmers and software developers. The demand that objects be run-time modifiable executable programs would not change.

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 considered true Legos.) There are only 134 elements and only six quanta. The vast majority of houses in this country are built with fewer than 10 standard sizes of dimension lumber. In all of those cases as well, the base elements are simple and highly specialized.

How Many Objects?

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 translates into about 110,000 classes. A pretty large number but clearly finite.

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 liberal ability to add classes representing objects that do not make the paper, we still come up with fewer than a thousand classes to model all typical domains of human interest.

If your problem domain ”or worse , your application ”has thousands of classes (and I have seen some), you probably have yet to master object thinking.

 

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 convenient to build a large construct from small, but not the smallest possible, components. It s easier to build living things with hydrocarbon molecules than directly with individual atoms. It s easier to build a roof with a truss made of standard-dimension lumber and gang nails than a board and a nail at a time. Intermediate constructs, such as trusses used to build houses, are components. The number of components will be much larger than the number of objects from which those components are constructed. Moreover, they will likely reflect stylistic differences reflective of the designers and potential users of such components.

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 prototypes fail to meet satisfaction criteria and so are taken apart and reassembled in another attempt to reach the envisaged goal.

XP development closely resembles playing with Lego bricks in the sense that it too allows discovery and emergent solutions, tolerates and leverages mistakes, encourages taking things apart and reassembling them into more elegant solutions (refactoring), and relies heavily on feedback as to the extent to which the current assembly meets user expectations.

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 superior to, in this regard, compile-link-test environments such as C++ (even Visual C++ with incremental compilation). This notion would seem to be borne out in experience. It typically takes about half as long to develop an application with Smalltalk as with C++, given equivalent levels of skill in the developers, even with current incremental compilers. Even advocates of languages such as C++ will tend to concede the speed-of-development issue and focus instead on characteristics-of-product issues such as speed of execution.