“一个设计模式引发的血案”

虽然作为一个菜鸡，可能还谈不上架构，但是就像说说自己的一些想法。

01 一个设计模式引发的血案

事情要从 2018.8.30 晚上说起。

由于心血来潮，想想也没事情干，就啃完了阮一峰的《ES6 入门》。看到最后几章中提到了 Decorator（修饰器），感觉很新奇。好像 OC 中没有类似的语法糖，但是在 Java 中见过。但是心想，不就一个装饰器模式么？有啥好特别的，当时也没有多想，就合上书，睡觉去了。

第二天，也不知道哪根筋搭错了，就问起了大佬。

• 大佬，OC 中好像没有装饰器模式？Java 和 JS 中貌似都有语法糖的样子？

• cocoa touch 里面没见过。

（黑人问号？？？）

• category 不算么？装饰器模式不就是对于类的方法或者变量的补充么？

• category 跟典型的 decorator pattern 不太一样，decorator 实例会有一个指向原实例的指针，原实例没有被改变，还可以独立使用，category 的话，就不是这样，decorator 就像是消音器，可以拆卸，category 是把枪械的设计图纸改了。”

？？？ 难道是我记错了

基于好奇心，去 wiki 上查了下， wiki 的解释如下。

What problems can the Decorator design pattern solve?

Responsibilities should be added to (and removed from) an object** dynamically at run-time**.

A flexible alternative to subclassing for extending functionality should be provided.

Emmmmm 好像不是。不死心的我，建了个工程试了下，好像还真不是。就算没有引用 category file 也能正常通过 performSelector 直接调用。又记起 category 还像是在编译期加入方法的，当时的我

学艺不精，告辞！！！

02 “术”与“道”

当然，摸到大佬的腿肯定就不能这么轻易放开的。

• 那么，怎么才能成为和大佬一样的人呢？对于那么多细节上的点就都熟记于心呢？

• Emmmmmmm...... 实际上，设计模式的书我都没看过

• 实际上，设计模式，算是“术”，你要是领会了“道”，术是很容易的。

不得不说，大佬就是大佬，有的话就是有深度。再细细体会了许久并和大佬继续深入交流之后，终于有所领悟。

03 “术”与“道”

何为术？何为道？

说起术和道，脑海中印象最深的，就属动漫《一人之下》（原名异人）中的诸葛青和王也道长两个人物了。（一人之下作者米二对于整部作品注入了大量道家相关的元素，奇特的画风，耳熟能详的口音，让人痴迷不已，强烈安利。）诸葛青和王也道长均为术士，所用的呢都是术法，说起术法就不可不谈道家的奇门遁甲。

奇门遁甲指的是奇门和遁甲。奇就是乙（日）、丙（月）、丁（星）三奇，为天时。“门”就是休、生、伤、杜、景、惊、死、开八门（在排宫法中是八门，在飞宫法中九门：休、死、伤、杜、中、开、惊、生、景），为方位。遁就是隐藏，“甲”指六甲，即甲子、甲戌、甲申、甲午、甲辰、甲寅，“甲”是在十干中最为尊贵，它藏而不现，隐遁于六仪之下。

在中国传统文化中，奇门遁甲被认为是以易经和八卦为基础，结合星相历法、天文地理、八门九星、阴阳五行、三奇六仪等要素的一门学问。

——以上内容引自维基百科

而作为术，奇门遁甲自古以来就是通晓天地的规律，了解世间万的“道”理，从而做到真的趋吉避凶。或者说我认为，术实际上是人对于道的一种运用。

那么如果把设计模式作为“术”，他用于解决我们平常所遇到的业务模块，那么道是什么？

深感迷惑的我被大佬的一句话点醒。

道可道，非常道。

04 设计模式与兵法

俗话说：兵无常势，水无常形。

我们日常的业务场景就是一个个的难题，很多时候，我们会发现，现有的架构，没有办法很好的契合到业务场景当中。真的是我们的架构不对么？实际上并不是。那是因为我们的业务场景太多变么？实际上也不是。那么问题究竟处在哪呢？

17世纪英国哲学家培根曾经说过：“读史可以明智”。既然想不出个所以然来，那就看看古人是怎么做的。

古时候天下分久必合合久必分，各个帝王能够赢下各个城池，所需要考虑的东西，肯定比我们现在碰到的业务场景多得多。那么当时有什么精华可以让我们学习的呢？想必唯有“阵法”可以一学。

而说到阵法，可能就要说一说《梦幻西游》玩家都知道的一个人，鬼谷子。鬼谷子在《梦幻西游》代表着各个阵法。而史书中记载，鬼谷子是战国时期纵横家的鼻祖（让我不禁联想到了《秦时明月》），座下弟子无数，而最为人所知的，可能就是兵家代表人孙膑。而孙膑所著的《孙膑兵法》中，将阵完整系统地分为八种阵型。既：“方、圆、锥行、雁行、钩行、玄襄、疏阵、数阵、火阵、水阵。”

那么阵法有什么可以学的呢？

