设计模式总结

       还记得大三的时候想学习下设计模式，泛读了下觉得在当时根本用不上，就放下了。转眼过去了三年，做了些项目，期间也接触到了设计模式。感觉很有必要系统的学习下。感触最深的是以前写的代码难以重用、可维护性差、封装性也惨不忍睹。所以还是得老老实实的来走一遍传说中的------“设计模式”。

1、避免代码中出现多的重复的代码，否则难以维护。尽量封装成公共接口供调用。

2、.将业务逻辑与界面逻辑分开，使得一个业务逻辑可以对应多个界面逻辑。业务逻辑的接口中的输入输出参数与界面输入输出（显示）相对应。

3、代码可扩展，当对程序扩展功能时，应该尽可能少的影响源代码的结构，这里考虑使用继承和多态。

4、面向对象编程中，并不是类越多越好，类的划分是为了封装，具有相同属性和功能的对象的抽象集合才是类。

5、软件设计真正要做的就是发现职责，并把这些职责分离开来。

策略模式：

1、定义

策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法的变化不会影响到使用算法的客户。

2、组成：

抽象策略类(Strategy):定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，Context使用这个接口调用不同的算法，一般使用接口或抽象类实现。

具体策略类(ConcreteStrategy)：实现了Strategy定义的接口，提供具体的算法实现。

环境类（Context）：需要使用ConcreteStrategy提供的算法,维护对一个Strategy对象的引用。可定义一个 接口来让Strategy访问它的数据。

3、适用范围

针对具体一功能具有多种算法，比如查找、排序、计算成都到北京的费用（高铁、飞机、客运）等等。每一种方法都能得到相同的结果，但是具体实现过程（算法）不同。客户端只需要通过公共接口调用，无需知道具体算法的实现过程。

4、优点

策略模式中的Strategy类为Context提供了一系列可供重用的算法，继承有助于继承有助于析取出这些算法中的公共功能。

当不同的行为堆砌在一个类中时 ,很难避免使用条件语句来选择合适的行为。将行为封装在一个个独立的Strategy类中消除了这些条件语句。含有许多条件语句的代码通常意味着需要使用Strategy模式。----用策略模式来封装变化，【变化】特质是针对同一要求、功能带来的变化。

      Strategy模式提供相同行为的不同实现模式，客户根据需要选择对应的策略模式。

单一职责原则：

就一个类而言，应该仅有一个引起它变化的原因。即一个类只负责一项职责。

如果一个类承担的职责过多，把各种各样的职责耦合在一起，那么一个职责的变化可能引起4诸多职责的变化，当需求变化时，这种设计引来的一连串变化是难以估计的。

优点：1、可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；

2、提高类的可读性，提高系统的可维护性；

3、变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。

 需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。

开放封闭原则：

1、软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。对于扩展是开放的,对于更改是封闭的。关键是抽象，将一个功能的通用部分和实现细节部分清晰的分离开来。

2、通过有效预测软件可能发生的变化，然后构造抽象来隔离那些变化。这样当变化发生时，我们能在不花较大代价的前提下（修改原来的类结构）达到满足新需求的程度。

3、核心思想：对程程序的改动是通过增加新代码进行的，而不是更改现有的代码。开发人员主要对程序中频繁变化的那些部分做出抽象，而不是抽象所有部分。

4、开放封闭原则还可以统一起来理解。由于我们对扩展实现了开放，才能够保证对修改是封闭的。开放利用了对象的抽象，封闭则在一定程度上利用了封装。最佳的做法仍然是要做到分离对象的变与不变，将对象不变的部分封装起来，并遵循良好的设计原则以保障接口的稳定；至于对象中可能变的部分，则需要进行抽象，以建立松散的耦合关系。实际上，开放封闭原则也体现了依赖倒置原则的思想。

依赖倒转原则：

1、高层模块不应该依赖于低层模块，两个都应该依赖抽象

2、抽象不应该依赖于细节，细节应该依赖抽象。即：要针对接口编程，不要针对实现编程。

里氏代换原则：子类必须能够替换掉他们的父类型。只有子类能够替换掉父类，父类的功能接口才能被真正的复用，而子类也能在父类的基础上增加新的行为。