The Object-as-Person Metaphor


The Object-as-Person Metaphor

People are objects, and objects should be conceptualized as if they were people. Projecting human characteristics onto inanimate things is called anthropomorphization. Anthropomorphizing in a philosophy class might earn you a poor grade, but it s essential to a good understanding of objects.

Philippe Kahn starred in The World of Objects , a video he produced to illustrate object concepts. He used musicians, a specialized type of human being, to illustrate the anthropomorphization of objects. Mr. Kahn noted that he is capable of playing numerous instruments and splicing the results together to create a finished piece of music. Better results with less work, however, would be obtained by engaging a group of talented musicians ”each of whom was a specialist in some instrument or aspect of music. He could then communicate his desires to them, allowing them to respond to those desires using their innate skills, knowledge, and abilities . The musicians would be asked, at a relatively high level, for some service (asking the percussionist for some color , for example). They in turn would interpret (make sense of) those instructions in terms of their own abilities, experience, and even awareness of the context in which the request was made and then respond in an appropriate manner.

start sidebar
Behind the Quotes ”Philippe Kahn

Philippe Kahn is the founder of Borland International, once one of the largest software companies in the world and still a leader in the field of integrated development environments ( IDEs ), which combine programming language, editing, incremental compiling, debugging, and visual tools to simplify and speed software development.

Borland was an aggressive early adopter of object ideas for its own software development and enjoyed numerous early successes with object technology. Mr. Kahn left Borland, and the world of the PC, to concentrate on network applications as CEO of Starfish Software. His current work still reflects a commitment to object ideas.

end sidebar
 

The object-as-person metaphor tells us that an object needs to be an agent capable of providing a specified set of services. It has access to a body of knowledge (some of it internalized) that it uses to respond to our service requests as well as any necessary mechanisms (talents and skills) and resources (instruments, a computer, or whatever else it may need). It also tells us that the (only) appropriate way to determine whether an object will suit our needs is by a careful review of its interface (r sum ).

Applying this metaphor can feel a bit strange at first. What, for example, are the talents or skills possessed by a book? What services can or does it provide? What knowledge does it require to respond to requests for those services? What resources does it need? These appear to be hard or nonsensical questions to answer. But with some practice, a book is revealed as

  • A collection of page objects.

    • Working with those page objects, it maintains order (sequence).

  • An object capable of identifying itself.

  • An object that can describe itself.

    • The description is a separate object that can provide individual elements of the description, such as date published, author or authors, publisher, and so on.

  • An object that can provide the reader with access to a specific page or a group of pages (chapters) upon request (also in collaboration with the page or chapter objects).

  • An object that acts as a front for a community of objects (pages, tables of contents, indexes, chapters, and the like), allowing users of the community a convenient point of contact. Requests can be sent to the book, knowing that the book will relay those requests to the actual objects capable of responding, without interference.

  • At one point in its life (in the days when it was a mere unpublished manuscript), an object that was also able to add pages to and delete pages from its collection and still maintain the proper order.

If objects are similar to persons, they are limited in some of the same ways that human persons are limited. For example, they need to know certain things to complete an assigned task. When the book was young and still being composed (playing the role of manuscript), it might have been asked to add a page to its collection of pages. To do this, it would have needed to know the page to be added.

Like people, software objects are specialists. They are also lazy. A consequence of both these facts is the distribution of work across a group of objects. Take the job of adding a sentence to a page in a book. Granted, it might be quite proper to ask the book, Please replace the sentence on page 58 with the following. (The book object is kind of a spokesperson for all the objects that make up the book.) It would be quite improper, however, to expect the book itself to do the work assigned. If the book were to do that kind of work, it would have to know everything relevant about each page and page type that it might contain and how making a simple change might alter the appearance and the abilities of the page object. Plus the page might be offended if the book attempted to meddle with its internals.

The task is too hard (lazy object) and not the book s job (specialist object), so it delegates ”merely passes to the page object named #58 the requested change. It s the page object s responsibility to carry out the task. And it too might delegate any part of it that is hard ”to a string object perhaps.

Following these patterns, we let the book and the page do what each does  best and what is appropriate for each. If we need a service that requires a contribution from more than one object, either we assume responsibility for asking the objects for their individual contributions and assembling those results in a way that suits our purpose or we send the request to whichever object is acting as spokesperson for the group and allow it to delegate tasks and assemble responses in order to reply to our request.