阵法看似规整（只有这几种），实则不然。所有的阵法均看将领的指挥，对于不同的敌方的阵型，有的时候不仅仅需要阵型的切换，有的时候还需要对阵型进行改造，进行创新，而设计模式也类似与此。

业务没有永久的不变的业务，而设计模式也没有永久不变的设计模式，所有的设计模式衍生出各种各样的新的架构，从而支持着各种各样的业务场景，从 MVC，到 MVP，到 MVVM 等等，谁都不能说哪个好，哪个坏。也没有谁推翻了谁，只是新的能够支持当前业务形态的形式被发现了，为的就是能够更好的支持各种各样的业务场景。

04 道可道，非常道

就如大佬所说：道可道，非常道。

这句话在我理解有两层意思：

一、道可道，非“常”道

道看似不变，实际上一直在变，他永远不会以一种常态出现在你的面前。

业务场景是如此，架构亦是如此。你永远不会触碰到同一种业务，每种业务都有自己的独特点。

二、道可道，“非常”道

俗话说：道生一，一生二，二生三，三生万物，万物归一。万物看似皆在变，实则皆不变。道仍然是道，变得只是他的表象。而现有的设计模式思路也是如此，说白了就是如何对于每个模块进行优雅的拆分，从而更好的进行组合。而为的就是每块代码能够更好的对那一块内容进行解释。而这就是一种求极限的思路，如何让设计模式产出的内容能够与业务形态进行映射。

就像当我们遇到问题的时候会有2个域，一个是 problem domain（待解决问题的领域），一个是 solution domain（对问题提出解决方案的领域）。有的时候看到 problem domain，我们就能提出正确以及优雅的解，那是因为我们看穿了这个问题的本质和某种设计模式相类似，直接套用即可。但是有的情况下我们并没办法提出最优雅的解。而这个时候，我们站在开发的角度，需要不断的向产品提出自己的疑惑****，从而明白，产品真正需要的是什么？当弄清楚这个问题之后，我们所需要做的就是如何优雅地将 problem domain 映射到 solution domain 上。

05 映射与最优解

那么有的时候我们会想，这些解决方案，从哪来呢？

有人可能会说，前辈们留下来的呗。

那么再往前呢？在没有设计模式这个概念提出来的时候呢？

劳动人民日积月累的宝贵经验？

那再往前呢，在历史的长河之中呢？

帝王？Emmmmmmm？？？

那个时候可能不叫解决方案，可能叫做《帝王术》。就像前面说到，“读史可以明智。”很多情况下，历史已经告诉了我们很多经验。

以 JS 的数据存储为例，一般情况下为人所熟知对于 Store 的存储有两个方向，一个是集中式——redux，一个是分布式——mobx。你说这两个设计思路很新颖？实则不然，redux 更像是中央集权制度的映射，如果一个人修改了主要的 store，那么就会引入脏数据，从而影响整个工程；而 mobx 更倾向于权力的拆分，映射到数据而言，就是让数据与数据之间彼此独立（由于对于 JS 这几个库不怎么熟悉而且不是这次讨论重点，只能点到为止）

那么具体哪个是最优解呢？谁也说不出，因为对于不同的业务场景，最终的结论都是不同的。

05 问题与本质

所以说无论问题有多难，在对问题不断拆解的过程，就是一个不断探索问题本质的过程。写代码是如此，做产品亦是如此。

说到这有人可能不信了？做产品还能有本质这一说？

无论哪一款爆款的产品，最终能被众人接受的原因就是满足了人的“七大罪”—— 傲慢、贪婪、色欲、嫉妒、愤怒、暴食及怠惰。前五个可能风险系数较高，所以一般容易出事情，而最后两个，一个是美食，也就是吃吃吃。另一个就是懒。

世间流传着一句话：这个世界实际上是由懒人推动的。因为当一个人想要变得懒惰的时候，他会想办法找到各种更加快捷或者更加方便的事物进行代替。机器人取代人，软件操作系统取代日常文件的维护，移动端取代 PC 端逐渐成为时代的主流……

06 道与编程

扯了那么多，最后总结一些个人的想法：实际上编程和道是一样的，包括大数据亦是如此。都是不断得在追求事物的规则，甚至是本源，并将其进行规则化或者说通过规则进行描述。就像 05 中提到的，世间万物都是会随着时代变迁朝着熵增（混乱度增加，有序变成无序）的方向发展，而人为了能够让自己过得更加舒服（变得更懒），就会不断得将无序转变成为有序。而作为一个程序员，有的时候不仅仅满足于自己的能够做出一个产品，更能在处理问题的过程中，惊奇的发现一个个神奇的规律。那种对于规则的不断探索所产生的 High 点，可能这就是我还会继续写代码的原因吧……

当然有的时候我也会不断思考如果强人工智能真的出现了（也就是人类真的发现了人这个东西中的所有规则）会怎么样？那就是下一篇文章中的故事了。

欢迎关注我的公众号：zkhCreatorPro

聊聊产品，谈谈人生，我说的不一定是对的，但是都是我思考过的。