Chapter 9: All the World s aStage

Overview

Chapters 7 and 8 focused on individual objects and problem domains. The discussion focused on discovering ”identifying ”the objects that already exist in a domain and understanding what is expected of them in that domain. The focus was on an entire domain ”either an enterprise (Woodgrove Bank) or an area of commerce (banking industry) as a whole ”to avoid defining objects in terms of their idiosyncratic behavior in narrowly defined applications.

Our goal of object discovery was facilitated by telling specific stories about small groups of objects engaged in resolving specific problems or, collectively, providing a specific service. We did this to illustrate , to explore, and to discover the intrinsic capabilities and expectations of that object. No single story defined the nature of an object. The set of stories we used to discover and model objects was broad enough in scope to ensure a proper balance of specificity and generality: specificity so that the objects could be built and built simply; generality to ensure that the same objects could be used in multiple contexts without modifying their essential nature.

A number of concerns that typically arise in software development were not mentioned or were mentioned but set aside for later discussion. Deferred issues fall into four broad categories:

• Static relationships, associations, affiliations, compositions, and interaction channels that are assumed to be, but seldom are, permanent

• Scripting, providing the cues to be used by a collection of objects while completing specific collective tasks

• Constraints, keeping objects from doing things that they are capable of but that we want to prevent in certain circumstances

• Implementation, providing detailed information about the inside of our objects; algorithms to be used and detailed specifications about formats and values of information

The first three categories were deferred because they do not inform us about objects, only about contexts in which objects must operate . Implementation issues are deferred in accordance with the long-standing development rule, Figure out what must be done before you concern yourself with how it is done.

We are also being consistent with the Lego brick metaphor: separating the problem of creating bricks from the problem of building things with bricks. To reintroduce another metaphor, we separated our discussion of actors and their intrinsic talent from the discussions of casting, screenplays, and direction. Our goal was to create actors (objects) with the versatility required to assume many different roles in a wide variety of genres and to avoid creating objects that were typecast ”doomed to play the same role, in the same screenplay, over and over again.

Generally, we do not try to solve all the problems of the world in one fell swoop. Instead, we arbitrarily set a boundary that delineates our focus and separates it from the rest of the universe. We call this bounded space our system, or our application, or our program, or our object. Unfortunately, we also tend to be a bit sloppy in our use of terminology and frequently use the terms application , system , and program more or less interchangeably. In the rest of this section, I will use the term application as a label for the domain and our artificially bounded portion of that domain and the term application artifact for specific instances of executing code ”programs or objects. (To see the difference between application and application artifact , see the sidebar Systems and Artifacts. )

Systems and Artifacts

Structured analysis was, in its own time, a new paradigm for software development. As popularized by Larry Constantine, Ed Yourdon, and Meillor Page-Jones, an initial task was the creation of a model of the existing system. Developers were instructed to create a model ”data flow diagrams, entity relation diagrams, context diagrams, and even program structure charts ”to document their understanding of how things were currently done. This effort was supposed to facilitate understanding and modeling of a new system to replace the existing one. In practice, this step was seldom completed: its value was not understood , and its cost was significant. Later editions of books on structured analysis tended to eliminate this step altogether.

Modeling the existing system has a parallel in object thinking: domain-centric analysis. There is an implicit assertion in both: you cannot begin to understand what must be until you understand what is. This assertion has two corollaries:

• Almost all of the objects you will ever need are already defined, and already have behavioral expectations associated with them, in the domain.

• Almost all of the requirements of new development arise from a misalignment of behaviors and objects. Misalignment results when the wrong object (or group of objects) is providing a particular service, a service is more appropriately provided by a silicon-based object simulation instead of a carbon-based biological object, or, occasionally, no existing object is capable of providing the needed service.

Christopher Alexander ( Notes on the Synthesis of Form ) offers another expression of the need to understand the problem and the problem (domain) space in detail before proceeding with development. Design, according to Alexander, is the process of adapting a solution to a problem. The problem defines the needed solution, and understanding the problem therefore reveals the required solution.

Object thinking and structured analysis share a common belief that the existing system must be understood before one proceeds with development. They differ , however, in a very significant way. Structured thinkers, like software engineers , tend to think of the system in terms of a bounded artifact, a piece of software executing on hardware. Object thinkers view the system as The System : the complex whole of the domain and all its parts (objects), explicitly including all the human objects and all of the patterned interactions of those objects. It is this System that we seek to understand before attempting to intervene with any development project.

Understanding an entire System is seemingly a daunting task, one reason why most software engineering texts suggest a much narrower focus. Paradoxically, expanding our focus actually provides significant benefits and has the effect of simplifying our work. The dictum Everything is an object provides us with a single metaphor/model and a means of partitioning even the most complex domain into a relatively small number of objects with easily understood behaviors.

This perspective also has the effect of redefining what is meant by artifact and application as those terms are used in development projects. Artifacts are objects or methods ”nothing more. Applications are simply scripted assemblies of objects, some objects being software simulations, others being physical entities, and still others being human roles.

A side effect of this perspective is a kind of minimal-intervention principle. Recognizing that introducing any change into a complex system will have widespread, frequently unforeseen, and too often deleterious consequences, we seek to minimize those effects by making the smallest possible change. Examples of applying the minimal-intervention principle include introducing a single new object, adding a new behavior to an existing object, reassigning a behavior from one object to another, simulating as faithfully as possible an existing object with software, and assembling and scripting the least number of objects necessary to fulfill a single story, as XP defines user stories.

 

We do need to understand more about the application ”the context in which our objects will perform and the precise tasks we expect our objects to perform ”before proceeding with development. Specifically, we need to determine the relationships, constraints, and interactions that will be required of our objects in each specific circumstance. (Although we might discover new things about our objects while engaged in our study of the application and might be required to modify the intrinsic nature of our objects as a result, it s a major mistake, from an object thinking perspective, to define objects in terms of an application instead of a domain.)