具体设计模式选择

见解：     设计模式是经验，我们需要先知道每种设计模式所解决的问题，
               然后什么时候使用。
               代码是思想的具体化，先有想法然后再是代码

具体设计模式选择：

        1.单列模式
             解决问题：一个全局使用的类频繁地创建与销毁
             何时使用：当你想控制实列数目，节省系统资源的时候
        2. 原型模式
             解决问题：在运行期建立与删除原型
             何时使用：
             注意点： 深拷贝，浅拷贝  关键看对象中是否包含引用，深拷贝引用对象会重新拷贝，浅拷贝引用对象不会拷贝 
        3. 建造者模式
             解决问题: 复杂对象的创建工作，这个复杂对象的各个部分经常变化，但将它们组合在一起的算法相对稳定
             何时使用：一些基本部件不会变，而其组合经常变化
       4. 工厂模式
             解决问题：接口选择的问题
             何时使用：明确的计划不同条件下创建不同实列
       5. 抽象工厂模式
             解决问题：接口选择的问题
             何时使用：系统的产品多于一个的产品族，而系统只消费其中某一族的产品      

      6.适配器模式
              解决问题：现存对象不满足新环境要求
              何时使用：系统需要使用现有的类，但此类的接口不符合系统的需要
      7. 桥接模式
               解决问题：在有多维度会变化的情况下，用继承会造成类爆炸问题，扩展起来不灵活
               何时使用：实现系统可能有多个维度变化，每一种维度都可能变化
       8.过滤器模式
                解决问题：使用不同的标准来过滤一组对象
                何时使用： 通过逻辑运算以解耦的方式
      9.组合模式
                解决问题：客户程序与复杂元素的内部结构解耦
                何时使用：部分整体层次结构， 忽略组合对象与单个对象的不同
       10. 装饰器模式
                解决问题： 通过继承扩展一个类，当扩展功能的增多，子类会很膨胀
                何时使用： 在不想增加很多子类的情况下扩展类
        11. 外观模式
               解决问题：降低访问复杂系统的内部子系统的复杂度，简化客户端与之的接口
               何时使用： 客户端不需要知道系统内部的复杂联系，   定义系统的入口
        12.享元模式
               解决问题：有大量对象，可能会造成内存溢出
               何时使用：连接池，常量池
        13.代理模式
                解决问题：直接访问会给使用者或者系统结构带来很多麻烦，可在访问此对象时加上一个对
                                 此对象的访问层。
                 何时使用：想在访问一个类时做一些控制
      14. 责任链模式
               解决问题：将请求的发送者和请求的处理者解耦
               何时使用：在处理消息的时候需过滤很多道
      15. 命令模式
               解决问题： 无法抵御变化的紧耦合的设计
               何时使用： 将行为请求者和行为实现者解耦   redis 很多的命令
     16. 解释器模式
               解决问题： 对于一些固定文法构建一个解释句子的解释器 ：xml，word，csv 等可以解释的
               何时使用： 一种特定类型的问题发生的频率足够高，就可将问题抽象为一个简单语言中的句子，
                构建一个解释器，该解释器通过解释这些句子来解决问题。
     17. 迭代器模式
               解决问题：不同的方式来遍历整个整合对象
               何时使用： 遍历一个聚合对象
      18.中介者模式
                解决问题：对象与对象之间存在大量的关联关系
                何时使用： 多个类相互耦合，形成了网状结构
     19. 备忘录模式
                解决问题： 在对象之外保存对象的一个内部状态，之后可以将对象恢复到原先保存的状态
                何时使用： 允许用户取消不确定或者错误的操作，恢复到他原先的状态
      20.观察者模式
                解决问题：一个对象状态改变给其他对象通知的问题
                何时使用：一个对象的状态发生改变，所有的依赖对象将收到通知
      21.状态模式
                解决问题： 对象的行为依赖于它的状态，并且可以根据它的状态改变而改变它的相关行为
                何时使用： 代码中包含大量与对象状态有关的条件语句
      22.策略模式
                解决问题： 在有多种算法相似的情况下，使用if...else 所带来的复杂和难以维护
                何时使用： 一个系统有许多许多类，而区分它们的只是它们直接的行为
     23. 模板模式
                解决问题：一些方法通用，却在每一个子类都重新写了这一方法
                何时使用： 有一些通用的方法
     24. 访问者模式
               解决问题： 稳定的数据结构和易变的操作耦合问题
               何时使用： 

      25. 传输对象模式
               解决问题： 客户端与服务端的数据交互
               何时使用： 

      ......

       参考： https://www.runoob.com/design-pattern/design-pattern-tutorial.html