UML类中的几种关系（有图有例子说明）

点击查看原文

类之间可能存在以下几种关系：关联(association)、依赖(dependency)、聚合(Aggregation，也有的称聚集)、组合(Composition)、泛化(generalization，也有的称继承）、实现(Realization)。
关联是指两个类之间存在某种特定的对应关系，例如客户和订单，一个订单只能属于某个客户，一个客户可能会有多张订单。根据方向，分为单向和双向。根据对应的数量分为一对一、一对多、多对多等。对应的UML图如下所示：




关联关系用实线+箭头表示。上图显示Customer和Order是双向一对多关联关系。对应的Java代码如下所示：

class Customer {

private Integer id;

private String name;

private Set<Order> orders;

public Set<Order> getOrders() {

return orders;

}

public void setOrders(Set<Order> orders) {

this.orders = orders;

}

}

class Order {

private Integer id;

private float money;

private Customer customer;

public Customer getCustomer() {

return customer;

}

public void setCustomer(Customer customer) {

this.customer = customer;

}

}

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

依赖指的是类之间的调用关系。类A访问类B的属性或方法，或者类A负责实例化类B，那么就说类A依赖于类B。和关联关系不同的是，无需在类A中定义类B类型的属性。例如自行车和打气筒，自行车通过打气筒来充气，那么就需要调用打气筒的充气方法。对应的UML图如下所示：




依赖关系用虚线+箭头表示。上图显示Bicycle和Pump是依赖关系，Bicycle依赖于Pump。对应的Java代码如下所示：

class Bicycle {

public void expand(Pump pump) {

pump.blow();

}

}

class Pump {

public void blow() {

System.out.println("正在充气......");

}

}

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

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




聚合使用空心菱形+实线表示。上图显示Computer是由MainBoard和DisplayCard等组成的。对应的Java代码如下所示：

class Computer {

private MainBoard mainBoard;

private DisplayCard displayCard;

public void on() {

System.out.println("开启计算机......");

}

public void close() {

System.out.println("关闭计算机......");

}

public void run() {

System.out.println("计算机正在运行......");

}

}

class MainBoard {

public void control() {

System.out.println("控制计算机......");

}

}

class DisplayCard {

public void display() {

System.out.println("计算显示数据......");

}

}

计算机由主板、显卡等部件组成，所以在Computer中定义了MainBoard和DisplayCard类型的属性。
聚合中类之间可以独立出来，比如一块主板可以状态A计算机上，也可以装在B计算机上。也就是说这块主板离开A计算机之后仍然是有意义的。

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



组合使用实心菱形和实线表示。上图表示People是由Head、Hand、Leg等组成。对应的Java代码如下所示：

class People {

private Head head;

private Hand hand;

private Leg leg;

public void think() {

head.think();

}

public void holdThing() {

hand.holdThing();

}

public void walk() {

leg.walk();

}

}

class Head {

public void think() {

System.out.println("思考......");

}

}

class Hand {

public void holdThing() {

System.out.println("拿东西......");

}

}

class Leg {

public void walk() {

System.out.println("走路......");

}

}

People和Head、Hand、Leg是不可分割的，Head、Hand、Leg离开了People没有任何实际意义。在People中定义了Head、Hand、Leg类型的属性，组合也可以看成是聚合的一种特殊形式。
聚合和组合的代码几乎相同，单凭代码是无法区分两个类之间是聚合还是组合的关系的。所以就需要结合实际的业务环境来区分。例如汽车和轮胎，车主买了一辆汽车，上边肯定是由轮胎的，在这个业务中，轮胎和汽车是组合关系，它们分开就没有实际意义了。在汽车修理店，汽车可以更换轮胎，所以在汽修店的业务环境中，汽车和轮胎就是聚合的关系，轮胎离开汽车是有业务意义的。

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




泛化用空心三角形+实线表示。上图表示Student继承People。对应的Java代码如下所示：

class People {

protected String name;

protected String sex;

protected Date birthday;

public void eat() {

System.out.println(name + "正在吃饭......");

}

public void drink() {

System.out.println(name + "正在喝水......");

}

public void sleep() {

System.out.println(name + "正在休息......");

}

}

class Student extends People {

public void study() {

System.out.println(name + "正在学习......");

}

}

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

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




实现用三角形箭头和虚线表示。上图表示类CarDriver和PlaneDriver都实现了Driver接口。对应的Java代码如下所示：

public interface Driver {

void drive();

}

class CarDriver implements Driver {

public void drive() {

System.out.println("驾驶汽车......");

}

}

class PlaneDriver implements Driver {

public void drive() {

System.out.println("驾驶飞机......");

}

}

值得注意的是，关联、依赖、聚合、组合的关系很容易搞混。当对象A和对象B之间存在关联、依赖、聚合或者组合关系时，对象A都有可能调用对象B的方法。这是它们的相同之处。另外它们还有自己的特征。
对于两个相对独立的对象A和B，当一个对象A的实例与B的实例存在固定的对应关系时，这两个对象之间为关联关系。代码中表现为在A中定义了B类型的属性。
对于两个相对独立的对象A和B，当一个对象A负责构造对象B的实例，或者调用对象B提供的服务时，这两个对象之间主要体现为依赖关系。代码中的表现即将B类型的参数传入A的方法中，而不是在A中定义B类型的属性。
聚合、组合与关联在代码中并没有明显的区别，主要看实际的业务环境，根据代码所处的实际业务环境来判断它们之间的关系。同样的两个类，处在不同的业务环境中，可能它们的关系也不相同。

点击查看原文