23种设计模式体会

Factory（工厂模式）：对象产生过程的闭合控制
 客户端不需要关心对象的产生过程。工厂替你完成这些琐碎的事情。
 需求往往是要根据不同类型生产特定的对象。如if(test == 1){return 1;} else {return 2}。通常可以结合singleton模式，并可以通过map分类完成。

 

Builder（建造模式）：对象部件的产生过程的闭合控制
 建造模式和工厂模式的使用场景不同，建造模式更关注结果对象的组成部分，而它的目的是将各个组成部分的构建过程对外隐蔽。
 常用的例子是构建汽车的各个组成部分，但汽车这样的场景应用不会太多。
 举个更常见的例子：任务包括两个部分：任务校验器和任务执行器。对于不同任务，校验器和执行器都是不同的。
 这个时候可以用此模式，而且往往它会和工厂模式结合使用。

 

Factory Method（工厂方法模式）：职责迁移至子类工厂
 可以把工厂方法和抽象工厂看作是一个整体。
 相对工厂模式，此模式适用更加复杂的场景，创建对象由抽象工厂的子类完成。
 其实与工厂模式的根本区别就在于职责迁移。
 abstract Object getObj(); 子类返回对应的内容。

 

Prototype（原始模型模式）：对象属性生产过程的闭合控制，clone
 当几个对象的类仅在属性上存在一点差异，而行为上完全相同时。
 可以在复制一个原型对象后，对其属性进行细小的微调，从而实现定制化的目的。

 

Singleton（单例模式）：
 单例顾名思义就是个类全局只有一份实例。在spring中大量应用。

 

Facade（门面模式）：对处理逻辑的闭合控制
 此模式比较常见，比如你对外公布一个webservice，或给客户端一个调用入口。其目的就是隐藏内部的逻辑关系。
 它往往是一套处理逻辑的终极表现，下面可以包含多种模式的合成，如：工厂模式，构件模式等等。

 

Adapter（适配器模式）：
 生活中有很多Adapter的例子。比方说，你买了一款舒适、手感极佳的键盘，它是P/S接口的，然而你的新式电脑已经淘汰了P/S接口，只提供USB接口。此时，为了能够使用这款键盘，就需要一个转接头，它的一头是P/S接口的，用来连接键盘；另一头是USB的，用来连接电脑。类似这样的转接头就充当一个Adapter的作用。类似的例子还有电源的三相/两相 转接头等等。
 适配器是轻量级模式，我们在日常的开发其实会不经意的用到。

 

Bridge（桥梁模式）：
 大中小与加奶不加奶，不同组合达到不同的效果。其实也就是纵向和横向纬度的不同选择组合。

 

Composite（合成模式）：
 菜单中树形结构。其实就是树干树枝的关系，树枝也可以理解为树干，一层层嵌套。

 

Decorator（装饰模式）：
 对原对象进行扩展，有一个原对象的引用，在执行原对象前后进行其他处理。

 

Flyweight（享元模式）：
 避免大量拥有相同内容的小类的开销(如耗费内存),使大家共享一个类(元类).
 比较经典的例子就是CD，CD包含几个信息：title，year，artist。以artist为例，多张CD的artist可能一样，这样我们就可以我们就可以考虑artist作为享元。
 结合Flyweight factory，获取artist对象。（原理就是在factory里只保留一份同名的artist对象，可以用过Map保存）。
 本质上与数据库中外键比较类似。
 
Proxy（代理模式）：
 使用代理模式的两种场景：授权机制、某个客户端不能直接操作到某个对象,但又必须和那个对象有所互动。
 1：我们可以通过代理完成对原始对象和拦截器的结合，达到对原始对象访问的拦截效果。这里顺便提下spring的动态代理，让访问者都感觉不到代理存在。
 2：创建实体代理，达到间接访问原始对象的目的。一方面可以完成对触及不到对象的访问，另一方面也是原始对象的隐藏。

 

Command（命令模式）：
 在我的最初印象里，command执行的就是if(command == 1){...}else if(command == 2){...}...这样的逻辑。其实这种理解完全错误了，恰恰command是为了避免这样的hardcoding。
 怎么解释呢：现在我们把这里的command向上提一层，提高到一个Command接口，它包含一个execute方法，而if else里的实现体就一个个Command的execute的实现体。
 这样访问者所要做的执行Command的execute方法。再结合工厂模式获取相应类型Command实体给访问者，这样就很好的达到了对访问者的解放，同时被调用者也不用关心是谁访问了。
 
