Identifying objects is easy, they should always be nouns. As we have seen in the Circuit Controller example, we picked up nouns from the requirements as classes in our design. Even when you invent classes, keep in mind that they should be nouns. Abstract concepts don't qualify as object names. 

Naming the objects is extremely important in object oriented design. Chances are that if you name your object correctly, the designers and maintainers will assign it functionality that fits its name. Also note that, if you have trouble naming an object, you probably have the wrong object. At this point go back and look at the problem again and see if you can pick an alternative object.

选择名词或者名词短语作为类的名称

识别对象是简单的，因为它们一般都可以用名词来描述。就像我们在电路控制器这个例子中看到的那样，我们在设计的时候从需求中选择名词作为类名。甚至在你创造自己的类的时候，也要时刻注意类名应该是名词。抽象的概念不要作为对象的名称。

在面向对象的设计中为对象命名显得特别重要。在变化出现的时候，如果你恰当的命名了你的对象，设计和维护人员会根据它的名称指派正确的功能。同样需要注意的是，如果你发现你在命名一个对象的时候出现了问题，你可能创造了一个错误的对象。在这个时候，应该再一次回到问题本身，寻找是否存在一个可以替代的对象。
----------------------------------------------

Method names should contain verbs

In any language, actions performed by nouns are specified using verbs. Why should object oriented programming be any different? Thus make sure all the operation methods should contain verbs.

Thus the Circuit class we discussed earlier would have methods like:

• Activate
• Deactivate
• Block
• Unblock
• ChangeStatus

Notice that the methods do not include Circuit in the name (ActivateCircuit, BlockCircuit etc.) as being methods of Circuit its clear that they refer to operations on Circuit.

方法名称应该包含动词

在任何一种语言中，用名词表现行为即为动词。在OOP中也不例外，应该确保所有方法包含动词。因此，在我们之前起到的那个Circuit 类中的方法应该像下面这样：

Design is a process of modeling the problem domain into programming constructs. Object oriented design simplifies the design process by maintaining a one-to-one mapping between problem domain objects and software objects. To succeed in object oriented design, keep your design as close as possible to problem domain objects. The interactions between your objects should mirror interactions between corresponding problem domain objects.

Problem domain objects is basically an object that can be found in the problem itself. For example, when developing a text editor real-world objects would be, Paragraph, Sentence, Word, ScrollBar, TextSelection etc. While developing a call processing module, the objects might be Call, Ringer, ToneDetector, Subscriber etc. 

靠近问题领域

设计是一个把问题领域建模到程序结构的过程。面向对象的设计通过维持一个一对一的问题领域和软件对象之间的映射，让设计过程简单化。要成功的进行面向对象的设计，应当让你的设计尽可能的靠近问题领域对象。你设计的对象之间的相互关系应该与问题领域对象之间的相互关系一致。

问题领域对象本质上就是可以在问题本身中找到的对象。例如，当你开发一个文本编辑器的时候，真实世界的对象可能是段落、句子、词、滚动条、文本选择器等；让你开发一个呼叫过程模块时，对象可能是呼叫者、闹铃、音频探测器、被呼叫者等。

----------------------------------------------------------

Object discovery vs. object invention

The first step in object oriented analysis is to discover the objects that can be directly identified from the problem itself. In many cases objects can be identified  from the requirements. Objects discovered from the problem statement are extremely important. These objects will be the core objects in the design.

The next stage in object design is to "invent" objects. These objects are needed to "glue" together objects that have been identified during object discovery. Invented objects generally do not correspond to anything tangible in the problem domain. They are inventions of programmers to simplify design.

Consider the following statement from the requirements:

The circuit controller shall support digital and analog circuits. The circuit controller shall contain 32 DSPs. When the circuit controller receives a request to setup a circuit, it shall allocate a DSP to the circuit.

We discover the following objects from the requirement:

• CircuitController
• DigitalCircuit
• AnalogCircuit
• DSP

We invent the following objects based on our knowledge of the manager design pattern:

• DSPManager: Manages the 32 DSPs on the circuit controller
• CircuitManager: Manages the digital and analog circuits

We invent a Circuit base class for DigitalCircuit and AnalogCircuit by filtering properties that are common to DigitalCircuit and AnalogCircuit objects.

The relationship between the classes also follows from the requirement. CircuitController class contains DSPManager and CircuitManager classes. The CircuitManager contains an array of Circuit class pointers. The DSPManager contains an array of DSP objects.

发现对象 vs 创造对象

面向对象设计中的第一步就是在问题本身中发现对象。在大多数情况下，对象可以直接在需求中提取出来。在问题的描述中发现对象是非常重要的，往往这些对象就是设计中的核心对象。

对象设计的下一步就是“创造”对象。这些创造的对象需要和提取出来的对象“粘和”起来。被创造出来的对象和问题领域本身并没有直接的关联，这些对象是程序员创造出来，以便简化设计用的。

