設計模式 - 六個基本原則

這裏咱們要作的是瞭解個個原則的優缺點，而不是生搬硬套

單一職責原則(Single Responsibility principle)

A class should have only one reason to change.

一個類應該只有一種緣由引發它的狀態變化

嗯嗯， 你設計的類符合SRP原則麼？

優勢：類的複雜性下降，提升類的可讀性，相應的變動引發的風險低

缺點：職責難以劃分，若粒度劃分很差，可能難以維護

SRP最難的就是職責的劃分，有粒度太小，會致使類的大量增長；若粒度過大，那就會出現一個萬能類，大公司早期項目估計都有這樣的「牛」類，會致使後期難以維護和擴展。

PS：

1. SRP用在方法和接口上仍是很不錯的，一個方法和接口只作一件事情

2. 職責劃分粒度掌握很差，也總比指責不清晰要好不少，不然一旦出現問題，全部類都抱怨說這不是個人責任

里氏替換原則(Liskov Substitution Principle)

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T

程序P中一個類T的實例o2可以被另外一個類S的實力o1替換而不引發程序結果改變，那麼S是T的子類

若是USB是父類抽象接口，那麼全部設備實現就是子類(2.0, 3.0, type-c)

優勢：減小代碼重複，提升代碼可重用性與可擴展性

缺點：繼承是入侵性的，子類沒法甩掉父類的一些方法和屬性。代碼耦合增高靈活性下降，修改一處代碼，不得不考慮是否會影響相關子類

PS:

1. LSP說的是用子類替換父類，反過來是不成的;

2. 若子類沒法完成父類的某些方法或功能，那麼子類沒法替換父類而達到程序行爲不變，違背了LSP;

3. 若遵照LSP，子類覆蓋時應該調用父類方法或完成和父類相同的邏輯;

4. 若遵照LSP，須要保證每一個接口的對應參數和返回值，一樣遵照LSP；

5. 考慮到可維護性，繼承不該該超過三層

依賴倒轉原則(Dependence Inversion Principle)

High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.

高層不該該依賴底層模塊，二者應該抽象(沒法被實例話的接口，類啥的)；抽象不該該依賴細節；細節應該反而依賴抽象，換句話說也就是面向接口編程.

優勢：減小類之間的耦合，提升可讀與可維護性，下降並行開發風險
缺點：目前沒發現，除了依賴特別強的情話下沒法使用

PS:

1. 底層模塊是指不可分割的原子邏輯，應該符合SRP

2. 面向接口編程很容易實現TDD(Test-Driven Development，測試驅動開發)

3. 高層不依賴於底層，換句話說若是底層員工不幹了，你還能依照抽象，在尋找其餘可以勝任的人來接替。大大增長公司的穩定性

接口隔離原則(Interface Segregation Principle)

1. Clients should not be forced to depend upon interfaces that they don't use.

2. The dependency of one class to another one should depend on the smallest possible interface.

1.客戶端不該該依賴它不須要的接口
2.類間的依賴關係應該創建在最小的接口上

優勢：結構清晰，減小沒必要要依賴，增長靈活性
缺點：與SRP同樣接口粒度是個難以權衡的問題，若功能同樣，粒度太小，會致使接口過多，結構複雜

PS:

1. 根據SRP接口粒度應該儘可能小，即接口內部公開方法要儘可能少，減小沒必要要的public接口

2. 接口要儘可能高內聚，即接口內部可以儘可能獨立處理事物，減小對外部的依賴

3. 接口要可定製化，一樣的功能對內部模塊和對外部模塊顯然會有權限等限制要考慮，以防止誤用

4. 一個接口儘可能只服務一個字模塊或業務邏輯

5. 若接口被污染，儘可能去修改，若風險較大，能夠採用適配器轉化處理

迪米特法則(Law of Demeter) or 最少知識原則(Principle of Least Knowledge)

1.Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.
2.Each unit should only talk to its friends; don't talk to strangers.
3.Only talk to your immediate friends.

每一個單元應對周圍有最少的瞭解 and 只和朋友交流

優勢：類之間依賴更少，更易於擴展和維護
缺點：爲了減小依賴可能會增長更多的wrapper方法(中轉，跳轉)，也可能所以增長大量沒必要要的工做

PS：
朋友=成員變量 or 成員方法的輸入輸出參數

開閉原則(Open/closed principle)

Software entities like classes, modules and functions should be open for extension but closed for modifications.

一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉

PS: 以上五個原則都是開閉原則的具體形態

23個設計模式

單例模式