架構整潔之道二(設計原則)
前言
好的系統,應該從寫整潔的程式碼開始。再好的架構設計,要是使用的磚頭質量不佳,那造出來的就是危房。
一些老牌的設計原則,這裡瞭解一下。編碼時,我們未必經常會使用,但還是應該牢記於心。有了這些
內功心法(設計原則),至於什麼招式(設計模式)那都是一通百通的,一變百變的。
SOLID原則
SOLID是指:SRP(單一職責原則)、OCP(開閉原則)、LSP(里氏替換原則)、ISP(介面隔離原則)、
DIP(依賴反轉原則)。下面就聽我隨便瞎聊聊。
SRP(單一職責原則)
正如天下武功為快不破一樣。這個原則是最簡單,但也是最難把控的。什麼叫單一。我覺得應按實際情況來
做分析。如果把人比做是一個系統。當系統還沒到很複雜的時候。也許我們會把,用手處理的運動(
例如:打羽毛球、打乒乓球)歸為一類行為。但當我們把這個人做的更精緻的時候,也許我們就會把
用手打一種球類運動歸為一類行為。所以什麼是單一,應該在現有的系統基礎上,以及現有的人力資源
上,把功能儘可能的劃分單一。畢竟分類越細,所要建立的模組會越多,那自然維護的成本也就會越高。
所以,對SRP的最終描述我覺得應該是這樣的:
任何一個軟體模組都應該只對一類行為負責。而現有的系統規模和人力資源來決定這一類到底可以分的多細。
OCP(開閉原則)
對於開閉原則,我覺最有用,也是最好去實踐的。相對官方的定義是這樣的:
對修改關閉,對擴充套件開放
什麼意思呢,其實很好理解。需求是永遠會變動的。所以,我們在編碼時,只要牢記一個原則:
我寫的程式碼,假如有一天,有新的需求增加或者調整(修復BUG不算),我只需要額外加一些類就可以搞定
的,而不是去修改原來的程式碼來滿足未來可變的需求。
換句話說,我不管你用什麼黑科技,怎麼設計,只要後面的需求來了,不要讓我去修改原來的程式碼,
那麼你的設計就是好的設計。所以什麼面向介面程式設計,抽象與實現的分離,SPI外掛機制,工廠模式等等
這些招式都是在處理這個原則。
LSP(里氏替換原則)
這個原則也是比較好處理的。簡單的理解,就是對繼承或者介面實現進行了約束。通俗的講,可以這樣
解釋:
我們申明一個介面或者抽象類,分別有A、B、C三種實現。當上層在使用這個介面時,無論我使用ABC中
的任何一個實現,上層的功能都是可以良好合理工作的。
上面的定義還是不明白,沒關係。我舉個列子。例如,我們申明瞭一個”鳥”做為基類。其中有個fly的方法。
我們用啄木鳥或者布穀鳥去實現,那是沒問題的,他們都能實現飛的動作。但是如果我們用雞去實現,發現fly這個方法無法實現,
於是就提示說這個方法不支援。這樣雞的實現就違反了LSP原則了。因為當我們系統用雞的例項去替換時,
發現不能fly,那不就悲劇了麼。
ISP(介面隔離原則)
先丟擲一句話,看能不能理解:
任何模組或者層次的軟體設計,如果依賴了他不需要的東西,那都是有害的
具體舉個例子來解釋:例如我們有個類,其中有3個方法:方法1、方法2、方法3。而我們的模組a功能只需要方法1,模組b功能只需要方法2,
模組c功能只需要方法3。如果我們使用同一個介面,包含這3個方法去編碼,那麼勢必,在模組a的功能上雖然沒有用到方法2和方法3,
但也是被依賴了,假如有一天,方法2或者方法3被修改了,雖然模組a沒有使用,但也必須需要重新編譯了。因此,我們應該把這3個方法,
拆分成3個不同的介面,各自模組只依賴對應的介面。這樣任何其他方法被修改了,都不會影響當前模組。這就是所謂的介面隔離原則。
換一句比較術語化的說法意思都是一樣一樣的:
客戶端不應該依賴它不需要的介面;一個類對另一個類的依賴應該建立在最小的介面上。
DIP(依賴反轉原則)
這個大家應該熟悉的不要不要的了。Spring就是靠IOC(控制反轉)出道的。其實這個原則也很簡單:
我們編碼時,要儘量依賴一些穩定的抽象層,而不要去依賴容易變動的實現層
介面往往比實現更加穩定,所以我們要基於依賴介面程式設計,不要依賴具體實現。那麼要怎麼實現不依賴具體實現,就是上面說的控制反轉。
我們都知道,Java裡面介面是不能new的,需要有一個具體實現類來構建例項再向上轉型到介面引用。所以這裡有一個常見的做法,就是
使用工廠設計模式,建立一個工廠,專門用來例項化這些例項。這樣我們的模組裡面只依賴了相對比較穩定的工廠類,而不是具體介面的實現
類。像Spring的IOC,也是利用類似模式,只不過他做的比較強大健全而已,構造了一個容器來管理這些例項,並設定了很多擴充套件點,讓我們
方便的干預例項的建立。
總結
正如上面所說了,這5大設計原則就是內功心法。武俠小說都看過吧,光有內功心法其實是不夠的。還需要學一點招式,就是所謂的設計模式。
但內功的深厚最終決定你能走多遠。最後,真正的大俠,是需要在實戰中磨練的。最後形成一套屬於自己的拳法,例如:黯然銷魂掌。但內功
心法是你的起步,需要時刻牢記。
相關推薦
https://www.atatech.org/articles/128443
相關文章
- 架構整潔之道-書中箴言架構箴言
- 《架構整潔之道》第 1 章 設計與架構究竟是什麼架構
- 架構整潔之道:優秀設計或多餘,有效設計最可取架構
- 《架構整潔之道》第 3 章 程式設計正規化總覽架構程式設計
- [譯] Go 語言的整潔架構之道 —— 一個使用 gRPC 的 Go 專案整潔架構例子Go架構RPC
- SOLID架構設計原則Solid架構
- 架構師修煉之道(二)——架構?設計?架構師?架構
- PHP 整潔之道PHP
- 雲原生架構及設計原則架構
- 程式碼整潔之道
- 讀Flink原始碼談設計:FileSystemConnector中的整潔架構原始碼架構
- JavaScript 程式碼整潔之道JavaScript
- Typescript 程式碼整潔之道TypeScript
- 聊聊程式碼整潔之道
- 簡單介紹架構設計的原則!架構
- [分散式]架構設計原則--高併發分散式架構
- 亞馬遜CTO的架構之道-儉約架構師的成本優先架構原則亞馬遜架構
- Angular應用架構設計-5:設計原則與總結Angular應用架構
- 架構設計的五大原則-SOLID架構Solid
- 360°透視:雲原生架構及設計原則架構
- 程式碼整潔之道 clean code
- 程式碼整潔之道:程式設計師的職業素養(十三)程式設計師
- “整潔架構”和商家前端的重構之路架構前端
- 【虹科乾貨】設計微服務架構的原則微服務架構
- 架構設計要按照什麼原則進行呢?架構
- 設計和架構:業務開發指導原則架構
- 架構簡潔之道:從阿里開源應用架構 COLA 說起阿里應用架構
- 程式碼整潔之道讀書記
- 【架構設計】你真的理解軟體設計中的SOLID原則嗎?架構Solid
- 讀資料工程之道:設計和構建健壯的資料系統07資料架構的原則架構
- 掌握4C原則,設計高效的系統架構架構
- Apache 的架構師們遵循的 30 條設計原則Apache架構
- 借降本增效之名,探索開閉原則架構設計架構
- [開發故事]架構師修煉 III - 掌握設計原則架構
- 雲端計算架構設計6大原則遵循了哪些?架構
- 閱讀《程式碼整潔之道》總結
- 程式碼整潔之道Clean Code筆記筆記
- 程式碼整潔之道的 7 個方法