最近研究设计模式，看类图有点发虚！有些关系搞的不是很清楚。所以整理一下：

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

@H_301_4@　类和类之间八竿子打不着那就是没关系，这个没啥歧义。

@H_301_4@　依赖@H_301_4@(dependency)

　　可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用。用带虚线的箭头。

@H_301_4@　关联@H_301_4@(association)

　　他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量；

@H_301_4@依赖和关联区别：我用锤子修了一下桌子，我和锤子之间就是一种依赖，我和我的同事就是一种关联。依赖是一种弱关联，只要一个类用到另一个类，但是和另一个类的关系不是太明显的时候（可以说是“uses”了那个类），就可以把这种关系看成是依赖，依赖也可说是一种偶然的关系，而不是必然的关系。关联是类之间的一种关系，例如老师教学生，老公和老婆这种关系是非常明显的。依赖是比较陌生，关联是我们已经认识熟悉了。

聚合(Aggregat ion)

是关联关系的一种，是强的关联关系。聚合关系是整体和个体的关系。普通关联关系的两个类处于同一层次上，而聚合关系的两个类处于不同的层次，一个是整体，一个是部分。同时，是一种弱的“拥有”关系。此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与cpu、公司与员工的关系等；表现在代码层面，和关联关系是一致的，只能从语义级别来区分；

UML图中实现使用一条带有虚心菱形的线来表示

组合(Composition)

是关联关系的一种，是比聚合关系强的关联关系。它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。Composition(组合关系)是一种强的“拥有”关系，体现了严格的部分和整体的关系，部分和整体的生命周期一致。他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束；比如你和你的大脑，window窗口和frame，在窗口中创建一个frame时必须把它附加到窗口上，当窗口消失时frame也就消失了；表现在代码层面，和关联关系是一致的，只能从语义级别来区分；

UML图中实现使用一条带有实心菱形的线来表示