我对uml类图关系的理解

泛化关系（继承）
（带三角箭头的实线，箭头指向父类）



实现关系
（带三角箭头的虚线，箭头指向接口）



依赖关系
（带箭头的虚线，指向被使用者）



关联关系：
（带普通箭头的实心线，指向被拥有者）



聚合关系
（带空心菱形的实心线，菱形指向整体）



组合关系
（带实心菱形的实线，菱形指向整体）

泛化关系
public Class Tigger extends Animal{
实现关系
public Class Course implements Goods{
依赖关系
局部变量、方法的参数或者对静态方法的调用



关联关系，聚合关系，组合关系都是成员变量

类与类之间关系的确定必须是依据实际需求，换句话说就是在某个语义下才能确定两个类的关系，客观真实的反应真实需求。
比如：语义环境是："汽车有四个车轮，有了车轮汽车才可以行驶，车轮本身有自己的特征（颜色，大小）"
那么我们就可以抽取出汽车类和车轮类，那么如何确定他们的关系？？
根据uml类关系我们可以排除实现和继承，那么就剩下关联和依赖，依赖强调的是使用关系，关联强调的是拥有关系，“有车轮才可以行驶”这句话就可以
推断出他们不是使用关系，而是拥有关系，汽车必须拥有车轮。所以应该是：



比如：语义环境“卸掉的车轮要放到车库中去”依据这句话我们可以抽取两个类
车轮类和车库类，那么他们之间的关系又是什么呢？
肯定也不是实现和继承，那究竟是依赖还是关联呢，根据"车轮放到车库中"这句话可以得出，车库要提供一个存放车轮的服务，
两者不是拥有关系而是使用关系。所以：

语义描述"一个学习视频有多个知识点，一个知识点又可以被多个视频拥有"
还有一种方法来确定两个类的关系，使用类关系的代码体现确定类关系:
依赖关系的代码体现是方法参数，局部变量，静态方法调用。
关联关系的代码体现是成员变量。
根据"一个学习视频有多个知识点"的描述我们可以知道，视频类肯定有一个list<知识点类>的成员变量，
根据"一个知识点又可以被多个视频拥有"的描述我们可以知道，知识点类也有一个list<视频类>的成员变量，
所以可以断定视频类和知识点是关联关系。

注意：并不是所有的成员变量都是关联关系，如果说这个对象在创建的时候就需要这个属性，那么就可以断定是关联关系，
但是如果这个属性可以放在创建这个对象之后赋值，那么它就是依赖关系。

还是上面的语义描述"一个学习视频有多个知识点，一个知识点又可以被多个视频拥有"
由上面的分析我们已经可以确定视频类和知识点是关联关系，那我们在做指向的时候做双向箭头的话，理解起来会有问题，如：



所以我们团队的做法是根据你的业务关注程度，比如说你正在做视频有关的业务，那你就应该讲箭头指向知识点类。

可能有人觉得前面已经讲过关联关系的代码体现是成员变量吗，直接使用成员变量不就完了吗？
比如：
一对多：
一里面放一个类型为多的集合成员变量。
多对多：
双方都存放彼此类型集合的成员变量。
但是，这样我们在做数据持久的时候非常麻烦。
所以我们的做法是：
如果是一对多就在以里面存放一个多的主键ID，比如：
一个视频一定是属于某个老师的，代码如图：



如果是多对多我们采用的是关系表去做，
比如说视频和知识点的关系我们会创建一个关系表去承载这个多对对关系，在实体类中不做体现。