关联、依赖、聚合、组合、泛化、实现

类之间可能存在以下几种关系：关联(association)、依赖(dependency)、聚合(Aggregation，也有的称聚集)、组合(Composition)、泛化(generalization，也有的称继承）、实现(Realization)。

是指两个类之间存在某种特定的对应关系，例如客户和订单，一个订单只能属于某个客户，一个客户可能会有多张订单。根据方向，分为单向和双向。根据对应的数量分为一对一、一对多、多对多等。对应的UML图如下所示：

    关联关系用实线+箭头表示。

Customer和Order是双向一对多关联关系，那么在Customer中应该有Order的集合，在Order中应该Customer的属性。

依赖指的是类之间的调用关系。类A访问类B的属性或方法，或者类A负责实例化类B，那么就说类A依赖于类B。和关联关系不同的是，无需在类A中定义类B类型的属性。

 

例如自行车和打气筒，自行车通过打气筒来充气，那么就需要调用打气筒的充气方法。对应的UML图如下所示：

　　　　类A　　　　　　　　　　　　类B

    依赖关系用虚线+箭头表示。上图显示Bicycle和Pump是依赖关系，Bicycle依赖于Pump。

 

打气筒并不属于某个特定的自行车，一个打气筒可以为多个自行车提供充气的服务。在Bicycle中不需要定义Pump类型的属性，而是将传递了一个Pump类型的参数到Bicycle的方法中。

 

聚合是整体与部分之间的关系。例如计算机和主板，计算机是一个整体，主板是其中的一部分，主板、显卡、显示器等部件组成了计算机。对应的UML图如下所示：

 
    聚合使用空心菱形+实线表示。上图显示Computer是由MainBoard和DisplayCard等组成的。

 

计算机由主板、显卡等部件组成，所以在Computer中定义了MainBoard和DisplayCard类型的属性。

 

聚合中类之间可以独立出来，比如一块主板可以状态A计算机上，也可以装在B计算机上。也就是说这块主板离开A计算机之后仍然是有意义的。

组合中的类也是整体与部分的关系，与聚合不同的而是，其中的类不能对立出来。例如一个人由头、手、腿和躯干等组成，如果这个头离开了这个人，那么这个头就没有任何意义了。对应的UML图如下所示：

组合使用实心菱形和实线表示。上图表示People是由Head、Hand、Leg等组成。

 

People和Head、Hand、Leg是不可分割的，Head、Hand、Leg离开了People没有任何实际意义。在People中定义了Head、Hand、Leg类型的属性，组合也可以看成是聚合的一种特殊形式。

 

聚合和组合的代码几乎相同，单凭代码是无法区分两个类之间是聚合还是组合的关系的。所以就需要结合实际的业务环境来区分。例如汽车和轮胎，车主买了一辆汽车，上边肯定是由轮胎的，在这个业务中，轮胎和汽车是组合关系，它们分开就没有实际意义了。

 

在汽车修理店，汽车可以更换轮胎，所以在汽修店的业务环境中，汽车和轮胎就是聚合的关系，轮胎离开汽车是有业务意义的。

 

泛化比较好理解，就是两个类之间具有继承关系。例如人和学生，学生继承了人，除过具有人的一般的属性和方法之外，他还要有学习的方法。对应的UML图如下所示：

    泛化用空心三角形+实线表示。

 

Student继承自People，并且多了一个study的方法。

实现即一个类实现了某个接口。对应的UML图如下所示：

    实现用三角形箭头和虚线表示。上图表示类CarDriver和PlaneDriver都实现了Driver接口。

 

值得注意的是，关联、依赖、聚合、组合的关系很容易搞混。当对象A和对象B之间存在关联、依赖、聚合或者组合关系时，对象A都有可能调用对象B的方法。这是它们的相同之处。另外它们还有自己的特征。

对于两个相对独立的对象A和B，当一个对象A的实例与B的实例存在固定的对应关系时，这两个对象之间为关联关系。代码中表现为在A中定义了B类型的属性。

对于两个相对独立的对象A和B，当一个对象A负责构造对象B的实例，或者调用对象B提供的服务时，这两个对象之间主要体现为依赖关系。代码中的表现即将B类型的参数传入A的方法中，而不是在A中定义B类型的属性。

聚合、组合与关联在代码中并没有明显的区别，主要看实际的业务环境，根据代码所处的实际业务环境来判断它们之间的关系。同样的两个类，处在不同的业务环境中，可能它们的关系也不相同。