深夜，聊聊设计模式

我们知道，一门技术你只要花时间去看，是很快可以搞懂的，但是架构例外，设计模式作为架构的基础，也没法很快搞懂。设计模式的书都是大同小异的，书中都是理论结合一个个小例子来阐述设计模式，但是即便你把整本书全看懂了，到实际中依然会不知所措。

有些设计模式比较像，比如工厂和建造者模式，再比如代理模式和中介者模式，如何正确地区分它们？

那么多设计模式，如何在工作中使用？我怎么知道用哪种好呢？

本篇文章我来和大家谈谈，首先有几个心得，大家要赞同：

• 设计没有对错，只有好坏之分

• 个人要形成自己的架构关

• 设计的目标总是正向收益

• 设计的过程中总会带来负面收益

一个没有对错的东西，就不存在标准答案，所以一个架构师也应该有自己的架构立场。两个优秀的架构师，针对同一个东西，他们所产出的设计可能差异很大，甚至对立，但是他们的设计可能都是优秀的。

为了掌握设计模式，需要经过如下步骤。

首先要掌握六大原则的精髓：单一职责、里式替换、开闭原则、依赖反转、接口隔离、迪米特法则。

最重要的，要理解设计模式的精髓：开闭原则，“对扩展开放，对修改关闭”这句话非常重要。

然后找本设计模式的书，比如《大话设计模式》、《head first 设计模式》，搞懂23种常用的设计模式，边看书边思考。大家可以发现，23中设计模式中，很多模式都是不完美的，有些甚至还违背了6大基本原则，所以生搬硬套设计模式行不通，这也是架构不能速成的原因。但是在学习过程中，你又必须从生搬硬套开始，逐步完成升华。

最后，尝试在自己项目的局部模块生搬硬套一些设计模式，然后列出这样设计的好处和坏处，逐步思考逐步改进，慢慢找到属于自己的感觉，形成自己的设计观，这个过程只能靠自己体会。到最后你会发现，本文前面提出的问题其实不是问题，因为那根本不重要。

我给大家一些建议，评价一个设计好坏的主要因素是：

开闭性是否良好。这个设计是否可以应对未来半年到一年内的业务变动，如果每次业务变动都需要修改设计核心代码，很显然，这个设计失败了。

可维护性是否良好。或者说可读性是否良好，如果一个设计太过晦涩难懂，那一旦设计者离职，后续的代码将难以维护。记住，设计的目的是让代码更清晰易懂，而不是为了装逼。

性能。设计再牛逼，性能很差，这也是一个垃圾的设计。

最终，你应该达到高手无招的地步，你设计了一个方案，是个四不像，很难说出它是哪一种设计模式，但是它却是一个好的设计方案，这个时候你就出山了。

推荐阅读
最近聊了一些高P，我慌了
十年老码农，现场教你写简历
为了让你看技术文章，我们操碎了心。。。
编程·思维·职场
欢迎扫码关注