The person metaphor guides our decomposition and our assignment of responsibilities to software objects that always reflect the demands of the domain, not their eventual implementation. Our software object should simulate the services provided by our real-world object, both of which we metaphorically regard as people. Even though it s true that we must be more precise in specifying our software object, it s critically important that we continue to use the real world and not the computer (implementation) world as the foundation for our conceptualization of the software object.

start sidebar
Forward Thinking ”Hey, Coach!

Hey, coach, Lori waved to Ron, who was playing the role of coach for the teams today, could you grab Hector [their on-site customer] and mediate a quick conversation about this ˜make selection story?

Sure thing, be right over.

Ron and Hector saunter up to Lori and Sally s work area. What s up?

Sally and I have been working on this ˜make selection story, and we think it might need to be broken up ”refactored. Either that or we are mis-thinking our objects. The story reads, ˜Allow the customer to make a selection from the available products, making sure that no expired products are sold and that sufficient funds are available to pay for the product selected.

We visualize this story going like this: 1) a selection object is created when a customer inserts money or a debit/credit card; 2) the selection object then monitors the console buttons for selection input; 3) when buttons are pushed , the selection object puts them together as a kind of key or index value and then asks the dispenser collection whether it has a dispenser matching that key and whether it is operational (its product has not expired and it is not empty); 4) the selection then asks the dispenser for the price of the product and the accumulator for the amount of money available; 5) if we get all yeses, we tell the dispenser to do its thing and give the customer the product. This seems to capture the story, but it will involve a lot of potential error-handling methods ”in case the dispenser doesn t exist or there are other problems.

Hector looked a bit puzzled. That seems to capture the story all right. I don t see any problem, but you are uncomfortable. Can you tell me why?

It just seems too complicated. The way we envisage building and testing this, it isn t simple enough.

Ron said, I think you have the story right, but you might want to consider involving some different objects, and you might want to assume that some of the things you are trying to do in this story are actually done at a different point in time. Check me on this, Hector, to make sure that we don t invalidate your story.

Your selection object is a good idea, but let s simplify it. It will be what Rebecca Wirfs-Brock and Alan McKean would call a structurer stereotype object ”that is, it will exist primarily to maintain a structural relationship: in this case, the parts of a selection. Some selections will have only one part, as with the soda machine: a selection is just a numbered button. For the candy machine, the parts are a letter and an integer. Your idea of having it constitute itself in response to a money-inserted event and button-pressed events is a good one.

But we will introduce another object ”a menu object. This will be a collection kind of object, and it will represent, or proxy, the dispenser collection. Visualize it like a two-dimensional table: column 1 is a key, and column 2 is a variable.

You remember variables ? An object that contains an object reference and a message to be sent to that object in order to change from an unknown to a known value?

Yes. Everyone agreed that they remembered what a variable object was.

OK, now ”assume that the menu is constantly updated whenever a dispenser is activated or deactivated and that, at the time when a selection is made, all you have to do is ask the menu whether it contains an entry at the key value that matches your selection object. If it does not, a message is sent to a userMessage object, which prompts the user for a different selection.

If the selection is included in the menu, we involve another object ”a dispenseRule object. This is probably a singleton object, and it lives in an instance variable of the vendingMachine object. Oh, and by the way, your selection probably lives in another instance variable of the vendingMachine while it is alive . The dispenseRule has registered with the   currentSelection variable (that is where your selection will live) to be notified if the object-in-residence (your selection object again) generates a selectionMade event. This is what will happen if the menu object confirms that you are a valid selection.

The dispense rule has two variables: one that sends a price message to the product at the front of the dispenser, or maybe to the dispenser itself, and a second one that sends the total message to the accumulator. It also has one operator, and that is less-than (or greater-than, depending on how you actually write your code to relate the two variables), and it evaluates to a Boolean true or false.

If dispenseRule evaluates to true, the product is dispensed. If not, another userMessage object is told to engage the customer in a dialog to resolve the situation.

Most of what I am suggesting is just moving responsibilities around among objects ”to simplify things for all concerned . But it does require another user story ”if Hector is agreeable ”called ˜update menu. That story will be executed whenever a dispenser changes its state.

