Chapter 5: Vocabulary: Words toThink With

Overview

Language shapes our ability to think. Words provide us with representations of particular thoughts and offer a mechanism for communicating thoughts among ourselves . The richness, variability, and subtlety of our thoughts are reflected in the size of our vocabulary. When we discover new things, we invent (or borrow ) new words to express our discovery. When we want to make critical distinctions between or among similar notions, we use specialized vocabularies. The use of special vocabularies is common in our professional lives because, as specialists, we need to become familiar with unique ideas and to make important distinctions that as laypersons we might not make.

Object-oriented development has its own specialized vocabulary for all of the aforementioned reasons. The unique vocabulary of objects has another important purpose: to differentiate object concepts from traditional software concepts that on the surface appear to be similar. Object vocabulary is deliberately different and is focused on communicating object thinking. To ignore the vocabulary or to trivialize the differences between object and traditional terms is to make a significant error.

Perhaps the most asked question in an introductory object class is some variation of, What is the difference between a (class, method, message) and a (module, function, procedure call)?

In one sense, this question can be answered only with, Nothing, there is no difference. Given this answer, the next question becomes, Why then do you use these silly new words? Underlying this question, of course, is the sneaking suspicion that the object advocate is a snake oil salesman trying to confuse the innocent customer with a fancy polysyllabic vocabulary.

Forward Thinking ”It s Not a Code Smell, But

Every time I look at this code, it seems strange ”but not strange , Jon comments to Samantha. It s pretty ordinary for the most part, but I have this constant nagging feeling that something is different ”not wrong, just different.

Not surprising, replies Samantha. This is probably your first real object-oriented project as well as your first XP project.

What do you mean? I ve been writing Java for several years ; doesn t that count as OO?

Not necessarily , because what you code is dependent on how you have thought about the problem space and how you have decomposed that space into objects. Just using a particular language doesn t mean you build objects; only object thinking about decomposition assures that you will build objects.

Huh?

Let me show you. Remember the ˜Serene Meditation story we worked on last week?

Yeah, our customer has some imagination when he writes story titles. ˜ Serene Meditation: The machine goes into a power-save mode until a potential customer triggers an induction field around the machine or calls the machine s published phone number. When its meditation is interrupted , the machine lights up, its selection menu is presented, and the money-accepting mechanisms are initiated.

Yeah, he does, but when we first wrote the code for that story you had two ˜controller objects, phone and inductionField , that tried to keep track of the other components and send them wake-up messages. When I pointed out the duplicated code, you quickly refactored into a single controller, but then you had to include a case statement to notify different objects depending on the actual source of the wake-up event. Only after we talked about MVC and using event dispatchers and event registration did we hit on the correct solution: let the machine , selectionMenu , coinAccepter , billAccepter , and cardAccepter objects register with the inductionField or phone object so that it s notified if it detects the unique event it s looking for. When we wrote the code, it didn t look radically different, but the organization of the code to form the methods was different.

And last week, we were working on the form object and had really different ideas of what its methods should be?

Yeah, I had a whole bunch of methods, mostly setters and getters for attributes. You had only three or four methods that you thought necessary. Turns out I was thinking about attributes all wrong.

Not all wrong, and according to some object theorists not wrong at all. When Coad and Yourdon published their first book on OO analysis, they defined objects and attributes as if they were standard data entities. Schlaer and Mellor, Rumbaugh, and a host of others did essentially the same thing. UML, which you used a lot before coming here, allows greater latitude in the definition of an attribute, but the base definition is still ˜a named characteristic with a value. You were still thinking of attributes as some characteristic of an object, the value of which the system had to remember.

So you were thinking of a form in terms of a lot of attributes: formNumber , dateCreated , lastRevisionDate , title, and so on. I was defining a form as an object that contained other objects, a collection, and an object that could identify itself, display itself (with help from the objects it contained), and describe itself.

Yeah, all the attributes I was listing ended up being inside a description object ”another kind of collection, kind of like a dictionary.

So you see, it s not the code that s different ”it s the objects and the distribution of methods across the set of objects that s different.

And the vocabulary is different too. I have to keep reminding myself that things such as functions and methods look essentially the same, but they derive from very different ideas. A method reflects a behavior expected in the domain, and a function reflects a unit of execution in the machine.

Got it! Now back to this ˜reorder product story.

 

The object difference is not readily apparent at the level of implementation. As noted earlier, once software is in the machine it s all ones and zeros. The difference is how we think about the problems and solutions. This difference is most manifest in how we do decomposition and how we decide to distribute responsibilities across a community of objects. A message and a function call might be identical, in syntax and in how they are implemented inside a machine. But who sends the message to whom, how that message is interpreted, and what kind of code will be necessary to respond will be quite different.

Object vocabulary is also different because of the underlying philosophy that motivates thinking in new terms and because we are employing different metaphors for what we are about and what we are building. Different philosophy + new metaphors = object vocabulary.

Note  

Object vocabulary is first and foremost a technique to help developers avoid the mistake of thinking about solutions using old mental habits.

Although numerous terms are employed in the discussion of objects, not all of them have the same degree of importance. Relatively few terms both need to be understood as fundamental and embody the majority of object philosophy. Other terms extend or elaborate aspects of essential terms and allow us to say other interesting things about objects or the way software objects might be implemented. Still another set of terms applies almost exclusively to software objects; these terms are a function of the implementation language selected for development. A fourth set consists of auxiliary terms. Table 5-1 lists the vocabulary terms in the four categories: essential, extension, implementation, and auxiliary.

Table 5-1: Categorized Object Vocabulary

Essential Terms	Extension Terms	Implementation Terms	Auxiliary Terms
Object Responsibility Message Protocol	Collaboration/collaborator Class Class hierarchy Abstract/concrete Inheritance Delegation Polymorphism Encapsulation Component Framework Pattern	Method Variable Dynamic binding	Domain Business requirement Business process reengineering (BPR) Application