Interpreter（解释器模式）：
 用来解释语言的文法。实际应用不是太多。它的适用范围其实很有限。
 1：简单文法：对于复杂的文法来说，解释器模式会让类的层次复杂的难以管理
 2：效率无关：追求效率的语法解释通常使用状态机解决。
 较好应用解释器的场景：金额大小写格式的转换、定时格式等。
 以金额转换为例，可以定义个十百千万等级别的解释器，然后通过这些计时器的组合达到整个解释的目的。

 

Visitor（访问者模式）：
 此模式与Command模式有很大的相似之处。最终的目的都是让访问者与被调用者的解耦，也可以避免大量的if else硬编码，说到底就是条件外置。
 那和Command模式的区别之处在于侧重点不同，Command模式适合用于完成一整套的命令动作，而Visitor模式更适合“众口难调”的场景。

 

Iterator（迭代子模式）：
 此模式的根本目的就是为了让访问者不需要关心聚合对象的内部实现，外部不需要去关心是哪一类聚合对象。唯一需要知道的就是我可以遍历里面的内容。
 它让遍历算法从聚合对象中独立出来，达到解耦的效果。当然你还可以引入多太迭代器实现对不同聚合对象的遍历访问，让客户端真正的做到访问透明，这里可以和Factory Method结合使用。

 

Mediator（调停者模式、中介模式）：
 个人觉得中介模式更容易让人理解，就比如：买房人与卖房人的关系，是多对多的，一个买房人需要与多个卖房人打交道才能买到称心如意的房子，卖房人也是同样。
 但引入中介，这个情况就大大改善了，关系变成了一对多，而且在中介内部，买卖双方可以共享资源，我们马上就可以联想到Flyweight 模式，又是个不错的组合。
 
Memento（备忘录模式）：
 用备份这个词好像更合适，实现就是用一个保存另外一个对象内部状态拷贝的对象.这样以后就可以将该对象恢复到原先保存的状态。
 比如下一步特定条件下需要将对象信息回滚就可以用到此模式。

 

Observer（观察者模式）：  
 源-监听器（Source/Listener）模式，这个解析更容易让人理解，因为我们接触最多的就是事件发布与监听。
 我们常常说到的埋点位置就是这个Source的入口，既然下了埋点，总要让有人关心才有用。而这关心的人就是Listener，而且它也只对他订阅的主题关心。
 等等监听到它关心的主题就可以干活了。

 

State（状态模式）：
 又是一个适合减少大量if else的模式，此模式专注的是状态随着事件的变迁。像流程引擎核心功能就是此模式的具体实现。
 此模式的本质是将状态变迁的琐碎逻辑从整体逻辑中剥离，由state对象自己来维护，每个state只关心它的下一个状态。

 

Strategy（策略模式）：
 此模式主要利用组合来解藕接口与算法，使算法独立于客户变化。专注于策略、算法，像费率就是典型的应用场景。
 例子：商品出售有可能打折，有可能是满多少减多少，有可能是送购物券等等，其实每一种方式都是一种策略。
 我们可以抽象出策略接口，而每个策略我们都可以独立出一个实现类，策略组合随着需求变化而变化。
  
Template Method（模板方法模式）：
 业务有确定的骨架，只有其中的细节处理不一致，这时就可以用模板模式。像模板语言Velocity其实是差不多的思路。
 其中如果不想横向扩展类，可配合回调接口一起使用，可在不同方法中植入不同实现。
 模板方法可以是在抽象类完成，也可以单独建立模板实例，组合完成。为了减少类的继承，后者更值得推荐。

 

Chain Of Responsibleity（责任链模式）：
 如校验链的使用，链子的不同节点完成特定的任务。其中链的就是节点接口的一种实现。
 结合command模式，组装责任命令是个不错的选择。

 

总结：模式往往不会独立存在，其实到最后你会发现很多模式都会有异曲同工之妙，只有适合自己的模式，没有绝对需要的模式。它真是暗藏玄机的东西，每隔段时间来温习都会有新的体会，这种体会是靠实际应用中的经历来感悟的。这些我个人目前的理解，如有不妥之处请指正。