漫谈模式之基于抽象与多态的模式变形思考

较早以前，一个小伙伴问我：“孟君，这么多设计模式的结构你是怎么记住的？我好像老是忘记”。回想一下，我上次特意去记忆应该是大学备战设计模式课程考试的时候。

其实，随着自己对设计原则理解的加深，以及工作经验的沉淀，好多设计模式的主要结构是很容易画出来的。因为，到后面，你会发现好多模式是在抽象和多态的基础上，基于不同的目的不断变化过来。

本文，我抛砖引玉一下，分享一点小小的经验。

问题：如何不修改源代码而改变它的行为？也即，对扩展开放，对修改封闭。

答案就是：抽象与多态。

抽象可以满足扩展，多态支持个性化。接下来，我们来看看他们的魔法效果吧。接下来，将下图作为讲解的基础结构。

图片

基于抽象和多态的模式变形

策略模式

图片

在此基础上，如果增加一个上下文Context，上下文还包含一个方法来设置当前要使用的具体策略，这使得客户端可以根据需要轻松地更改算法的行为。

图片

这样就形成了策略模式。

责任链模式

图片

在此基础上，如果Handler需要指定后继（succesor），形成一个链。

图片

这样就形成了责任链模式。

组合模式

图片

如果具体的节点，分为叶子结点和组合结点（组合结点为树形结构），

图片

这样就形成了组合模式。

代理模式

图片

如果想对具体的主题进行访问控制。增加一个Proxy，其方法调用真实主题的方法，不过前后可以补充内容，比如记录操作时间或者判断是否有数据权限等。

图片

这就形成了代理模式。

装饰者模式

装饰模式的思考和代理差不多，换成装饰器，每个具体装饰器可以增加新的方法用于增强，大家可以思考一下。

图片

模版方法模式

如果具体的实现有相关的步骤，比如：有不同渠道去扣税，每个渠道的输入报文各不相同，但是，其大致的流程有类似性：

图片

这样的场景，基类里面可以定义一个模版方法（指定按照步骤执行的方法），个性化的方法，用abstarct修饰，并由子类具体实现。

图片

这就形成了模版方法模式。

桥接模式

如果左边图形的抽象，以及右侧涂色的实现，通过复合的关系关联起来，这样就形成了桥接模式。

图片

本文先给出几个，让大家感受一下。

有兴趣的读者，还可以使用相同的套路继续去思考其他的模式，比如，状态模式、访问者模式、解释器模式等等。