考虑下面在需求中的一句话：

电路控制器应该支持数字信号和模拟信号。电路控制器应该处理32位的DSP。当电话控制器接收一个建立电路的请求之后，它应该为这个电路分配一个DSP。

我们在这段需求中可以发现下面几个对象：

• CircuitController
• DigitalCircuit
• AnalogCircuit
• DSP

然后我们根据管理设计模式的知识创造下面的对象：

• DSPManager：在电路控制器中管理32位的DSP。
• CircuitManager：管理数字电路和模拟电路。

我们为DigitalCircuit和AnalogCircuit再创造一个基类Circuit，这个基类拥有DigitalCircuit和AnalogCircuit中共有的属性。

这些类的联系也符合我们的需求：

CircuitController类拥有DSPManager类和CircuitManager类。CircuitManager拥有一组Circuit类的引用；同时DSPManager也拥有一组DSP对象。

实际上，我一直在找寻这样的一个例子来说明类的应该就是一个独立的个体，不应该其他无关系的类有联系，今天看到这篇文章，一句话：正和我意！

Person owns Dog...

May 28, 2004

There's a famous OO problem involving people and dogs that I first learnt about in Meilir Page-Jones' excellent book "Fundamentals of Object-Oriented Design in UML." It involves a class Person, with an attribute numOfDogsOwned and a simple accessor method getNumDogsOwned(). The argument goes that this may not neccessarily be good design, since Person and Dog are distinct concepts, and dog ownership is not an essential property of being a person.

Page-Jones calls this mixed-role cohesion, and he explains the problem better than I can: "What if you wanted to reuse Person in an application that had no dogs? You could do so, but you'd have extra, useless baggage from the class, and you might get some pesky warnings about missing dogs from your compiler (or linker). And where should we stop with this design philosophy? Why not include these attributes in Person: numOfCarsOwned, numOfBoatsOwned, numOfCatsOwned, numOfFrogsOwned,... ?"

It's an interesting problem, because there's no perfect solution in OO - Page-Jones discusses the pros and cons of four possible solutions including just adding the members directly to Person, using a PersonDogOwnership relationship class, using an abstract mix-in class, and using aggregation. Mixed-role cohesion sounds like the kind of problem that inter-type declarations in AspectJ should be able to help us address, so here's the world's first (AFAIK) aspect-oriented solution to the person-owns-dog problem:

/**
* not a dog in sight...
*/
public class Person {
private String lastName;
private Address address;
...
public String getLastName() { return lastName; }
...
}

Some of you will have heard me use my adverb/adjective analogy for aspects before, and that's exactly what we've got here. We want to create a dog-owning person, which we could do by creating a DogOwningPerson class (a bit like creating a new noun), but dog-owning isn't limited to people, maybe an Organisation can own dogs too? What we've got is a concept (a compound adjective, dog-owning) that stands in its own right independent of any one class, and that could be applied to many different classes. I'm thinking interface, and I'm thinking aspect...

/**
* not a person in sight...
*/
public aspect DogOwnership {
public interface IDogOwner {};
private int IDogOwner.numDogsOwned;
public int IDogOwner.getNumDogsOwned() { return numDogsOwned; }
}

This aspect represents in a single module the concept of dog ownership. It defines an IDogOwner interface (it doesn't have to be an inner-interface, but making it so helps to keep the whole thing together), and uses inter-type declarations to define a numDogsOwned attribute and a getNumDogsOwned() method on behalf of all dog owners.

We still haven't quite got to person-owns-dog - I wanted to keep the concept of dog ownership independent of any one kind of dog owner. If we have an application where we need person-owns-dog, we can write the following:

public aspect PersonOwnsDog {
declare parents : Person implements DogOwnership.IDogOwner;
}

I like this solution because Person and DogOwnership are independently reusable, and represent cohesive abstractions in their own right. The PersonOwnsDog aspect that binds the two together is also very clear and simple.

With these aspects in place, you could call the getNumDogsOwned method on a Person as follows:

Person person = new Person();
person.getNumDogsOwned();

this will compile happily and execute without any problems. If ever you build the application without the PersonOwnsDog aspect though, you'll get a compile-time error about missing dogs. If you don't want that to happen, you could code the client this way (and I probably would in this particular circumstance):

...
if (person instanceof DogOwnership.IDogOwner) {
((DogOwnership.IDogOwner)person).getNumDogsOwned();
}
...

but it's just a matter of personal taste, the compiler doesn't require it.

Posted by adrian at May 28, 2004 12:21 PM [permalink]

1.    The browser hosts an application, not content.
        浏览器是一个应用程序，而不是一个显示内容的容器。

2.    The server delivers data, not content.
        服务器端发送数据，而不是全部内容。

3.    User interaction with the application can be fluid and continuous.
        和用户的交互应该是连贯而持续的。

4.    This is real coding and requires discipline.
        这是真正的编程，当然需要严谨的原则。