大话设计模式（一）

以前做项目，只知道实现功能，没有什么思考和优化。今年要找工作，看了一些书，对代码的理解和追求有以下变化：

“代码无错就是优”（实现功能）—>“代码效率”（数据结构和算法）—>“代码的易维护、易扩展、易重用”（面向对象和设计模式）

下面介绍一下学习的几个设计模式：

1.简单工厂模式

解决对象的创建问题。

服务端：一个抽象父类（抽象方法），多个子类（重写抽象方法），工厂类中定义public静态方法传入不同参数，实例化不同子类，以父类的身份return。

客户端：使用工厂类的public static方法，传入不同参数，生产不同的对象，调用父类的抽象方法（多态）。

2.策略模式——商场促销

封装算法（策略）的变化，策略可以相互替换。

服务端：和工厂模式一样，定义父类和子类；定义Context类维护对策略对象的引用

Class Context{        Strategy strategy; //策略抽象父类        public Context(Strategy strategy){                  this.strtegy = strategy;        }         //上下文接口          public void contextInterface(){                   strategy.algorithm();         }}

客户端：new Context(instance).contextInterface();

**跟简单工厂模式的异同：

(1)两者的父类和子类定义相同

(2)工厂类中生产工厂的函数传入的参数是生产不同对象的标识，而策略模式中Context类构造函数传入的是某个子类的实例

(3)策略模式Context类中封装了对抽象父类方法的调用（contextInterface()），而在工厂模式中需要在客户端调用父类的抽象方法

**策略模式可以和工厂模式结合：在Context构造方法中实现类似工厂生产对象的方法，传入标识，而不是对象实例。这样客户端只需要认识Context类，而不需要像工厂模式中那样，客户端需要认识Factory和抽象父类。

3.单一职责原则

就一个类而言，应该仅有一个引起它变化的原因。

发现职责并把那些职责相互分离。

4.开放-封闭原则

软件实体（类、模块、函数等）应该可以扩展，但是不可以修改，对扩展开放，对更改封闭。

在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。

比如：编写一个加法的运算，以后增加减法的运算，就可以把原来加法的运算扩展成一个抽象运算父类，加法和减法都成为子类，这样以后要增加乘法除法时，只需增加两个新类继承抽象父类，而不用更改其他代码。

对程序中呈现频繁变化的那些部分做出抽象。