Friday, April 6, 2007

关联和依赖关系的区分

玻璃杯中的花生壳--关联和依赖关系的区分

[软件工程]关联和依赖关系的区分
[ 2007-3-29 14:47:28 | By: 玻璃杯中的花生壳 ]
 

依赖是比关联弱的关系,关联代表一种结构化的关系,体现在生成的代码中,以java为例:  
 
若类A 单向关联指向类B,则在类A 中存在一个属性B   b  
 
若类A依赖类 B,则不会有这个属性,类B的实例可能存在于某个方法调用的参数中,或某个方法的局部变量中。

关联会对关系的类增加属性  
 
依赖则并不对关系的类增加属性  

从业务角度来讲:关联表示的是"拥有 "关系(根据拥有的程度又可分为一般关联,聚合,合成),依赖表示的是"涉及 "关系。如汽车跟轮子,车身的关系是关联,但跟汽油、公路的关系就是依赖。  
 

关联关系就是两个类谁都知道谁,可以相互通信,也就是说只要存在相互通信的连接,就是关联。关联关系分为7 类:普通、递归、限定、或、有序、三元、聚合关联。如人类和计算机类,"使用 "就是他们的关联。  
 
依赖:类A是独立的,若类 A的改变将导致类B的改变,则说明类 B依赖于类A ,他们是依赖关系。

在建立对象模型时,很容易把依赖、关联和聚集关系混淆。当对象 A和对象B 之间存在依赖、关联或聚集关系时,对象A都有可能调用对象 B的方法,这是三种关系之间的相同之处,除此之外,它们有着不同的特征。

1 .依赖关系的特征


对于两个相对独立的系统,当一个系统负责构造另一个系统的实例,或者依赖另一个系统的服务时,这两个系统之间主要体现为依赖关系,例如生产零件的机器和零件,机器负责构造零件对象。再例如充电电池和充电器,充电电池通过充电器来充电。再例如自行车 Bicycle和打气筒 Pump,自行车通过打气筒来充气。图1-39Bicycle类与 Pump类的类框图。



1-39 Bicycle 类与Pump类的依赖关系

Bicycle 类和Pump类之间是依赖关系,在 Bicycle类中无需定义Pump类型的变量。 Bicycle类的定义如下:

public class Bicycle{
/**
给轮胎充气 */
public void expand(Pump pump){
pump.blow();
}
}


在现时生活中,通常不会为某一辆自行车配备专门的打气筒,而是在需要充气的时候,从附近某个修车棚里借个打气筒打气。在程序代码中,表现为 Bicycle类的 expand()方法有个Pump类型的参数。以下程序代码表示某辆自行车先后到两个修车棚里充气:

myBicycle.expand(pumpFromRepairShed1); // 到第一个修车棚里充气
myBicycle.expand(pumpFromRepairShed2); //
若干天后,到第二个修车棚里充气

2 .关联关系的特征
对于两个相对独立的系统,当一个系统的实例与另一个系统的一些特定实例存在固定的对应关系时,这两个系统之间为关联关系。例如客户和订单,每个订单对应特定的客户,每个客户对应一些特定的订单;再例如公司和员工,每个公司对应一些特定的员工,每个员工对应一特定的公司;再例如自行车和主人,每辆自行车属于特定的主人,每个主人有特定的自行车,图 1-40显示了主人和自行车的关联关系。而充电电池和充电器之间就不存在固定的对应关系,同样自行车和打气筒之间也不存在固定的对应关系。

1-40 主人和自行车的关联关系


Person
类与Bicycle类之间存在关联关系,这意味着在 Person类中需要定义一个Bicycle 类型的成员变量。以下是Person类的定义:

public class Person{
private Bicycle bicycle; //
主人的自行车

public Bicycle getBicycle(){
return bicycle;
}
public void setBicycle(Bicycle bicycle){
this.bicycle=bicycle;
}
/**
骑自行车去上班 */
public void goToWork(){
bicycle.run ();
}
}


在现时生活中,当你骑自行车去上班时,只要从家里推出自己的自行车就能上路了,不象给自行车打气那样,在需要打气时,还要四处去找修车棚。因此,在 Person类的 goToWork()方法中,调用自身的bicycle 对象的run()方法。假如 goToWork()方法采用以下的定义方式:

/** 骑自行车去上班 */
public void goToWork(Bicycle bicycle){
bicycle.run();
}

那就好比去上班前,还要先四处去借一辆自行车,然后才能去上班。

No comments: