设计模式总结

工作一年零两个月了,对设计模式的理解总结。

使用设计模式的目的,最重要的是要让具有“可扩展性”,也就是在需求变更,或者需求增加的时候能够尽量少改动原来代码,或者不改动原来的代码只增加新的代码,从而扩展功能(这也是开闭原则吧)。最具代表性的就是在协议处理上的命令模式,需要增加一个新的协议,就增加一个新的command。但是,很容易进入一个误区,那就是过度设计,一个很简单的功能,可以使用设计模式,也可以不使用设计模式,决定是否使用的因素是什么呢?需求,需求是否很增加,是否会变化。如果一个需求基本不会有什么变化,那么使用设计模式只会增加代码的复杂性。

设计模式是怎样让代码就有扩展性的呢?同样四个字“职责转移”,命令模式是把命令发送者与执行者职责分开,把命令执行职责转移给命令执行者;观察者模式把观察者与被观察者分开,本来是观察者去主动获取被观察者的状态什么的,这个职责被转移到被观察者中,被观察者状态变化的时候会通知观察者。工厂方法,把创建对象的职责集中到一个工厂中;访问者模式,如何访问对象这个职责交给了访问者;外观模式把与复杂子系统交互的职责转移到外观当中;

工作中使用过或者遇到过的模式也不少,最常见的就是命令模式,或者是主动对象(带线程池的命令模式),大多用在协议的处理上;然后是观察者模式,第一个常用的就是协议的订阅,观察是否有协议发送处理;然后就是对设备增删改的观察,订阅者主要是设备的上报、存储告警策略等。桥接模式也较常见,有好多类xxximplemnet,这个是真正的实现者;代理模式中遇到过对一个client的proxy,很少用到代理的延迟加载的功能,这个功能可能客户端用的多;状态模式在做协议的时候处理状态机有用到;适配器模式主要是封装sdk接口比较常见;中介者模式工作用的也不多,但是系统架构有点像一个中介者,一个中心,多个特定业务服务器,也有点像分布数据库一个中心数据库,多个业务数据库。把相互之间的依赖转成对中心的依赖,虽然用的不多,但是这个模式应该是很强大的,在代码优化的时候,去除蜘蛛网状的依赖关系。访问者模式在设备访问时候有用到;建造者模式在构造协议的时候有用到;原子模式、外观模式、工厂方法、单例比较常见了。其他备忘录、享元、组合、责任链、装饰者模式目前没有用到过。

2020-05-21

参考

软件设计的依赖倒置原则:如何不依赖代码却可以复用它的功能?

Table of Contents