对于很多刚刚接触UML的童鞋，可能会对类之间的关联与依赖关系不太理解，今天小菜就浅薄的讲一下。
这块的确是有点乱，不过小菜突然找到了一个比较好的切入点，拿出来分享一下。
接触过设计模式的读者，会经常看到这样的场景：在实例化A类的时候，需要B类作为构造方法的参数，这说明A类需要持有一个B类的引用。比如代理模式、装饰模式等，都会这样做。例如Java中的IO流采用的就是装饰模式，所以我们会经常看到这样的语句：new BufferInputStream(new FileInputStream("c:\\1.db"));
这种持有引用，就是简单的关联关系。在代码中表现为：在A类中有一个 成员变量 ，变量的类型是B类，A类中持有了B类的引用，就说明A类和B类发生了关联关系。
用UML图表示如下：
稍加说明，由于是A类持有B类的引用，因此关联是从A类中发出的(由A类引起)，因此箭头要从A类指向B类。
通常情况下，这种简单的单向关联就够用了，但是关联关系主要还是应用在数据库设计中。
在数据库设计中，无论是一对一、一对多、多对多，都不是单向的。
从表的角度分析，它们均可以从任意一端确定另一端。就拿一对多来说，有了one端的主键，可以根据many端表的外键查出many端数据；有了many端外键，可以根据one端表的主键查出one端数据。
从实体类的角度分析，同样可以从任意一端确定另一端。还是拿一对多来说，one端的实体类会持有一个many端的引用集合，例如private Set<B> bs;，查询到了one端，可以直接从这个集合中读取many端；many端的实体类会持有一个one端的引用，例如private A a;，查询到了many端，可以直接从这个引用确定每一个many端的one端。
这样一来，就成了双向关联，用UML画关联关系的时候，两边都要加箭头，这样太难看，索性就都不加了。
例如部门实体类和员工实体类的关系，就可以这样表示：
由于是数据库实体类间的关联关系，因此还要加上数量关系，1代表one端，0..n代表many端，说明一个部门可以有多个员工，但一个员工只能属于一个部门，通过UML图描述了一对多。
这个才是关联关系典型的应用。
不得不提的是，关联关系还可以细分为聚合和组合(二者的具体概念读者自行搜索)。
小菜发现聚合、组合可以从另一个角度去理解。
先说说聚合，它是一种弱关联，大概意思就是整体和部分可以独立存在。如果我们换个角度，可以看成是数据库的级联操作。
就拿小组和组员来说，删除某个小组的时候，把该组的组员也删除，这显然是不科学的，因为小组和组员是一种弱关联，小组可以拥有任意一个组员，一个组员也可以去任意一个小组，这个小组不存在了，可以去另一个小组，它们没有必然的关联，可以称为聚合。
因此，我们在设计数据库的时候，往往不会设置级联删除，也就是说，删除小组时不会删除组员。
UML图表示如下：
空心菱形表示聚合，指向one端。
再说说组合，组合是一种强关联，大概意思是整体和部分不可分割，不能独立存在。同样从级联操作理解。
就拿学生和学生证来说，假如某个学生退学，不再属于这个学校，那么可以考虑将该学生信息删除，删除的时候，学生对应的学生证信息也会被删除，在此处可以加级联删除。因为学生证属于某个学生专有的信息，学生不存在了，学生证又不能让他人使用，因此是一种强关联，可以称为组合。
UML图表示如下：
最后要谈的是依赖关系。
假如A类的某个方法中，使用了B类，那么就说A类依赖于B类，它们是依赖关系。
A类的某个方法使用B类，可能是方法的参数是B类，也可能是在方法中获得了一个B类实例。但无论是哪种情况，B类在A类中都是以 局部变量 的形式存在的。
因此，A类中有B类型的局部变量，就说A类依赖于B类。
UML图表示如下：
虚线箭头表示依赖，箭头指向被依赖的类。
综上，有一个简单的判断原则：某个类以 成员变量 的形式出现在另一个类中，二者是关联关系；某个类以 局部变量 的形式出现在另一个类中，二者是依赖关系。
注意： 本文为了方便讲解，一直是拿类当例子，这并不是一种好的设计思维。实际开发中，为了更好的实现"开-闭原则"，一般都是定义接口，依赖于接口，依赖于抽象，而不是根据具体编程，希望读者不要被小菜误导！！
小菜水平有限，就先谈到这，文章如有不当之处请见谅，欢迎与我交流！
