引子
遵從SOLID五大設計原則、遵從三大程式設計正規化……很多的設計原則對於像我這樣工作十幾年的人來說，已經刻到了骨髓裡。
在平時工作中，不自覺的進行了熟練的運用：看到公司裡有個基礎資料這樣的服務，明知道很難很難也要決心治理掉：“這種服務不應該存在！任何一個軟體模組都應該只對一個使用者或系統利益相關者負責(單一職責原則)。我們的程式碼是要長長久久執行N個世紀的，不應該將領域不清的部分堆到一處！”
有一次跟剛工作幾年的小夥子討論的時候，就是《面對編碼分歧怎樣展開討論》裡邏輯分析那一段，我突然意識到自己正面臨著危險：很多原則是在很多年前思考並開始運用了，那時候的批判性思維還很弱，時代也在飛速的發展，是不是很多金科玉律當時並沒有想明白、或者理解有偏差、或者應該被更新了。我是否正在逐漸走向經驗主義？
想到這裡，我決心從頭來梳理分析自己深入骨髓的設計原則。
SOLID原則
先簡單回憶一下SOLID原則的內容：
SRP：單一職責原則，任何一個軟體模組應該只對某一類行為者負責。
OCP：開閉原則，設計良好的軟體應該易於擴充套件(對擴充套件開放)，同時抗拒修改(對修改關閉)。
LSP：里氏替換原則，儘量使用抽象(如父類)，避免使用具體(如子類)，以便於方便的進行替換。
ISP：介面隔離原則，客戶端不應該依賴於它不需要的介面。這裡囉嗦兩句，Bob大叔在自己的巔峰之作《架構整潔之道》中詳細介紹了SOLID原則，後來設計原則逐漸演變為六大，多出來的一個是LOD迪米特法則，又稱最少知識原則，我一直找不到六大設計原則的出處，知道的朋友還煩請告知。我個人觀點，介面隔離原則與迪米特法則異曲同工，所以沒有必要放進來。
DIP：依賴反轉原則，多使用抽象介面，儘量避免使用多變的實現類。
《面對編碼分歧怎樣展開討論》裡邏輯分析那一段，我本身之所以認為自己是對的，原因是同事的設計違反了LSP里氏替換原則和DIP依賴反轉原則，同時還間接的違反了OCP開閉原則。
落筆在這個地方躊躇了很久。我該怎麼證明自己這樣是對的還是錯的呢？這個問題最後還是想起了Bob大叔的觀點，才和自己達成和解。
Bob大叔說：
科學和數學在證明方法上有著根本性的不同，科學理論和科學定律通常是無法被證明的，比如我們沒法證明萬有引力的正確性，但我們可以用科學實驗來演示這些定律的正確性。而且不管做多少次正確的實驗，也無法排除在今後的某次實驗可能會推翻萬有引力定律的可能性。
這就是科學理論和定律的特點：它們可以被偽證，但是沒有辦法被證明。如果某個結論經過一定努力沒有辦法證明是偽證，我們則認為它在當下是足夠正確的。
從這裡吸取的營養是：我應該從本身這麼做是否正確出發。《面對編碼分歧怎樣展開討論》裡邏輯分析那一段，實際上同事已經認同了他要解決的問題有別的方法去解決，而我的建議有更好的擴充套件性和可維護性。
擴充套件性和可維護性又在軟體領域有多重要的作用呢？軟體之所以叫軟體，軟本身就有靈活的意思，如果以後都不太會變化，這段邏輯刻在硬體上不是更高效嘛。為了達到軟體的本來目的，軟體系統必須足夠軟，應該很容易被修改。
三大程式設計正規化
先來簡單回憶一下三大程式設計正規化：
結構化程式設計
結構化程式設計對程式控制權的直接轉移進行了限制和規範。
對結構化程式設計的結構舉個例子，大家就明白了：順序結構、分支結構和迴圈結構。現在大多數程式語言都禁止使用goto這樣的無限制跳轉語句，因為它將會損害程式的整體結構。
工作十幾年，自己從未寫過goto語句。但是見過一些原始碼有goto語句的，那時候才見識了goto的厲害：用它可以跳轉到任何程式碼位置，不受限制。它破壞了程式的封裝，修改一個類的內部結構變的很危險，增加了耦合性。
不過我們不必擔心自己沒有遵循結構化程式設計的正規化，只要是按照程式語言推薦的語法都是遵循這一正規化的。
物件導向程式設計
物件導向程式設計對程式控制權的間接轉移進行了限制和規範。
程式導向和麵向物件最大的不同在於，物件導向有更好的可讀性和重用性。
記得頭幾年評價別人程式碼寫的不怎麼樣會這樣說：這個同學用物件導向的語言寫出了程式導向的程式。
函數語言程式設計
函數語言程式設計對程式中的賦值進行了限制和規範。
物件導向程式設計是對資料進行抽象，函數語言程式設計是對行為的抽象。我們來理解一下什麼是對行為的抽象。
下面程式碼可以被編譯通過：
new ArrayList<Integer>().stream().forEach(x-> System.out.println(x=x+1));
下面程式碼不可以被編譯通過：
int i =0;
new ArrayList<Integer>().stream().forEach(x-> System.out.println(i+=x));
提示說i應該是final或者effectively(實際上) final。
為什麼函數語言程式設計要求用到的變數i為不可變的？但是沒有要求x是不可變呢？
區別是x是函式的引數也就是輸入，i是函式外變數。而函數語言程式設計是對行為抽象，就是說對輸入進行了一系列的處理行為，得到一個輸出；不能對其他資料進行操作，對其他資料操作是面向程式設計做的事情。
舉個生活中的例子：
記得高中的時候特別喜歡陸游那首<卜運算元.詠梅>
驛外斷橋邊，寂寞開無主。
已是黃昏獨自愁，更著風和雨。
無意苦爭春，一任群芳妒。
零落成泥碾作塵，只有香如故。
這首古文描述了對梅花的加工行為。這個行為抽象為函式是這個樣子的：
function 梅花變香泥(一枝梅) {
第一步：孤立它
第二步：讓它經歷黑暗
第三步：讓它經歷風雨
第四步：讓其他花兒妒忌它
第五步：讓它凋落到泥裡化為塵土只保留香氣
}
這裡“梅花變香泥”行為被抽象，對呼叫者來說只要呼叫了這個函式，就是呼叫了那5步驟的行為。這裡僅能對一枝梅處理，一枝紅杏出牆來到這裡，她只能對這枝梅產生改變，她可以嫉妒這枝梅冬天開放。“梅花已謝杏花新”，讓梅花零落成泥後讓杏花開放，這就不是這個函式該做的事了。
物件導向程式設計可以做這件事情，它是對資料的抽象：
暖氣潛催次第春，梅花已謝杏花新。
暖氣物件 暖氣;
春物件 春;
梅花物件 梅花;
杏花物件 杏花;
public 春物件 描述春天() {
梅花.狀態=謝了;
杏花.狀態=開了;
春.空氣狀態=暖氣;
春.梅花狀態=謝了;
春.杏花狀態=開了;
return 春;
}
我有對結構化程式設計沒有什麼疑問，畢竟50年前有人就用數學方法證明了順序結構、分支結構和迴圈結構的正確性。
但是作為一直以java語言作為主要開發語言的我，java是物件導向的這句話一直在腦子裡和引入函式式做鬥爭。
函數語言程式設計確實有很多優勢：因為函數語言程式設計的引入變數都是不可變的，虛擬機器實現時可以去掉很多多餘的鎖，併發處理更快；程式碼簡潔；內聚性更好……
我仔細想了一下，對諸如java這種物件導向的程式語言來說，函數語言程式設計和麵向介面程式設計一樣，是區域性實現的技巧，整體結構還是物件導向的。
後記
在上篇《架構師之路-redis叢集解析》最後我說到如果在看超過10，我就寫篇架構師三大難的文章，只可惜週六發文一向閱讀量不高，雖然“在看率”較平時已經提高很多了，目前還沒達到。但是“在看率”上來了，可以感受到大家的支援，讓我充滿力量。女孩子嘛，比較感性，決定本週加更這篇，表達一下自己的感恩~~
推薦閱讀