架構設計的思維方式（架構之思-分析那些深入骨髓的設計原則）

2023-04-16 03:58:09 1

遵從SOLID五大設計原則、遵從三大編程範式……很多的設計原則對於像我這樣工作十幾年的人來說，已經刻到了骨髓裡。

在平時工作中，不自覺的進行了熟練的運用：看到公司裡有個基礎數據這樣的服務，明知道很難很難也要決心治理掉：「這種服務不應該存在！任何一個軟體模塊都應該只對一個用戶或系統利益相關者負責(單一職責原則)。我們的代碼是要長長久久運行N個世紀的，不應該將領域不清的部分堆到一處！」

有一次跟剛工作幾年的小夥子討論的時候，就是《面對編碼分歧怎樣展開討論》裡邏輯分析那一段，我突然意識到自己正面臨著危險：很多原則是在很多年前思考並開始運用了，那時候的批判性思維還很弱，時代也在飛速的發展，是不是很多金科玉律當時並沒有想明白、或者理解有偏差、或者應該被更新了。我是否正在逐漸走向經驗主義？

想到這裡，我決心從頭來梳理分析自己深入骨髓的設計原則。

先簡單回憶一下SOLID原則的內容：

SRP：單一職責原則，任何一個軟體模塊應該只對某一類行為者負責。

OCP：開閉原則，設計良好的軟體應該易於擴展(對擴展開放)，同時抗拒修改(對修改關閉)。

LSP：裡氏替換原則，儘量使用抽象(如父類)，避免使用具體(如子類)，以便於方便的進行替換。

ISP：接口隔離原則，客戶端不應該依賴於它不需要的接口。這裡囉嗦兩句，Bob大叔在自己的巔峰之作《架構整潔之道》中詳細介紹了SOLID原則，後來設計原則逐漸演變為六大，多出來的一個是LOD迪米特法則，又稱最少知識原則，我一直找不到六大設計原則的出處，知道的朋友還煩請告知。我個人觀點，接口隔離原則與迪米特法則異曲同工，所以沒有必要放進來。

DIP：依賴反轉原則，多使用抽象接口，儘量避免使用多變的實現類。

《面對編碼分歧怎樣展開討論》裡邏輯分析那一段，我本身之所以認為自己是對的，原因是同事的設計違反了LSP裡氏替換原則和DIP依賴反轉原則，同時還間接的違反了OCP開閉原則。

落筆在這個地方躊躇了很久。我該怎麼證明自己這樣是對的還是錯的呢？這個問題最後還是想起了Bob大叔的觀點，才和自己達成和解。

Bob大叔說：

科學和數學在證明方法上有著根本性的不同，科學理論和科學定律通常是無法被證明的，比如我們沒法證明萬有引力的正確性，但我們可以用科學實驗來演示這些定律的正確性。而且不管做多少次正確的實驗，也無法排除在今後的某次實驗可能會推翻萬有引力定律的可能性。

這就是科學理論和定律的特點：它們可以被偽證，但是沒有辦法被證明。如果某個結論經過一定努力沒有辦法證明是偽證，我們則認為它在當下是足夠正確的。

從這裡吸取的營養是：我應該從本身這麼做是否正確出發。《面對編碼分歧怎樣展開討論》裡邏輯分析那一段，實際上同事已經認同了他要解決的問題有別的方法去解決，而我的建議有更好的擴展性和可維護性。

擴展性和可維護性又在軟體領域有多重要的作用呢？軟體之所以叫軟體，軟本身就有靈活的意思，如果以後都不太會變化，這段邏輯刻在硬體上不是更高效嘛。為了達到軟體的本來目的，軟體系統必須足夠軟，應該很容易被修改。

三大編程範式

先來簡單回憶一下三大編程範式：

結構化編程

結構化編程對程序控制權的直接轉移進行了限制和規範。

對結構化編程的結構舉個例子，大家就明白了：順序結構、分支結構和循環結構。現在大多數程式語言都禁止使用goto這樣的無限制跳轉語句，因為它將會損害程序的整體結構。

工作十幾年，自己從未寫過goto語句。但是見過一些源碼有goto語句的，那時候才見識了goto的厲害：用它可以跳轉到任何代碼位置，不受限制。它破壞了程序的封裝，修改一個類的內部結構變的很危險，增加了耦合性。

不過我們不必擔心自己沒有遵循結構化編程的範式，只要是按照程式語言推薦的語法都是遵循這一範式的。

面向對象編程

面向對象編程對程序控制權的間接轉移進行了限制和規範。

面向過程和面向對象最大的不同在於，面向對象有更好的可讀性和重用性。

記得頭幾年評價別人代碼寫的不怎麼樣會這樣說：這個同學用面向對象的語言寫出了面向過程的程序。

函數式編程

函數式編程對程序中的賦值進行了限制和規範。

面向對象編程是對數據進行抽象，函數式編程是對行為的抽象。我們來理解一下什麼是對行為的抽象。

下面代碼可以被編譯通過：

new ArrayList.stream.forEach(x-> System.out.println(x=x 1));

下面代碼不可以被編譯通過：

int i =0;new ArrayList.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，我就寫篇架構師三大難的文章，只可惜周六發文一向閱讀量不高，雖然「在看率」較平時已經提高很多了，目前還沒達到。但是「在看率」上來了，可以感受到大家的支持，讓我充滿力量。女孩子嘛，比較感性，決定本周加更這篇，表達一下自己的感恩~~

,