Home > Articles > Software Development & Management > Object Technology

Object Think: A Perspective on Objects

📄 Contents

  1. Processing with Object Think
  2. Objects Doing
  3. Object Services
  • Print
  • + Share This
The object think perspective says objects act rather than get acted on, and conduct their own business rather than hold data for functional processing. Mike Abney uses a real-world example (peanut butter and jelly!) in this article, excerpted from his book Streamlined Object Modeling: Patterns, Rules, and Implementation.
This chapter is from the book

There's Something About Peanut Butter

Try this. Ask a few people how to make a peanut-butter-and-jelly sandwich. See how differently they answer. One person spreads the peanut butter first with a knife; then uses a spoon for the jelly. Another spreads the jelly first, always on the left slice of bread, which goes on top. A third puts the peanut butter slice on top; then slices it up into squares. Clearly, everyone has their own personal preferences—"how I like to do it"—for making peanut butter and jelly sandwiches. Build an object model of sandwich-making from these accounts, and it will focus on knifes, spoons, and handling bread slices.

Now consider another approach. Ask the same group to talk about a peanut-butter-and-jelly sandwich. Ask them to think about the parts of the sandwich. They will tell you that there are two slices of bread, peanut butter, and jelly. Ask them to list all the different varieties of bread, of peanut butter, and of jelly. They will tell you that there are wheat bread, white bread, bagels, and croissants; plain peanut butter and crunchy; grape jelly, apple jelly, strawberry jam, and so on. Ask if any varieties are taboo. Perhaps that orange marmalade with Teacher's Scotch is too overpowering for a peanut-butter-and-jelly sandwich, and that old-fashioned peanut butter with the oil floating on top is too messy.

Look for collaboration constraints: no chunky peanut butter on thin diet bread; never less than one ounce of jelly, nor more than three; a slice must have either jelly or peanut butter, but not both; a sandwich requires exactly two slices of the same type of bread; one slice must be spread with peanut butter and the other slice spread with jelly.

Think about personalizing the sandwich: slicing off the crusts, toasting the bread, cutting the sandwich, or flipping it to put either the jelly or peanut butter on top.

What a difference the point of view makes! By asking people to think about a sandwich and not their personal experiences making a sandwich, you open up their minds to many more possibilities.

Objective versus Subjective Descriptions

The peanut-butter-and-jelly sandwich example highlights the difference between asking people to describe a process and asking people to describe objects involved in a process. When asked to describe a process, people naturally describe it subjectively, in terms of "how I would do it," step-by-step. Some even detail imaginary interactions with a computer system, speaking in terms of "how I see the system," and focusing on "my favorite features." Right off the bat, you should notice that these user-centric process descriptions focus on "how" and not "what." Business requirements from "how" are only good as long as the "how" does not change, or until someone else wants a different "how." Business requirements from "what" can support all manners of "how" because the focus is on the people, places, things, and events that happen in the process; not a particular order in which they appear in the process.

Another thing you should notice about user-centric process descriptions is that each one reflects the speaker's unique experiences, biases, and point of view. Business requirements derived from individual experiences are difficult to verify as complete because it is possible that not all points of view were covered. Business requirements derived by discussing the people, places, things, and events are complete when all these types of objects are described and their involvements in the processes are modeled. It is neither a coincidence nor a pun to say that the trick to being objective is to talk about objects. Focusing on objects takes the inward-looking personal perspective out of the requirements gathering, and replaces it with an outward-looking perspective; the requirements-gathering session becomes more about reaching consensus than asserting will. User interactions are extremely useful, but only after the object model is built—when the vocabulary is established and "what" is clearly defined.

Be Objective with Processes

Be objective when asking about processes. Talk instead about the objects—people, places, things, and events—involved in the process and the actions on these objects, rather than asking clients how they "want to do it."

  • + Share This
  • 🔖 Save To Your Account