依赖关联聚合组合泛化

世界是普遍联系的，因此程序世界中的类，也不可能是孤立的。 UML 为我们定义了它们之间的关系，就是：依赖、关联、聚合、组合还有泛化。

泛化关系比较好理解，就是表示类之间的继承关系。容易混淆的是依赖、关联、聚合和组合的关系。这里做一些甄别：

1、依赖和关联的颠倒

在网上查找了一下依赖和关联的区别，有说“ 关联本身即是一种依赖”，亦有说“ 依赖是一种弱关联 ”，其实说来说去是一档子事。依赖和关联都是说一个类用到了另一个类。其区别在于一个是使用，一个是拥有。

依赖：具有某种偶然性。比如说我要过河，没有桥怎么办，我就去借来一条小船渡过去。我与小船的关系仅仅是使用（借用）的关系。表现在代码上，为依赖的类的某个方法以被依赖的类作为其参数。或者是 class A 的某个方法创造了 class B 的实例抑或对 class B 的静态方法的调用。如果 A 依赖于 B ，那意味着 B 的变化可能要求 A 也发生变化；

有两个元素A、B，如果元素A的变化会引起元素B的变化，则称元素B依赖（Dependency）于元素A。在UML中，使用带箭头的虚线表示依赖关系。

在类中，依赖关系有多种表现形式，如：一个类向另一个类发消息；一个类是另一个类的成员；一个类是另一个类的某个操作参数等等。

这是 uml 图表示的依赖关系：

代码表现：

public class Person
{
	//划船
	public void oarage (Boat boat)
	{
		boat.oarage();     
	}    
}

关联：有名的客户和订单的关系以及公司和员工的关系，都是关联关系。还有就是我和我的单车的例子，他们都是一种“拥有”的关系。表现在代码上，就是一个类包含另一个类的实例，通常表现为被关联类以类属性的形式出现在关联类的类定义中，也可以表现为关联类引用了一个类型为被关联类的全局变量。关联可以使单向的，也可以使双向的。

关联（Association）表示连个类的实例之间存在的某种语义上的联系。例如，一个老师为某个学校工作，一个学校有多间教室。我们就认为教室和学校、学校和教室之间存在着关联关系。

关联关系为类之间的通信提供了一种方式，它是所有关系中最通用、语义最弱的。

从网上找到的公司和员工的UML 图和代码：

公司和员工的关联关系

public class Company
{
	private Employee employee;
	public Employee getEmployee()
	{
		return employee; 
	}
	public void setEmployee(Employee employee)
	{
		this.employee=employee; 
	}
	//公司运作        
	public void run()
	{
		employee.startWorking();
	}
}

可见依赖于与关联亦有动静之别，关联的类“ 静态” 地引用了被关联类的实例变量，而依赖的偶然性也正说明了它的动态性。

2、聚合与组合同出而异体

聚合与组合其实都是关联的特例，都是整体和部分的关系。他们的区别在于聚合的两个对象之间是可分离的，他们具有各自的生命周期。而组合往往表现为一种唇齿相依的关系。

聚合：一种容纳或曰包含的关系，如同机场和飞机，汽车和轮胎的关系。其实仔细想想，前面的公司和员工的关系也有聚合的味道在里面。如一个电话机包含一个话筒，一台计算机包含显示器、键盘和主机等都是聚合关系的例子。在UML中，聚合关系用一个带空心菱形的实线表示，空心菱形指向的是代表“整体”的类。

组合：也可称之为强聚合，整体和部分是不可分的，整体的生命周期结束时也就是部分的生命周期到头时。很有名的就是桌子和桌子腿的关系。如果聚合关系中的表示“部分”的类的存在，与表示“整体”的类有着紧密的关系，例如“公司”与“部门”之间的关系，那么就应该使用“组合”关系来表示。在UML中，组合关系是用带有实心菱形的实线表示

聚合的 UML 图：

组合的 UML 图：

然而，聚合与组合的代码表现形式是一样的，都可以表现为以下的形式，它们仅仅具有语义上的区别。

网上找到的电脑和 cpu 的关系的代码表现：

public class Computer
{
	private cpu cpu; 
	public cpu getcpu()
	{
		return cpu; 
	}
	public void setcpu(cpu cpu)
	{
		this.cpu=cpu; 
	}       
	//开启电脑     
	public void start()
	{
		//cpu运作  
		cpu.run();
	}
}

泛化关系

泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说子类是从父类中继承的，而父类则是子类的泛化。在UML中，使用带空心箭头的实线表示，箭头指向父类。

在UML中，对泛化关系有三个要求：

1>子类应与父类完全一致，父类所具有的关联、属性和操作，子元素都应具有。

2>子类中除了与父类一致的信息外，还包括额外的信息。

3>可以使用子父类实例的地方，也可以使用子类实例。

例如：“书籍”与“非计算机类书籍”就是泛化关系，箭头指向父类"书籍"。

这一篇讲的也不错：http://www.cppblog.com/mzty/archive/2008/04/16/47264.html

结语：

一般情况下，当某个类被当作参数传递并且被当作结果返回的时候，或者被当作某个方法内的临时变量使用的时候 , 可以运用依赖关系，使用关联来表示一个拥有关系，而不是整体 - 部分关系。使用聚合来表示一个动态的整体 - 部分关系，而是用组合来表示一个静态的整体 - 部分关系。但是需要指出的是，所谓“关系”只是在某个问题域才有效，离开了这个问题域，可能这些关系就不成立了，例如之前我和小船的关系，可能在某个问题域中，我是船夫，我的工作就是驾着小船在河上摆渡，那我和小船的关系就上升为关联关系了。试想一下，武侠小说中的那些剑仙们，修炼到人剑合一的境地，剑在人在，剑亡人亡，那它们之间的关系就似乎与组合关系类似了。又如在关心汽车的领域里，轮胎是一定要组合在汽车类中的，因为它离开了汽车就没有意义了。但是在卖轮胎的店铺业务里，就算轮胎离开了汽车，它也是有意义的，这就可以用聚合了。这说明关系是在特定的问题域中的“关系”，会随着问题域的迁移而改变的。

依赖 关联 聚合 组合 泛化

猜你在找的设计模式相关文章

依赖关联聚合组合泛化