一、简介
二、五种关系
1、依赖(Dependency)
2、关联 (Association)
3、聚合(Aggregation)2.1、单向
2.2、双向
2.3、自身
2.4、多维(N-ary Association )
4、组合(Composite)
5、泛化(Generalization)
三、 总结
简介
各位架构师同仁及有志于成为架构师的同仁大家好。
本文旨在在这里与各位重温一下架构工作中的一个重点,框架代码类视图的编制工作。通过编制、修改并保存类的视图,来确保中大型系统的代码维护工作得以
持续进行。
本文参照UML建议归总了五种关系,实际上当然还有其他的归总方式,不过UML还是比较受业界推崇的,所以在此推荐一下。
五种关系
1、依赖(Dependency)
某个类的方法依赖于另外的类,这是一个use 关系,两者联系比较弱,两者间的UML图像体现为 虚线 +箭头
class Human { int Attack() { Weapon w; return w.GetPower(); } } #define weapon_type_sword 10 #define weapon_type_tank 1000 class Weapon { int GetPower { return weapon_type_sword; } }
这里Human类的攻击造成一定数值的伤害,数值取决于武器类型。这里人只是用一下武器,而武器不是人的所有物,是很符合天朝的规范的。
2.关联(Association)
2.1 单向关联
某个类知道另一个类,这是一个 has ... ... 的关系,由于从定义上来讲聚合及组合也是关联的一部分,
所以 关联(Association)关系的一个基本解释就是 知道.
或者更形象滴说是 记得 ,UML图形上表现为直线+箭头,如图(图中的Human 和Book就是关联关系)。
class Book { public: Book() { BookName = "A book"; } string BookName; }; class BookList { public: Book Books[1]; BookList() { Book * pBook = New Book;
Books[0] = *pBook; } Book GetBook() { return Books[0]; } }; class Human { public: Book MyBooks[1]; void GetBook() { BookList t; MyBooks[0] = t.GetBook(); } };//此代码有内存泄露之虞,仅供学习设计模式
2.2 双向关联
双向关联表示两个互相知道,和单向关联的主要区别是只有实线没有箭头
2.3 自身关联
节点类往往是一种自身关联的类,主要特点是一个指向自己的单实线加箭头。
2.4 多维关联
多维关联也是一种常见的关联模式,如下图
主人与宠物狗一起玩扔飞盘的游戏,会形成一个多维的关联关系。
3 聚合(Aggregation)
聚合是一种特殊的关联。聚合是一种强的关联关系,表示一个类的对象是另一个类的一部分(成员),同时其拥有关系相对的弱化了,因为聚合带有被包含的类是可以共享,且两个类的对象生命周期有一定的关联却并不完全同步。还是用刚才那本书的示例来演示。
注意图中红色的菱形,聚合关系UML图形就是菱形+直线+箭头(红色只是突出一下)
4 组合(Composite)
组合仍旧是关联关系的一种特殊形式。表示某个类是另一个类的一部分。其图像是一个实心的菱形加上直线加上箭头 。
如上图这个是书和书页的组合关系。书页离开了书是没有意义的(在某种业务描述下当然也是可以分开的,所以UML关系必须结合业务及系统整体情况来看)
5 泛化(Generalization)
指的是类的继承或者类对接口的实现。某些资料里将这两种情况分开讨论,实际是没有意义的,在UML这种重在梳理整体结构关系的体系里并不会,也不需要体现出代码细节或者程序对寄存器之类的底层调用上的区别。泛化的标志是一个伞形图标,伞柄有点超比例的长。
如上图,跑车当然是汽车的子类了。或者说汽车是一种Interface,而跑车是继承该接口的类。
三、总结
五种关系中,泛化在代码实现上与其它四种区别明显,相信各位不太会搞错。那么其它这四种关系,依据关联的紧密度来看 依赖(dependency) < 关联(Association)
< 聚合(Aggregation) < 组合 (Composite)
从实现上看,依赖只是两个类之间存在方法的调用,并不存在一个持续的内存影响。 非聚合/组合 的关联类,通常保持者被关联类的内存指针,但通常来说双方不包含
内存块上的重叠(否则释放一个,另一个也就被释放了)。 聚合与组合在代码上已经很难一眼看出了,两者的被关联类都是直接在关联类内的成员,如果设计师的图纸掉了,而代码有时候写的又不是很严谨的话,情况就悲剧了,你得看遍所有的代码来确定,被关联的(聚合与组合都是关联的一种特殊形式,对吧?)类从来就没有单独实例化使用过,才能确定他是组合,反之即时聚合。现在大家对UML中类的五种关系清楚了吧?