类图的关系
类图的关系
关于类图关系的理解
对于 Generalization
- 图的表现上 ： 箭头的指向就是 从谁那里 泛化而来， A->B , A继承了B的功能
- 对于继承来说，基本上都是很清楚，而在C++中的实现也很明显，就是继承
对于 Realization
- 图的表现上： 箭头的指向就是 实现谁的 功能 e.g：A->B, A要实现B的功能
- 而在C++的实现上， 定义为接口类， 然后继承接口类，就行了
对于 Association
- 这个关系，之前理解很痛苦，原因在于，我总是认为关系就是实现。
关系是分析时候的逻辑上的，在实现中往往不一样。 -
关系表示的是一种拥有的关系，它是能让一个类知道另一个类的特征和行为
- 图的表现上：带箭头的是单向关联，A->B , B类有属性是A的对象
- 所以从C++实现上来说，就是class A的 attribute 有class B的指针
对于 Aggreation
- 这个实际上就是整体与部分的关系，但是离开了整体还能活，
思考一下：就像计算机主机一样，内存拆掉，内存还是那个内存 - 图的表现上：箭头的指向 就是 由什么 构成 A -> B : 就是A 由 B 构成
- 从C++的实现上来说， 就是class A 的 attribute 有class B的指针。之前我在这里蒙圈了。
对于 Composition
- 这个是更强的 Aggreation , 整体还要负责部分的生命周期
- 图的表现上 ： 和 Aggreation 表现相同
选取的箭头尾部的菱形不同， Composition表现为 实心的菱形，毕竟离开就不能活，Aggreation为空心 - C++的实现上，就是成员变量，
另一个我认为是指针，只是这里的指针是负责了成员生命周期的指针
对于 Dependency
- 目前对这个不是太懂，虽说表示的是一种使用关系，但是具体的实际还是没有碰到，所以就先行搁置
### Association or Aggreation
在分析的时候，我们能清楚地画出来是关联还是聚合，但是，当我们从代码开始分析的时候，往往会让人有点头晕(准确地说：让我头晕了)。
* 关联和聚合在代码上表达如此相像，但是稍微分析一下还是有点区别的
一般的，界面的控件和后台数据对象应该是关联关系
自己包含自己的指针，应该是自身的关联关系
今年看uml的一本书的笔记(上面是去年思考的)
这个解决了我当年看书的一个疑问，就是上面的那个疑问，由于上次遇到了使用指针的代码，介于我当时的水平很低，并不明白这代表的是关联还是其他的关系，所以看到使用业务逻辑这个方向看的时候，发现明朗了很多。
Generalization 泛化关系
判断是否采用泛化关系
- 在企业领域的专业概念里，特殊对象必须 “是一种” (a kind of)一般对象
- 多种特殊对象里，有部分通用的属性与操作，也有部分独有的属性与操作
Association 关联关系
判断是否采用关联关系
- 在企业领域的专业概念里，两种对象之间有一种固定不变且需要保存的静态关系
- 在信息化时，系统会用到这些静态关系，而且必须将它们存到数据库
Aggregation 聚合关系
聚合关系是一种特殊的关联关系，所以它继承了关联关系的特质，而且还独有”整体-部分”(Whole-Part)的特质
判断是否采用聚合关系
- 在企业领域的专业概念里，两种对象之间有一种固定不变且需要保存的静态关系(继承自关联关系的条件)
- 在信息化时，系统会用到这些静态关系，而且必须将他们保存到数据库(继承自关联关系)
- 在企业领域的专业概念里，两种对象之间有Whole-Part的静态关系(聚合关系独有的条件)
Composition 组合关系
组合关系时一种特殊的聚合关系，所以它继承了关联关系，以及聚合关系的”整体-部分”(WHole-Part)的特质，还独有全然拥有Part对象的特质。
判断是否采用组合关系
- 在企业领域的专业概念里，两种对象之间有一种固定不变且需要保存的静态关系(继承自关联关系的条件)
- 并且在信息化时，系统会用到这些静态关系，而且必须将他们存到数据库(继继承自关联关系的条件)
- 在企业领域的专业概念里，两种对象之间有Whole-Part的静态关系(继承自聚合关系的条件)
- Part对象只能链接一个Whole对象，且Whole对象被注销(Destroy)时，Part对象必须一块被注销(组合关系独有的条件)