设计模式（一）设计模式的分类与区别

  本系列文章共分为六篇：     设计模式（一）设计模式的分类与区别     设计模式（二）创建型模式介绍及实例     设计模式（三）结构型模式介绍及实例     设计模式（四）行为型模式介绍及实例（上）     设计模式（五）行为型模式介绍及实例（下）     设计模式（六）设计模式的常见应用

  设计模式，实质上是一套被反复使用的代码设计经验，它提供了在软件设计过程中重复性问题的解决方案。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。   设计模式的本质是建立在对类的封装性、继承性和多态性以及类的关联关系和组合关系等充分理解的基础上，对面向对象设计原则的实际运用。

  【对扩展开放，对修改关闭】   在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码。   可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。   抽象的设计方式灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。同时软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需根据需求重新派生一个实现类来扩展功能即可。

  【任何父类可以出现的地方，子类一定可以出现】。   该原则是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用。   实现开闭原则的关键步骤就是抽象化，而父类与子类的继承关系就是抽象化的具体实现。因此，里氏代换原则是对开闭原则的补充。   该原则简单来说，就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。其具体体现为：

如果程序违背了里氏替换原则，就需要取消原来的继承关系，重新设计它们之间的关系。

  【程序要依赖于抽象接口，不要依赖于具体实现】。   该原则其定义中包含了三层含义：

1>高层模块不应该依赖低层模块，两者都应该依赖其抽象。 2>抽象不应该依赖细节。 3>细节应该依赖抽象。

  依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。   该原则的核心思想是：要面向接口(接口或者抽象类)编程，不要面向实现(具体的实现类)编程。在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多(这里的抽象指的是接口或者抽象类，而细节是指具体的实现类)。

  依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，在实际开发中，该原则的具体体现为：

  【一个类应该有且仅有一个引起它变化的原因，否则类就应该被拆分】。   如果一个类承担了太多的职责，至少存在以下两个缺点：     1） 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力。     2）当客户端需要使用该对象的某一个职责时，不得不同时实现其他职责，从而造成冗余代码或代码的浪费。

  单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点：

  如果一个类承担的责任过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。   软件设计要做的很多内容，就是发现职责并把那些职责相互分离。至于判断的标准，就是：如果能想到多余一个的动机去改变一个类，那么这个类就具有多于一个的职责。   单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

  【一个类对另一个类的依赖应该建立在最小的接口上】   接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的，区别如下：

  在具体应用接口隔离原则时，需要从以下几个方面考虑：

  隔离：建立单一接口，不要建立臃肿庞大的接口；即接口要尽量细化，同时接口中的方法要尽量少。   接口隔离原则与单一职责原则的不同：接口隔离原则与单一职责的审视角度是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。

  【只与你的直接朋友(前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等)交谈，不跟“陌生人”说话】。   其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。该原则的目的是降低类之间的耦合度，提高模块的相对独立性。   从迪米特法则的定义可知，它强调以下两点：

  所以，在运用迪米特法则时要注意以下 6 点：

  【尽量先使用组合、聚合等关联关系来实现，其次才考虑使用继承关系来实现】。   如果要使用继承关系，则必须严格遵循里氏替换原则。   采用组合或聚合的方式复用类时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点：

  常规的分类方式是根据其作用来划分，总共有三类：创建型模式、结构型模式和行为型模式。   在理解设计模式时，可以先重点关注其特点，再探究其适用场景。

  该模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用new运算符直接实例化对象，它的主要特点是将对象的创建与使用分离。   该类别包括5种具体的模式：

 一句话简单理解5种创建型模式：

  该模式关注类和对象的组合，即如何将类或对象按某种布局组成更大的结构。   该类别包括7种具体的模式：

 一句话简单理解7种结构型模式：

  该模式用于描述类或对象之间怎样通信、协作共同完成任务，以及怎样分配职责。   该类别包括11种具体的模式：

 一句话简单理解11种结构型模式：

  先看一个比较复杂的UML类图：

此时需要注意前面的符号，“+”表示public，“-”代表private，“#”代表protected。

 示例：

  泛化（generalization）关系时指一个类（子类、子接口）继承另外一个类（称为父类、父接口）的功能，并可以增加它自己新功能的能力，继承是类与类或者接口与接口最常见的关系，在Java中通过关键字extends来表示。   继承关系用空心三角形+实线来表示。              示例：

  实现（realization）是指一个class实现interface接口（一个或者多个），表示类具备了某种能力，实现是类与接口中最常见的关系，在Java中通过implements关键字来表示。   实现关系用空心三角形+虚线表示。                示例：

  关联关系体现的是两个类，或者类与接口之间的强依赖关系。   在Java中，关联关系是使用实例变量来实现的。   关联关系用实线箭头表示。                示例：

  聚合（aggregation）是关联关系的特例，是强的关联关系，聚合是整个与个体的关系，即has-a关系，此时整体和部分是可以分离的，他们具有各自的生命周期。   聚合关系也是使用实例变量来实现的，在java语法上区分不出关联和聚合，关联关系中类出于一个层次，而聚合则明显的在两个不同的层次。   聚合关系用空心的菱形+实线箭头来表示。                 示例：

  组合（compostion）也是关联关系的一种特例，体现的是一种contain-a关系，比聚合更强，是一种强聚合关系。它同样体现整体与部分的关系，但此时整体与部分是不可分的，整体生命周期的结束也意味着部分生命周期的结束。   组合关系用实心的菱形+实线箭头来表示。            同时，组合关系的连线两端还可以有一个数字“1”和数字“2”，这被称为基数，表明这一端的类可以有几个实例，一个鸟很显然应该有两只翅膀。如果一个类有无数个实例，则就用“n”来表示，关联关系、聚合关系也可以有基数的。            示例：

  依赖（dependency）关系也是表示类与类之间的连接，表示一个类依赖于另外一个类的定义，依赖关系时是单向的。简单理解就是类A使用到了类B，这种依赖具有偶然性、临时性，是非常弱的关系。但是类B的变化会影响到类A。   在java中，依赖表现为：局部变量，方法中的参数和对静态方法的调用。   依赖关系用虚线箭头来表示。

               示例：

  其实深拷贝就是基于浅拷贝来递归实现具体的每个对象。   在一些重复创建对象的场景下，我们就可以使用原型模式来提高对象的创建性能。如循环体内创建对象时，我们就可以考虑用clone的方式来实现，示例：

  享元模式是运用共享技术有效地最大限度地复用细粒度对象的一种模式。该模式中，以对象的信息状态划分，可以分为内部数据和外部数据。内部数据是对象可以共享出来的信息，这些信息不会随着系统的运行而改变；外部数据则是在不同运行时被标记了不同的值。   享元模式在实际开发中的应用也非常广泛。例如Java的String字符串，在一些字符串常量中，会共享常量池中字符串对象，从而减少重复创建相同值对象，占用内存空间。