常用设计模式之装饰器模式、模板方法模式

　　装饰器模式

　　装饰器模式个人理解，是一种将核心功能和边缘功能区分的一种解耦方式，而装饰的过程，类似一种面向过程的实现，涉及到调用链、先后顺序等，不同的调用顺序，装饰器表现出来的外观也不一样，在大话一书中，可能就类似先穿什么衣服，然后再穿什么衣服，而顺序不一样，可能就会出现内衣外穿超人的外观出现。这样一来，考虑到顺序的话，其实更像数学中的排列了，而不是仅仅是组合了。比如在上传图片这一功能实现上，有三个配置项：给图片加水印，压缩图片、可配置压缩宽高，保留原图，如果有顺序参与进来的话，不仅仅是七种情况了，比如先压缩，后加水印，和先加水印，再压缩。

　　具体哪些情况下要用到装饰器模式，一个就是出现多种情况，如有配置项，此时核心功能（对象）需要表现出一些不一样的外观来（属性方法等），在不改变原对象的基础上，通过对其进行包装扩展（添加属性或方法等），使原有对象可以满足用户的更复杂需求，满足开闭原则，也不会破坏现有的操作的一种低成本设计模式。 装饰器模式是一个对象嵌入到另一个对象中去，实际上相当于这个对象被另一个对象包装起来，形成一条包装链。请求随着这条链依次传递到所有的对象，每个对象都有处理这请求的机会。

 

 

　　模板方法模式

　　世上本没有路，走的人多了，也就成了路。而走的最多的路，也就是套路。模板方法可能平时一直在用，只是没有意识到、没有察觉到而已，比如SA中的内容管理的五个模型，继承自BaseContentController，而BaseContentController又继承自AdminSubordinateController，这么一说，其实模板方法应该是应用最多的设计模式了，基本上只要含有继承的父类子类，大部分都会实现模板方法。模板方法消除了大量的重复代码、重复方法。

　　具体哪里用到呢，子类中类似的方法、相同的方法、多个地方用到的方法，都可以提炼封装到父类中，形成模板方法，如果子类有特例，需要有一些不同的地方，可以使用类似OnEditExecuting等方法的钩子函数，将变化封装、延迟到子类中实现。模板方法在重构、消除重复代码时很有用，封装了不变，将变化也可以单独提取出来，类似钩子函数，和模板方法配合使用。

 

　　常用设计模式感想 

　　要针对接口编程，还是要把变化封装起来，做到高内聚、低耦合，对外展示的是一系列协议，而不是具体的实现，这样一来想怎么实现就怎么实现。 

　　终于讲到各种设计模式了，记忆最深的是，讲到几乎所有的包含不限于判断、计算等的模块，都可以用策略模式+简单工厂来实现。其实经过这么多年的coding，什么情况是最头疼呢，大概就是遇到数不尽的if...else判断了，几乎面向过程一样的编程，大概有那么一部分人会用switch...case来替代，实质还是面向过程，违反开闭原则。再进一步怎么改进、改善呢，有请策略模式+简单工厂出场，再进一步呢，可能是状态机or有限状态机或者行为树？

 　　设计模式大约是解决一类问题的“银弹”了，可也不能为了设计模式而强行设计模式，那就是过度设计了，就像微服务流行的时候，无论有没有需求，都一蜂窝的上马微服务、技术中台，结果有可能因为技术不成熟，导致微服务的可靠性还没单一服务可靠性高。

 　　一些话，老板是请你们来赚钱的，不是来修复bug的，企业的天职就是追求利润，有利润了，自然有就业，有员工，有纳税，就是对国家做贡献。那么该如何发挥主观能动性呢，让你敲的代码尽可能少的bug，尽可能少的返工，就技术角度来讲，自然是往好的代码上靠拢，什么是好的代码，符合六大原则，开闭、单一职责，这个角度来讲，设计模式也是一系列原则的集合体，比如策略模式、简单工厂模式，将变化封装。另一方面，技术人员需要懂一些业务逻辑（并不是代码层面的，而是产品方面的）、懂一些产品、运作逻辑，从而能够在稍微大一点、广阔一点的角度不犯错，随着时代的发展，纯粹的技术人员大概就是一个工具人了。最近开发，遇到很多稀奇古怪的问题，大多数是那种本可以避免的问题，前车之鉴吧，成功的经验就是能够避开那些失败的地方。