第3部分 設計原則
如果建筑的架構設計不佳，那么其所用的磚頭質量再好也沒有用，這就是SOLID設計原則所要解決的問題，
SOLID原則的主要作用就是告訴我們如何將資料和函陣列織成為類，以及如何將這些類鏈接起來成為程式，
我們為軟體構建中層結構的主要目標如下：
- 使軟體可容忍被改動，
- 使軟體更容易被理解，
- 構建可在多個軟體系統中復用的組件，
SOLID原則應該直接緊貼于具體的代碼邏輯之上，這些原則是用來幫助我們定義軟體架構中的組件和模塊的，
SRP：單一職責原則
一個軟體系統的最佳結構高度依賴于開發這個系統的組織的內部結構，這樣，每個軟體模塊都有且只有一個需要被改變的理由，
OCP：開閉原則
如果軟體系統想要更容易被改變，那么其設計就必須允許新增代碼來修改系統行為，而非只能靠修改原來的代碼，
LSP：里氏替換原則
如果想用可替換的組件來構建軟體系統，那么這些組件就必須遵守同一個約定，以便讓這些組件可以相互替換，
ISP：介面隔離原則
這項設計原則主要告誡軟體設計師應該在設計中避免不必要的依賴，
DIP：依賴反轉原則
高層策略性的代碼不應該依賴實作底層細節的代碼，恰恰相反，那些實作底層細節的代碼應該依賴高層策略性的代碼，
第7章 SRP：單一職責原則
任何一個軟體模塊都應該有且僅有一個被修改的原因，
任何一個軟體模塊都應該只對某一類行為者負責，
多人為了不同的目的修改了同一份源代碼，這很容易造成問題的產生，而避免這種問題產生的方法就是將服務不同行為者的代碼進行切分，
第8章 OCP：開閉原則
設計良好的計算機軟體應該易于擴展，同時抗拒修改，
如果A組件不想被B組件上發生的修改所影響，那么就應該讓B組件依賴于A組件，
軟體系統不應該依賴其不直接使用的組件
OCP是我們進行系統架構設計的主導原則，其主要目標是讓系統易于擴展，同時限制其每次被修改所影響的范圍，實作方式是通過將系統劃分為一系列組件，并且將這些組件間的依賴關系按層次結構進行組織，使得高階組件不會因低階組件被修改而受到影響，
第9章 LSP：里氏替換原則
果對于每個型別是S的物件o1都存在一個型別為T的物件o2，能使操作T型別的程式P在用o2替換o1時行為保持不變，我們就可以將S稱為T的子型別，
LSP可以且應該被應用于軟體架構層面，因為一旦違背了可替換性，該系統架構就不得不為此增添大量復雜的應對機制，
第10章 ISP：介面隔離原則
任何層次的軟體設計如果依賴了它并不需要的東西，就會帶來意料之外的麻煩，
第11章 DIP：依賴反轉原則
如果想要設計一個靈活的系統，在源代碼層次的依賴關系中就應該多參考抽象型別，而非具體實作，
在應用DIP時，我們也不必考慮穩定的作業系統或者平臺設施，因為這些系統介面很少會有變動，我們主要應該關注的是軟體系統內部那些會經常變動的（volatile）具體實作模塊，這些模塊是不停開發的，也就會經常出現變更，
穩定的抽象層
- 應在代碼中多使用抽象介面，盡量避免使用那些多變的具體實作類，
- 不要在具體實作類上創建衍生類，
- 不要覆寫（override）包含具體實作的函式，在這里，控制依賴關系的唯一辦法，就是創建一個抽象函式，然后再為該函式提供多種具體實作，
- 應避免在代碼中寫入與任何具體實作相關的名字，或者是其他容易變動的事物的名字，
工廠模式
利用抽象工廠模式來管理依賴關系
源代碼依賴方向永遠是控制流方向的反轉——這就是DIP被稱為依賴反轉原則的原因，
任意一個軟體都能反映出其制作團隊的組織結構，這是因為人們會以反映他們組織形式的方式作業，換句話說，分散的團隊可能用分散的架構生成系統，專案團隊的組織結構中的優點和弱點都將不可避免地反映在他們生成的結果系統中
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/286575.html
標籤：其他