“一個設計模式引發的血案”
雖然作為一個菜雞，可能還談不上架構，但是就像說說自己的一些想法。
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
聊聊產品，談談人生，我說的不一定是對的，但是都是我思考過的。