UML六种关系在代码中的体现你真的清楚吗？

前言

小编采用代码与图(IDE逆向工程生成)对应的方式进行输出此篇内容。

众所周知，uml六种关系强弱表示：继承>实现>组合>聚合>关联>依赖，下文就以从强到弱的关系一一进行介绍。

继承

public class Jeep extends Car {
}

实现

public class Car implements Fly {
}

组合

小编使用的IDE工具是IDEA，在IDEA逆向工程生成的图中，组合，聚合，关联三种关系用的同一种方式展现。

public class Car{
	private Framework framework;
	public Car() {
        this.framework = new Framework(null);
    }
}

上面类Car与类Framework的关系如图所示，一条依赖关系<<create>>，一条关联关系（在idea生成的图中关联，聚合，组合关系用同一种方式表示。）在这里，最弱的关系是关联，所以，二者间至少是关联关系。其中，菱形指向的一方代表整体，而箭头指向的一方代表局部，1代表在1个Car类中有1个Framework类实例。

其中，把代码中Car构造方法去掉，就会发现类间关系变成了只有一个关联关系（上图中Car与Framework右侧的线），可得，在构造方法中创建Framework类的实例代表的是 依赖关系<<create>>这条线。

而为什么小编得出上面的代码就是组合关系呢？？别急，我们和聚合关系对比来看。

聚合

public class Car{
	private Framework framework;
	public Car(Framework framework) {
        this.framework = framework;
    }
}

我们可以看到通过代码逆向工程生成的图中，类Car与类Framework间关系是：一条依赖关系，一条关联关系，和组合中的做法相同，我们把Car构造方法代码去掉，会发现只剩下关联关系，所以，Car构造方法中代表的是两个类间的 依赖关系。

这种写法和组合中的代码有什么不同呢？一个是在构造方法中实例化另一个类，一个是通过参数将另一个类的实例传进来。我们思考一下组合和聚合的区别就能轻易得出，这两个情况分别代表的关系。

由此得出，依赖关系上带有 <<create>>标志的关系相对于不带有 <<create>>标志的耦合更强一些，也就是关系更强。由此，得出结论：在Idea逆向工程生成的图中，依赖关系 <<create>>标志+关联，可以理解为组合关系，而普通依赖关系+关联，可以理解为聚合关系。当然，组合和聚合关系的前提是关联关系。（代码体现也就是Car类内部，方法外部声明的 Framework 类变量）

关联

public class Car{
	private Framework framework;
}

了解了组合和聚合关系后，我们对关联关系自然也明白了，因为关联关系是聚合和组合的基础。在类A内部，方法外部声明的类B的变量，这两类间的关系就可以说成是关联关系。因为类B变量的生命周期与类A是相同的，比依赖关系要强，所以，是关系关系。但确定了关联关系后再寻找更强的关系，还需要进一步观察代码。

依赖

依赖关系在代码中有三种体现：

• 参数
• 返回值
• 方法内变量

// 类Car与类Framework
public class Car{
	//case 1：参数
	public Car(Framework framework) {
	......
	}
	
	//case 2：返回值
	public Framework run() {
		return null;
	}
	
	//case 3：方法内变量

    public void run() {
        Framework framework;
    }
}

这三种情况下类间关系是依赖，因为Framework类在Car类的生命周期中占了局部，对于类来说，方法是局部的，类本身是全局的，所以局部的关系一定比全局弱，所以在方法内部声明的类变量，类间关系是依赖。简单一句话总结：区分依赖与关联关系就要看一个类在另一个类中生命周期的长短。

总结

以上对于UML的六种关系，都是经过小编根据代码与图对应实践后得出的结论，如有不同观点，欢迎交流。