依赖 关联 聚合 组合 泛化

前端之家收集整理的这篇文章主要介绍了依赖 关联 聚合 组合 泛化前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

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

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

1、@H_301_2@ @H_301_2@依赖和关联的颠倒@H_301_2@

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

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

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

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

这是@H_301_2@ uml@H_301_2@ 图表示的依赖关系:@H_301_2@

@H_301_2@

代码表现:@H_301_2@ @H_301_2@@H_301_2@

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

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

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

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

从网上找到的公司和员工的UML@H_301_2@ 图和代码 :@H_301_2@

@H_301_2@

公司和员工的关联关系 @H_301_2@

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


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

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

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

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

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

聚合的@H_301_2@ UML@H_301_2@ 图@H_301_2@ :

组合的@H_301_2@ UML@H_301_2@ @H_301_2@图:@H_301_2@

@H_301_2@

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

网上找到的电脑和@H_301_2@ cpu@H_301_2@ 的关系的代码表现:@H_301_2@

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();
	}
}


泛化关系@H_301_2@

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

在UML中,对泛化关系有三个要求:@H_301_2@

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

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

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

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

@H_301_2@

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

结语:@H_301_2@

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

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