引子
遵從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，我就寫篇架構師三大難的文章，只可惜周六發文一向閱讀量不高，雖然“在看率”較平時已經提高很多了，目前還沒達到，但是“在看率”上來了，可以感受到大家的支持，讓我充滿力量，女孩子嘛，比較感性，決定本周加更這篇，表達一下自己的感恩~~
推薦閱讀
到底多大才算高并發？
面試官視角看面試
技術方案設計的方法
在作業中遇到的兩件事及其思考
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/347035.html
標籤：架構設計
上一篇：java 自定義表單 動態表單 表單設計器 作業流引擎 flowable 專案原始碼
下一篇：設計模式 ——狀態模式