No problem, Hector says. In fact, some kind of story of that type would probably have been written anyway. The boss and I were discussing how we can build machines that contain different products in each dispenser and have LEDs or icons or something appear on the face of the vending machine to cue the customer about what is available inside ”your menu, in essence. I ll write up the story, and we can bring it up at the next game-planning session.

That help you two? Ron asked Lori and Sally.

Absolutely. We ll have this done in no time with those simplifications . We ll just stub in the menu behaviors for now until that story and object are ready. Thanks, Ron, thanks, Hector.

end sidebar
 

We have said that objects have access to all of the resources necessary to do their jobs. In the case of a software object, this means that each object is assumed to have access to all of the resources of an arbitrarily complex computer system if necessary. This is one reason that Alan Kay calls objects intelligent virtual computers. Because we are conceptualizing each of our objects as possessing its own computer (virtual computer or thread), we have the foundation for concurrent or parallel processing systems. Objects, like the people we metaphorically equate them to, can work independently and concurrently on large-scale tasks, requiring only general coordination. When we ask an object collective to perform a task, it s important that we avoid micromanagement by imposing explicit control structures on those objects. You don t like to work for a boss who doesn t trust you and allow you to do your job, so why should your software objects put up with similar abuse?

Variations on the object-as-person metaphor include the object-as-agent metaphor. The key difference between an agent and an object is autonomy. Autonomy has at least two aspects: independence and freedom of action, which both objects and agents share; and behavioral integrity, which an object has but an agent does not. To understand what is meant by behavioral integrity, consider the source of behaviors assigned to an object and the source of behaviors assigned to an agent. In the case of an object, the behaviors are intrinsic to  its nature. In the case of an agent, they are proxies of behaviors belonging to the client of the agent. An agent does the things that the client is supposed to do (would do if it had the time). This means that each agent is an idiosyncratic and highly specific reflection of the needs of a client. An agent is not composable .

An object-thinking approach to agents would lead to refactoring the agent into an intrinsic part (the behaviors that allow one to be a good agent) and a variable part (the services that the agent agrees to perform on behalf of a client), which we can call a contract object. Intrinsic behavior would include navigation abilities, knowledge of resources available, and general resourcefulness. A contract is itself composed of different types of objects ”goal objects, rule objects, and results objects among them. Interactions between the agent object and its current contract object would also require different script objects. The result is an ensemble of objects working cooperatively instead of a single entity.

In the real world, we think nothing of people fulfilling multiple roles. People are actors, and objects can also be actors. This metaphor leads into an entire category of theatrical extensions, some of which are discussed in the next section. The metaphor means that a single object can appear quite differently in different contexts. Mel Gibson can be Hamlet or The Road Warrior, two distinctly different roles. A collection object can be used to replicate most of the behaviors of a book or a parking lot, depending on the context and the values and objects manipulated as it performs its services.

Many readers will be uncomfortable with the object-as-person metaphor. A major source of discomfort arises from consideration of characteristics that humans have that we obviously cannot replicate (and probably do not want to replicate) in software. Emotions, true intelligence, and will are major examples. The problem is made worse when descriptions of objects and their behaviors seem to allude to precisely this kind of nonreplicable characteristic ”for example, Objects are lazy.

Effective use of metaphor requires constant awareness that a metaphor is not a specification. It is often helpful to replace the metaphor ”an object is a person ”with a supposition: what if an object were a person? You can then ask questions about your design in this form: if an object were a person, would I write my code this way? Here are two examples:

  • If an object were a person, would I directly access part of its memory without its knowledge instead of sending it a message asking for the information I need? If a developer is obsessed with performance, direct access is tempting. But reminding yourself that, as a person, you would not like someone directly probing your brain without your knowledge reminds you that this is a bad design choice. (It leads to undesirable coupling.)

  • Technology exists that would allow me to make hardware connections to your brain. I could then build a control box that would allow me to raise your hand whenever I pressed a button. Eventually this same technology might allow me to make you perform a complicated dance . Again, as a person, you might not like this, and neither would an object if it were a person.

The object-as-person metaphor, and the parables you can tell using the metaphor, are simple, easy-to-remember proxies for heuristics and axioms of good design.




Microsoft Object Thinking
Object Thinking (DV-Microsoft Professional)
ISBN: 0735619654
EAN: 2147483647
Year: 2004
Pages: 88
Authors: David West

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net