设计模式——开篇

      终于决定写设计模式这个系列的文章了，从事软件开发这3年多来，面对纷繁的技术，却慢慢迷失了自己，看的多了，学的多了，到头来每种都会一点，却每种都是一知半解，于是下定决心寻找软件世界最本质的东西——软件的哲学。决定先从设计模式下手，从软件最细小的颗粒着手，慢慢领悟软件架构的威力。熟悉设计模式首先得对UML类图有深入的了解，下面的图解是为了帮助我能更好的记住他们。

     UML中描述对象和类之间的关系包括：依赖，关联，聚合，组合，泛化，实现等。

• 依赖（Dependency）：B的变化影响A，反之则不成立，那么AB之间形成依赖关系，A依赖B；总是单向的(一般不应该存在双向依赖)。

           表示方法：虚线加箭头。箭头指向被依赖的元素，这里表示为A------>B。

           特点：当类与类之间有使用关系时就属于依赖关系，不同于关联关系，依赖不具有“拥有关系”，而是一种“相识关系”，只在某个特定地方（比如某个方法体内）才有关系。

public class Person
{
   public void Drink(Water water)
   {
      // TODO: implement
   }
}

• 关联（Association）： 元素间的结构化关系，是一种弱关系，被关联的元素间通常可以被独立考虑；类与类之间的联结，它使一个类知道另一个类的属性和方法；可以是双向或者是单向（也可以自身关联）。

           表示方法：实线箭头，箭头指向被依赖元素；箭头上的数字范围称为多重性关联关系，表示两个关联对象在数量上的对应关系：一对一，一对多，多对多。

           特点：表示类与类或类与接口之间的依赖关系，表现为“拥有关系”，具体代码可用实例变量来表示。

public class Teacher
{
   private Student[] Students;
}

• 聚合（Aggregation）： 关联关系的一种特例，表示部分和整体的关系（整体 has a 部分），表示一种弱的“拥有关系”，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。比如：发动机是汽车的组成部分，但是发动机可以独立存在，因此发动机和汽车是聚合关系。

           表示方法：空心菱形的实线，菱形头指向整体。

           特点：在代码实现聚合关系时，部分对象通常作为构造方法、业务方法的参数注入到整体对象中。

public class Car
{
   public void SetEngine(Engine Engine)
   {
      this.Engine = Engine;
   }
   
   public Car(Engine Engine)
   {
      this.Engine = Engine;
   }

   private Engine engine;

}

• 组合（Composition）：关联关系的一种，聚合关系的变种，表示一种强的“拥有关系”，体现了严格的部分和整体关系，部分和整体的生命周期一样。一旦整体对象不存在，部分对象也将不存在。比如：四肢是人的一部分，但四肢没法脱离人而独立存在，因此人和四肢是组合关系。

           表示方法：实心菱形的实线，菱形头指向整体。

           特点：在代码实现组合关系时，通常在整体类的构造方法中直接实例化部分类。

public class 人
{
   public 人()
   {
      z=new 肢();
   }

   public 肢 z;

}

• 泛化（Generalization）： 通常所说的继承关系（特殊个体 is kind of 一般个体）。比如：Student类和Teacher类都是Person类的子类。

           表示方法：用带空心箭头的实线表示，箭头指向一般个体。

• 实现（Realize）： 元素A定义一个约定，元素B实现这个约定，则B和A的关系为：B实现A，这个关系最常用在接口中。

           表示方法：空心箭头和虚线表示，箭头指向定义约定的元素。