Object Design reading note

Object Design: Roles, Responsibilities, and Collaborations

概要：讲述的是面向对象的的基本理论。对像设计中的：角色，职责，协作！

面向对象设计是管理的哲学，是数学的哲学，是自我管理之径，是思考的之径

参考中文文章：http://www.blogjava.net/sslaowan/archive/2007/03/20/104987.html

 

Chapter 1. Design Concepts

 

Alan Kay's favorite metaphor for software objects is a biological system.

A software object may be machinelike, but, crafted by a thoughtful designer, it can be very smart. It makes decisions; it does things and knows things. It collaborates with potentially many other objects. Living in an enclosing machine, it is a whole on one level and a part on another.--->对象是死的，可是聪明的设计者能够赋予它能力:能够做选择，做事情，拥有信息，协作。从不同角度去看对象它可以是某个整体的一部分，也可以是一个独立的主体。

 

Object Machinery

 

   A software application is constructed from parts. These parts software objects interact by sending messages to request information or action from others. Throughout its lifetime, each object remains responsible for responding to a fixed set of requests. To fulfill these requests, objects encapsulate scripted responses and the information that they base them on :knows infomation,maintains connections to other objects,performs services,makes decisions to do the right thing. If an object is designed to remember certain facts, it can use them to respond differently to future requests--->一个对象：知道一些信息，维持一些和其它对象的链接，执行一些服务，做出一些决定去做一些正确的事情

 

   Software objects display information, coordinate activities, compute, or connect to services. The bulk of this machine is our invention! We follow a real-world metaphor forms and files put our object model includes a much richer set of concepts that are realized as objects. --->我们对现实进行隐喻，把丰富的现实世界抽象成为我们的对象模型。

 

   If we keep our focus on the behavior, we can design the application using several complementary perspectives:---->关于程序我们可以形成如下看法：

An application =	a set of interacting objects
An object =	an implementation of one or more roles
A role =	a set of related responsibilities
A responsibility =	an obligation to perform a task or know information
A collaboration =	an interaction of objects or roles (or both)
A contract =	an agreement outlining the terms of a collaboration

 

Roles

 

A role is a set of responsibilities that can be used interchangeably.

   It is useful to think about an object, asking, "What role does it play?" This helps us concentrate on what it should be and what it should do. We have been speaking of objects and roles loosely. What is the real difference? When a role is always played by the same kind of object, the two are equivalent. But if more than one kind of object can fulfill the same responsibilities within the community, a role becomes a set of responsibilities that can be fulfilled in different ways. A role is a slot in the software machinery to be filled with an appropriate object as the program runs. ---->什么是角色，角色和对象的区别？

 

Object Role Stereotypes

A well-defined object supports a clearly defined role. We use purposeful oversimplifications, or role stereotypes, to help focus an object's responsibilities. --->好的对象有明晰的角色定位！

 

Because our goal is to build consistent and easy-to-use objects, it is advantageous to stereotype objects, ignoring specifics of their behaviors and thinking about them at a higher level. By oversimplifying and characterizing it, we can ponder the nature of an object's role more easily. We find these stereotypes to be useful:

• Information holder nows and provides information

• Structurer maintains relationships between objects and information about those relationships

• Service provider performs work and, in general, offers computing services

• Coordinator reacts to events by delegating tasks to others

• Controller takes decisions and closely directs others' actions

• Interfacer transforms information and requests between distinct parts of our system

But is it playing one or two roles? Often we find that a service provider holds information that it needs to provide its service. In doing so, it assumes two stereotypes  information holder and service provider  put only one role because the responsibilities are all wrapped up together for the same customers to use. If its information is being used solely to support its service, it assumes two stereotypes but only one role. But if it is perceived as serving two different types of clients for different purposes, it is likely playing two roles.

 

Some objects are hard to stereotype because they seem to fit into more than one category. They're fuzzy. How can you choose? You must decide what you want to emphasize. A transmission is a service provider if you emphasize the multiplication of power by the gears. It is an interfacer if you emphasize its connections to the engine and wheels. Can objects have more than one stereotype? If you want to emphasize more than one aspect, that's OK. There are blends of stereotypes, just as there are blends of emphasis.