模式开篇，策略模式，状态模式

代码应该达到特性：

1、可维护：写过的代码很容易忘，如果按照一定模式的完成的代码有一定规律可循，方便后期维护。

2、可复用：代码重用

3、可扩展：方便业务扩展

4、灵活性好：代码生命力

面向对象特性：封装、继承、多态把程序的耦合度降低。

基本概念和关系：

1、类、对象、抽象类、接口的关系：

    类是对象的抽象

    抽象类是类的抽象

    接口还行为的抽象

一般程序员学习语言的方式：选择一门语言，熟悉使用基本语法，使用第三方库，变成过程中面向过程根深蒂固，以积累API的方式当成程序员的发展，很难有大的进步。

正确学习方式：学习设计模式基本原则，将算法和设计模式融合应用，掌握互联网存在的成熟框架核心，技术问题到实现细节中解决。程序员的价值力求达到对业务需求能提供完整的整套解决方案。

模式：每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。

GRASP通用软件职责分配原则：

1、信息专家Information Expert：一个类拥有完成该类某功能或职责的数据，那么该功能或职责就该分配给该类。

2、创造者Creator：A管理B，或A经常使用B，情况很多不一一描述；情形上类似A和B有很强的联系，A是B的领导，控制着B。

3、低耦合Low Coupling：Don't talk to strangers，意思是说类设计尽量减少建立联系，一旦建立关系，当一个类修改时，很可能影响到另外一个类。

4、高内聚High cohesion：类间的职责和功能独立，避免某个模块内部出错时不影响其他模块。

5、控制器Controller：解决事件处理职责问题。有利于事件共同处理，缩小修改范围

6、多态Polymorphism：一种实体多种表现特性，子类的多种表现形式间不互相影响。

7、纯虚构：高内聚低耦合，是系统设计的终极目标，但是内聚和耦合永远都是矛盾对立的。高内聚以为这拆分出更多数量的类，但是对象之间需要协作来完成任务，这又造成了高耦合。该如何解决这个矛盾呢，这个时候就需要纯虚构模式，由一个纯虚构的类来协调内聚和耦合，可以在一定程度上解决上述问题。合理的UML图中，只有叶子才是对象，中间节点都应该是纯虚类。

8、间接Indirection：通过中间类来减少类之间的耦合。（目前还不理解它的好处）

9、受保护变化Protected Variations：使用接口封装，OCP（开闭原则），未来发生变化，通过接口扩展，不用修改旧实现。

比模式更重要的是原则：

1、单一职责：一个类仅有一个引起它变化的原因。尽量做到单一职责，网上的例子中图形计算程序只使用了正方形的Area()方法，永远不会使用Draw()方法，而它却跟Draw方法关联了起来。这违反了单一原则，如果未来因为图形绘制程序导致Draw()方法产生了变化，那么就会影响到本来毫不关系的图形计算程序；在实际的设计中Draw()和Area()很有可能同时需要使用，根据信息专家职责分配原则很难避免不打两个类放在一起。所以在实际设计中，尽量做到单一职责并不是绝对。

2、开放封闭原则：类的设计中应该增量开发，旧代码可以扩展，但不能修改。以继承的方式增加新类。

3、依赖倒置原则：结合自己开发的例子说明。刚入手设计模式或者未熟悉设计模式的的程序员中，过程式的思维方式根深蒂固，设计类过程中往往依赖于实现的细节，层次结构不清晰，导致接口的耦合程度高，对象不稳定。 依赖倒置原则描述的是与过程式的思维相反的设计思维，抽象出来的东西才是最稳定的，细节应该依赖于抽象，抽象不应该依赖于细节。不管高层模块还是低层模块，都依赖于抽象，具体一点就是接口或者抽象类，只要接口稳定，类的更改都不会影响另一个类。

4、接口隔离原则：不要为了所谓的通用性，将无关的接口放在一起（违反单一职责原则），相当于强迫继承接口的客户去实现他们不使用的方法。

5、替换原则：子类型能够替换掉它们基类型， is-a关系必须能够保证，才算是继承。

 

策略模式：定义一系列的算法,把每一个算法封装起来, 并且使它们可相互替换，使算法独立与客户端的变化。

适用性：

1）•许多相关的类只是行为有异。
2）• 需要使用一个算法的不同变体。第一种的另外一种描述。
3）• 算法使用客户不应该知道的数据。
4）• 一个类定义了多种行为 , 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。

模式的组成：

环境类（客户）：维护一个Strategy对象，提供对Strategy的设置。

抽象策略类（Strategy）：定义所有算法的公共接口，让客户通过Strategy对象来调用接口。

具体策略类：以抽象策略类为接口实现不同的策略算法。

简单工厂模式与策略模式的区别：简单工厂模式关注的是对象的创建，策略模式关注的是对象的行为模式

备注：大话设计模式中简单工厂模式和策略模式将判断从客户端移走，可以减少客户端一定的耦合程度。

 

状态模式：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。对像取决于一个或者多个动态变化的状态，这样的对象叫做有状态的对象，状态改变时行为也随之改变。

试用性：

在下面的两种情况下均可使用State模式:
1) •  一个对象的行为取决于它的状态, 并 且它必须在运行时刻根据状态改变它的行为。

2) •  代码中包含大量与对象状态有关的条件语句

结构组成：

环境类（客户）： 定义客户感兴趣的接口。维护多个ConcreteState子类的实例，每增加一种状态，环境类就要多增加一个实例。

抽象状态类：定义一组状态转换的算法的接口，让客户来调用接口。

具体策略类：以抽象状态类为父类实现不同的接口，包含一定的状态机制（及根据不同的状态开放一定的接口，相当于if。。。else。。。语句或switch。。。case语句）。

状态模式的缺点：增加系统类和对象个数，每个State子类和环境类耦合性大，个人觉得开发中不适合应用，很明显耦合度大的程序，代码维护上会存在很大难度，分开后的if 。。。else 或者switch 。。。case结构并没有减少，加大代码的阅读难度

 

本文纯属个人学习总结，篇幅的大部分内容都来源于网络，也包含个人逻辑思维和开发经验。每个人的水平、层次、出发点不同，看客可能存在一定的误解，有写的不好的地方希望看客能共同交流。