文章标题 原创 翻译 转载 文章内容 世界是普遍联系的,因此程序世界中的类,也不可能是孤立的。 UML 为我们定义了它们之间的关系,就是:依赖、关联、聚合、组合还有泛化。 泛化关系比较好理解,就是表示类之间的继承关系。容易混淆的是依赖、关联、聚合和组合的关系。这里做一些甄别: 1. 依赖和关联的颠倒 在网上查找了一下依赖和关联的区别,有说“ 关联本身即是一种依赖”,亦有说“ 依赖是一种弱关联 ”,其实说来说去是一档子事。依赖和关联都是说一个类用到了另一个类。其区别在于一个是使用,一个是拥有。 > *依赖*: 具有某种偶然性。比如说我要过河,没有桥怎么办,我就去借来一条小船渡过去。我与小船的关系仅仅是使用(借用)的关系。表现在代码上,为依赖的类的某个方法以被依赖的类作为其参数。或者是 class A 的某个方法创造了 class B 的实例抑或对 class B 的 静态方法的调用 。如果 A 依赖于 B ,那意味着 B 的变化可能要求 A 也发生变化; 有两个元素A、B,如果元素A的变化会引起元素B的变化,则称元素B依赖(Dependency)于元素A。在UML中,使用带箭头的虚线表示依赖关系。 在类中,依赖关系有多种表现形式,如:一个类向另一个类发消息;一个类是另一个类的成员;一个类是另一个类的某个操作参数等等。 这是 uml 图表示的依赖关系: ![依赖关系](http://hi.csdn.net/attachment/201107/13/0_1310560341hEY9.gif) 代码表现: ``` public class Person { //划船 public void oarage (Boat boat) { boat.oarage(); } } ``` > *关联*:有名的客户和订单的关系以及公司和员工的关系,都是关联关系。还有就是我和我的单车的例子,他们都是一种“拥有”的关系。表现在代码上,就是一个类包含另一个类的实例, 通常表现为被关联类以类属性的形式出现在关联类的类定义中,也可以表现为关联类引用了一个类型为被关联类的全局变量。关联可以使单向的,也可以使双向的。 关联(Association)表示连个类的实例之间存在的某种语义上的联系。例如,一个老师为某个学校工作,一个学校有多间教室。我们就认为教室和学校、学校和教室之间存在着关联关系。 关联关系为类之间的通信提供了一种方式,它是所有关系中最通用、语义最弱的。 从网上找到的公司和员工的UML 图和代码 : ![关联](http://hi.csdn.net/attachment/201107/13/0_1310560386FDxU.gif) 公司和员工的关联关系 ``` 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 图 : ![聚合](http://hi.csdn.net/attachment/201107/13/0_13105604092nhc.gif) 组合的 UML 图: ![组合](http://hi.csdn.net/attachment/201107/13/0_1310560424VEe5.gif) 然而,聚合与组合的代码表现形式是一样的,都可以表现为以下的形式,它们仅仅具有语义上的区别。 网上找到的电脑和 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中,对泛化关系有三个要求: * 子类应与父类完全一致,父类所具有的关联、属性和操作,子元素都应具有。 * 子类中除了与父类一致的信息外,还包括额外的信息。 * 可以使用子父类实例的地方,也可以使用子类实例。 例如:“书籍”与“非计算机类书籍”就是泛化关系,箭头指向父类"书籍"。 这一篇讲的也不错:[http://www.cppblog.com/mzty/archive/2008/04/16/47264.html)](http://www.cppblog.com/mzty/archive/2008/04/16/47264.html) ### 结语 一般情况下,当某个类被当作参数传递并且被当作结果返回的时候,或者被当作某个方法内的临时变量使用的时候 , 可以运用依赖关系,使用关联来表示一个拥有关系,而不是整体 - 部分关系。使用聚合来表示一个动态的整体 - 部分关系,而是用组合来表示一个静态的整体 - 部分关系。但是需要指出的是,所谓“关系”只是在某个问题域才有效,离开了这个问题域,可能这些关系就不成立了,例如之前我和小船的关系,可能在某个问题域中,我是船夫,我的工作就是驾着小船在河上摆渡,那我和小船的关系就上升为关联关系了。试想一下,武侠小说中的那些剑仙们,修炼到人剑合一的境地,剑在人在,剑亡人亡,那它们之间的关系就似乎与组合关系类似了。又如在关心汽车的领域里,轮胎是一定要组合在汽车类中的,因为它离开了汽车就没有意义了。但是在卖轮胎的店铺业务里,就算轮胎离开了汽车,它也是有意义的,这就可以用聚合了。这说明关系是在特定的问题域中的“关系”,会随着问题域的迁移而改变的。 文章类别 Python Mobile Android Java Shell Life Database Bug Windows IOS Tools Boost Node.js Mac Product Tips C/C++ Golang Javascript React Qt MQ MongoDB Design Web Linux LLM ChatGPT RAG AI 提交