工欲善其事－UML基础之类图关系

工欲善其事,必先利其器。－－论语·卫灵公

一直想把android framework的几个重要的系统服务理一下。把知识点串起来，系统化一点。本来公司原来是能用有道云笔记的，所以这两年都是把笔记记在有道里的，谁知道忽然禁用了，ＦＫ。

android 代码大量的使用了设计模式，再加上ipc的代码，搞的非常绕。既然人家按套路出招，那我们就要先了解人家的套路。要了解设计模式的套路，先要有一点ＵＭＬ的知道。类图是帮助理解设计模式的重要利器。

一、类图

类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。–度娘百科

二、类图的元素

2.1、类（Class)
　类是对现实世界中一组具有相同特征的物体的抽象。（既是抽象，也是封装。抽象是因为对一组具有相同特征事物提取了共同的特征。封装是将属于该组事物的多个属性及操作进行了封装。这些我认为并不是废话，这为我们在如果设计类或者说设计类提供了原则上的指导）
　图例：
　
类通常可以分为三种，分别是实体类(Entity Class)、控制类(Control Class)和边界类(Boundary Class)

实体类：就是对应现实世界中的一个实体。比如：员工，公司等。

控制类：控制类用于体现应用程序的执行逻辑，提供相应的业务操作，将控制类抽象出来可以降低界面和数据库之间的耦合度。（从这句话，我们可看出所谓的控制类，实际上起到了一个“关系类”的功能。将类与类之间的相互关系提取出来，做为类，这样有助于降低耦合度）

边界类：边界类用于对外部用户与系统之间的交互对象进行抽象。大部分就是界面类（人机交互当然不仅有界面一种而已）比如：TextBox.java

2.2、接口

接口是一系列方法的声明，是一些方法特征的集合。只有特征，没有实现。
图例：

2.3、关系
类与类之间由弱到强关系是: 没关系 －> 依赖 －> 关联 －> 聚合 －> 组合。

　2.3.1、泛化（Generalization）关系
　就是类之间的继承关系
　图例：
　

　2.3.2、实现（Realization）关系
　指类实际了一个或多个接口
　图例：
　

　2.3.3、依赖关系（Dependence）
　一种使用（use）关系。是一种弱关系。
　常见的依赖关系如下：
（1）类B以参数的形式传入类A的方法。
（2）类B以局部变量的形式存在于类A的方法中。
（3）类A调用类B的静态方法。

　2.3.4、关联关系(association)
　两个类、或者类与接口之间语义级别的一种强依赖关系
　1) 双向关联
　两个类都知道另一个类的公共属性和操作：被关联类B以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量
　图例：
　

　2 ) 单向关联
　图例：
　
　　
　3) 自关联
　一些类的属性对象类型为该类本身
　图例：
　

2.3.5、聚合关系（Aggregation）
体现的是整体与部分、拥有的关系，即has-a的关系
表现在代码层面，和关联关系是一致的，只能从语义级别来区分
这是一种整体与部分可分开的关系，比如多个树聚合成树林，但单棵树仍然是有意义的个体。所以这是一个语义上的差异。
图例：

2.3.6、组合关系（Aggregation）
类之间一种整体与部分之间的关系。体现的是一种contains-a的关系。
这种整体与部分间的关系是不可分开的关系。
组合关系中部分和整体具有统一的生存期。
表现在代码层面，和关联关系是一致的，只能从语义级别来区分。
图例：

后面的几种关系中，从代码的表现上，关联、聚合、组合最终在代码的表现上可能是一致的。都是从语义上来区别的。这里的侧重点是认识图例，理解类的设计与实现，类与类之间的关系。