UML图在日常工作和学习中承担着极为重要的作用，也是后续博客撰写过程中高频出现的一个部分，在入职培训的时候还专门做过一个课题的研究学习。但当时实际使用不多，印象没有非常的深刻。这里有必要每当使用UML的一种类型之前，先把相关的知识点整理一下，方便后续的记忆和使用，也是作为正式博客产出的前置内容。

这里先讨论一下最简的类图。顾名思义类图就是描述类之间关系的结构图，关于定义，内容，使用方法等网上都有足够详尽的文章，这里不再赘述。基于读者都已经熟悉了基本内容且处于刚实际上手的视角，来谈谈对于类图的认知。

网上文章为了便于读者理解，一般是使用各种现实中事物之间的关系来做类比。但不太利于更加快速直观的对应到类中的实际情况。所以还是建议读者在有一定代码阅读量的基础上，直接通过类中各种典型的使用场景作为特征，来区分理解各种类之间的关系。

一. 类之间的关系

类与类之间有若干种关系，如果一上来就混在一起全部学习的话，很容易搞混且不容易记忆。这里采用的是以关联性的强弱为依据，分梯度的方式来认知。

1.1 相对独立关系

以上两种关系十分明显和简单，不过多说明。

依赖是一种相对的弱相关，同样比较直观，易于区分。 简单的理解即为一个类持有另一个类实例的引用。A类的一个方法f1(B b)传参传进来了B类的实例，并且只在局部范围中使用。

从这类关系开始不易于区分，需要根据关键特性来加以理解和记忆。和依赖关系最为显著的区别就是：A类是以成员变量的方式持有B类的实例的。

典型场景：A类的构造方法里面new了B类的一个实例并赋值给对应成员变量，。即类A主动创建了类B的实例，并且此实例通常情况下仅由本类来使用。

典型场景：A类通过setter方法来给B类的引用赋值，B类对象的创建不是由A类实现的。

普通关联又从不同角度把关联关系分成了单向关联、双向关联、自关联三部分，简单了解即可。

模块解耦、防止内存泄漏等是实际项目开发中极为重要的内容，理清各种类关系的耦合强度是必要的。从耦合关系由强到弱来看：（关联）组合>（关联）聚合>依赖。

类与类之间的关系可以通过上述几节来加以区分，类内部的成员和方法在uml中如何表示网上也有详尽的讲解，没有什么特别需要强调的内容。这里提出一个建议：在类内部方法和变量过多的情况下，只选取重要的以及和外部相关类有交互的内容展示即可。