再回首，策略、简单工厂是否依然？

     ​这篇博客是好久之前就打好的草稿，可是一直就拖到了现在，刚好在保定上课，笔记本也排不上大用场，翻看手机，终于捡起了这些草稿，决定写完。

    再说设计模式之前，我们先说说开闭原则。

一、开闭原则（ocp)

    ​以前读这些官方解释，总是觉得很官方，现在在读，觉得句句经典。和大家共享

     ​遵循开闭原则设计出的模块具有两个主要特点：

    ​（1）对于扩展是开放的（Open for extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，我们可以增加模块的功能。

    ​（2）对于修改是关闭的（Closed for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者.EXE文件，都无需改动。

    ​注意：开闭原则是针对一个模块来说的，不然，开闭毫无意义。

    ​这两个模式是我们容易混淆的，因为从类图是看，基本是一样的。以前博客中都已经介绍过这几个设计模式，这里不做详细介绍，这篇博客是最近翻看笔记时的一点感触，来说说这两个设计模式的不同。

二、你还是你，我还是我——策略VS简单工厂

    1、问题域不同

    ​首先看一下两个模式的定义：

    ​
    ​策略模式

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

     ​简单工厂

    简单工厂模式（Simple Factory Pattern）属于类的创新型模式，又叫静态工厂方法模式（Static FactoryMethod Pattern）,是通过专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
    ​
     最主要区别是就是：策略模式为行为型设计模式，而简单工厂为创建型模式。两个设计模式解决的问题域本就不同，侧重点不一样，放开眼界，学习这两个模式，不可一起咬住不放。

    ​
    ​2、开闭原则​

     策略模式的​特点：创建，选择不同策略的责任在客户端。

     ​如果有扩展着怎么办呢？需要如下变动：

    ​    ​1：策略端增加新的策略类，无需改动已有的策略端代码————开闭原则

    ​    ​2：界面增加新策略字符串，客户端进行调用修改————客户端是无论如何都是要进行修改的。

那么我看简单工厂的特点：选择，创建的责任在算法端

     ​所以如有扩展，需要如下变动：

    ​    ​1：算法端增加新的算法类，调用算法的修改 还在 算法端，需要改动两处————违反开闭原则

    ​    ​2：客户界面增加选择新的算法的字符串————客户端是必定要修改的

    这就是区别二，一个遵循了开闭原则，一个没有。还有一点就是，并不是不遵循开闭原则就一定不好，具体还是要看需求，具体对待。

    宏观上问题域不同，细节上，是否需要遵循开闭原则，​这两点足以让我们可以适时的选择清楚简单工厂和策略模式了。​

三、策略 同 简单工厂


    两个模式不考虑问题域的话，只看类图，都是通过继承来实现子类的扩张，都能解决动态变化的功能。因此都有一些共性：

    ​优点：

　　    ​1、 简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。
　　    2、 避免程序中使用多重条件转移语句，使系统更灵活，并易于扩展。
  

　缺点：
　　   1、 因为每个具体策略类都会产生一个新类，所以会增加系统需要维护的类的数量。

总结：其实23个设计模式，非要交合在一块说，那么我想说：都是相近的，因为他们统一的宗旨是：抽象，继承，多态，封装​，所以，设计模式每个和每个都有想象的地方，或许正因为是这样，才有的设模式的三大类：创建型，结构性，行为型之分，然后，每个小的区域内，又有各个不同的侧重点。
    
    ​​这是我学习设计模式的一点小感悟：
        ​学习设计模式：不谋全局者，不足以某一域。
        ​​​使用设计模式：知其然，知其所以然。​