类与对象

“对象是一个具有状态、行为和标识符的实体。结构和行为累死的对象定义在它们共同的类中。‘实例’和‘对象’这两个术语可以互换使用。”

状态

考虑一个分发医疗的自动售货机。这类对象的一般行为是当某人在投币口塞进钱，并按下选择按钮时，机器就会提供一种饮料。如果用户先选择饮料再向投币口塞钱会怎样？大部分自动售货机什么也不会干，因为用户违反了它们基本的操作假定。换言之，用户没有注意到自动售货机处于一种状态（等待塞钱）。

从这个例子中，我们可以得到下面的基本定义：

“对象的状态包括这个对象的所有属性（通常是静态的）以及每个属性当前的值（通常是动态的）。”

行为

“行为是对象在状态改变和消息传递方面的动作和反应的方式”

换言之，对象的行为代表了它外部可见的活动。

标识符

对象之间的关系

两个对象之间的关系包括了一个对另一个所做的假定，即包括可以执行哪些操作以及导致怎样的行为。我们发现，在面向对象分析和设计中有两种对象关系特别有趣，它们是：

链接；

聚合；

链接（link）这个术语来自Rumbaugh等人，他们将它定义为“两个对象之间物理上或概念上的联系”。一个对象通过它与其他对象的链接，与其他对象进行协作。换言之，链接代表了具体的关联，通过这种关联，一个对象请求另一个对象的服务，或者通过这种关联从一个对象导航到另一个对象。

图3-5展示了集中不同的链接。这个图中，两个对象图标之间的连线代表这两个对象之间存在链接，意味着消息可以通过这个途径传递。消息用小箭头表示，它代表消息的方向，带有一个标签为消息本身命名。例如,图3-5中展示了一个简化的水流控制系统的一部分，这可能是在一个制造工厂中控制管道水流的。可以看到，FlowController对象（水流控制器）有一个到Value对象（阀门）的链接。Value对象有一个到DisplayPanel对象（显示面板）的链接，DisplayPAnnel将显示它的状态。只有通过这些链接，一个对象才能向另一个对象发送消息。

作为链接的参与者，一个对象可能扮演一下三种角色之一。

控制器：这个对象可以操作其他对象，但不会被其他对象操作。在某些地方，“主动对象”和“控制器”这两个术语是互换使用的。

服务器：这个对象不操作其他对象，它只被其他对象操作。

代理：这个对象既可以操作其他对象，也可以被其他对象操作。创建代理通常是为了表示问题域中的一个真实对象。

在许多不同类型的工业过程中，某些反应要求一定的温度坡度，即提升某种物质的温度，让它在某个温度保持一段时间，然后将它冷却到环境温度。不同的过程需要不同的温度曲线：某些对象（如望远镜中的镜子）必须马楠冷却，而另一些物质（如钢）必须迅速冷却。这种温度坡度具有足够的定义良好的行为，可以创建为一个类。因此我们提供了TemperatureRamp类，它在概念上是一种时间/温度的映射关系

实际上，这种抽象的行为不只是简单的时间/温度映射关系。例如。可以设置一种温度坡度，要求在60分钟达到250度，在180分钟时达到150度，然后我们想知道120分钟时温度是多少。这需要线性插值，这就是我们希望的这种抽象的另一个行为。

有一个行为显然不是这种抽象需要具备的，即控制加热器来实现特定的温度坡度。我们喜欢更好的关注点分离，让这种行为通过3个对象的协作来实现：一个温度坡度实例、一个加热器和一个温度控制器。process操作提供了这种抽象的主要行为，它的目标是利用指定位置的加热器实现指定的温度坡度。

对于我们的风格，有一点说明。第一眼看上去，似乎我们设计了一种抽象，其目的只是将一种功能分解包装在一个类中，使它看起来显得高贵而面向对象。但schedule操作表明并非如此。TemperaturezController类的对象拥有足够的知识，可以决定何时应该安排哪种具体控制，所以我们将这个操作作为抽象的另一个行为。在某些高能耗的工业过程中，加热物质是成本很高的事情，考虑前一个过程遗留下来的热量是很重要的，另外考虑未参与的加热器的正常冷却。由于存在schedule操作，客户可以查询TemperatureController对象，以确定处理特定温度的下一个最优时间。

1.可见性

考虑两个对象A和B，它们之间存在一个链接。为了让A能向B发送一条消息，B必须以某种方式让A看到它。在对问题分析的过程中，基本上可以忽略可见性的问题，但当开始设计具体的实现时，就必须考虑跨越链接的可见性，因为，我们此时考虑决定了链接两端对象的范围的访问。

2.同步

顺序：只有在某一时刻只存在一个主动对象时，被动对象的语义才能得到保证。

守卫：在多个控制线程的程序下，被动对象的语义也能保证，但主动地客户之间必须协作，已实现互斥访问。

并发：在多个控制线程的程序下，被动对象的语义也能保证，服务者保证互斥。

聚合

链接表明了一种端到端的关系或客户/服务提供者的关系，而聚合则表明一种整体/部分层次结构，提供了从整体导航到它部分的能力。

聚合可以代表物理上的包含，也可以不代表。

显然，在链接和聚合之间需要折中。有时候聚合更好，因为它将各个部分封装为整体的秘密；有时候链接更好，因为它们允许对象回见比较松的耦合。明智的工程决定需要仔细权衡这两方面的因素。

类的本质

对象是存在时间和空间的具体实体，而类仅代表一种抽象，即一个对象的“本质”。

“类是一组对象，它们拥有共同的结构、共同的行为和共同的语义。”

接口和实现

编程在很大成单独上是一种“制定契约”：一个较大问题的不同功能通过子契约被分配给不同的设计元素，从而被分解成较小的问题。

总的莱索，存在三种基本类型的类关系。第一种关系是一般、特殊关系，标识“是一种”关系。第二种关系是整体/部分，表示"组成部分"关系。第三种姑息是关联，表示某种语义上的依赖关系。

关联

1.语义上的依赖关系

关联只代表一种语义上的依赖关系，它标识这种依赖关系的方向，，也不标识一个类与另一个类相关的具体形式，但是，这些语义在分析问题时已经足够了，这是只需要确定这样的依赖关系。通过创建关联，用语义关系、它们的角色和它们的基数记录了参与关联的类。

这里展示了一对多的关联：每个Wheel实例与一个Vehicle有关，每个Vehicle实例可能与多个Wheel有关（用*号表示).。

2.多重性

一对一

一对多

多对多

继承

类和对象在分析和设计中的角色

在分析阶段和设计的早期阶段，开发者有两项主要任务：

从问题域的词汇中确定出类;

创建一些结构，让多组对象一起工作，提供满足问题需求的行为。

我们将这样的类和对象统称为问题的“关键抽象”,把这些协作结构称为实现的“机制”。

在开发这些的阶段中，开发者必须关注这些关键抽象和机制的外部视图。外部视图代表了系统的逻辑框架，因此包含了系统的类结构和对象结构。在设计阶段的后期以及随后的实现阶段，开发者的任务发生了变化，其关注的焦点放在了这些抽象和机制的内部视图上，包括它们的物理实现。

评判一种抽象的品质

耦合

内聚

充分性

完整性

基础性