设计模式总结
工作一年零两个月了，对设计模式的理解总结。
使用设计模式的目的，最重要的是要让具有“可扩展性”，也就是在需求变更，或者需求增加的时候能够尽量少改动原来代码，或者不改动原来的代码只增加新的代码，从而扩展功能（这也是开闭原则吧）。最具代表性的就是在协议处理上的命令模式，需要增加一个新的协议，就增加一个新的command。但是，很容易进入一个误区，那就是过度设计，一个很简单的功能，可以使用设计模式，也可以不使用设计模式，决定是否使用的因素是什么呢？需求，需求是否很增加，是否会变化。如果一个需求基本不会有什么变化，那么使用设计模式只会增加代码的复杂性。
设计模式是怎样让代码就有扩展性的呢？同样四个字“职责转移”，命令模式是把命令发送者与执行者职责分开，把命令执行职责转移给命令执行者；观察者模式把观察者与被观察者分开，本来是观察者去主动获取被观察者的状态什么的，这个职责被转移到被观察者中，被观察者状态变化的时候会通知观察者。工厂方法，把创建对象的职责集中到一个工厂中；访问者模式，如何访问对象这个职责交给了访问者；外观模式把与复杂子系统交互的职责转移到外观当中；
工作中使用过或者遇到过的模式也不少，最常见的就是命令模式，或者是主动对象（带线程池的命令模式），大多用在协议的处理上；然后是观察者模式，第一个常用的就是协议的订阅，观察是否有协议发送处理；然后就是对设备增删改的观察，订阅者主要是设备的上报、存储告警策略等。桥接模式也较常见，有好多类xxximplemnet，这个是真正的实现者；代理模式中遇到过对一个client的proxy，很少用到代理的延迟加载的功能，这个功能可能客户端用的多；状态模式在做协议的时候处理状态机有用到；适配器模式主要是封装sdk接口比较常见；中介者模式工作用的也不多，但是系统架构有点像一个中介者，一个中心，多个特定业务服务器，也有点像分布数据库一个中心数据库，多个业务数据库。把相互之间的依赖转成对中心的依赖，虽然用的不多，但是这个模式应该是很强大的，在代码优化的时候，去除蜘蛛网状的依赖关系。访问者模式在设备访问时候有用到；建造者模式在构造协议的时候有用到；原子模式、外观模式、工厂方法、单例比较常见了。其他备忘录、享元、组合、责任链、装饰者模式目前没有用到过。