設計模式
參考資料
圖解設計模式
大話設計模式
設計模式之禪
github我見過最好的設計模式
http://c.biancheng.net/view/1326.html
基本原則
開閉原則
在設計的時候盡可能的考慮，需求的變化，新需求來了盡可能少的改動代碼，擁抱變化
定義:指的是軟體中一個物體，如類、模塊和函式應該對擴展開放，對修改關閉，
面向抽象編程
開閉是對擴展和修改的約束
強調：用抽象構建框架，用實作擴展細節，
優點：提高軟體系統的可復用性及可維護性
- 面向物件最基礎的設計原則
- 指導我們構建穩定的系統
- 代碼不是一次性的，更多時間在維護
- 大多是代碼版本的更新迭代
- 我們最好對已有的原始碼很少修改
- 一般都是新增擴展，類來修改
- 能夠降低風險
關于變化
- 邏輯變化
- 比如說演算法從
a*b*c變化成a*b+c其實是可以直接修改的，前提是所有依賴或者關聯類都按照相同的邏輯來處理
- 比如說演算法從
- 子模塊變化
- 子模塊變化可能直接引起整體也就是高層的變化
- 可見視圖變化
- 如果說需求上多了一些原有邏輯不存在的，可能這種變化是恐怖的，需要我們靈活的設計
例子
- 彈性作業時間，時間是固定的，上下班是可變的
頂層介面
介面是規范，抽象是實作
通過繼承來解決
價格的含義已經變化了，所以不能夠子類直接繼承getPrice(),因為當前已經是折扣價格了，可能需要價格和折扣價格
問題
為什么要遵循開閉原則，從軟體工程角度怎么理解這點，
- 開閉原則對擴展開放對修改關閉，程式和需求一定是不斷修改的，我們需要把共性和基礎的東西抽出來，把常常修改的東西讓他能夠擴展出去，這樣我們程式后期維護的風險就會小很多
為什么重要
- 對于測驗的影響
- 一處變更可能導致原有測驗用例都不管用了
- 提高復用性
- 高內聚，低耦合
- 提高可維護性
- 面向物件開發的要求
如何使用
- 抽象約束
- 引數抽到配置中
- 例如sql的連接資訊
- 國際化資訊
- 指定專案章程
- 約定專案中Bean都是用自動注入，通過注解來做裝配
- 團隊成員達成一致
- 公共類走統一的入口，大家都是用統一的公共類
- 封裝變化
- 提前預知變化
依賴倒置原則
定義
高層模塊不應該依賴低層模塊，二者都應該依賴其抽象，抽象不應該依賴細節，細節應該依賴抽象，
說白了就是針對介面編程，不要針對實作編程
什么是倒置
- 不可分割的原子邏輯是底層模塊，原子邏輯在組裝就是高層模塊
- 抽象就是介面或者抽象類
- 都不能被實體化的
- 細節
- 細節就是具體實作類
優點
- 通過依賴倒置，能夠減少類和類之間的耦合性，提高系統的穩定性，提高代碼的可讀性和穩定性，降低修改程式的風險
例子
public class DipTest {
public static void main(String[] args) {
//===== V1 ========
// Tom tom = new Tom();
// tom.studyJavaCourse();
// tom.studyPythonCourse();
// tom.studyAICourse();
//===== V2 ========
// Tom tom = new Tom();
// tom.study(new JavaCourse());
// tom.study(new PythonCourse());
//===== V3 ========
// Tom tom = new Tom(new JavaCourse());
// tom.study();
//===== V4 ========
Tom tom = new Tom();
tom.setiCourse(new JavaCourse());
tom.study();
}
}
重點
- 先頂層后細節
- 自頂向下來思考全域不要一開始沉浸于細節
- 高層不依賴于低層，關系應該用抽象來維護
- 針對介面編程不要針對實作編程
以抽象為基準比以細節為基準搭建起來的架構要穩定得多，因此大家在拿到需求之后， 要面向介面編程，先頂層再細節來設計代碼結構，
問題
為什么要依賴抽象，抽象表示我還可以擴展還沒有具體實作，按照自己的話來解釋一遍
- 一般軟體中抽象分成兩種，介面和抽象類，介面是規范，抽象是模板，我們通過抽象的方式，也就是使用規范和模板這樣我們能夠使得上層，也就是呼叫層能夠復用邏輯，而我們底層是能夠快速更改實作的，例如Spring的依賴注入，Dubbo的SPI，SpringBoot的SPI都如此
依賴的常見寫法
- 構造傳遞依賴物件
- setter方法傳遞依賴物件
- 介面宣告傳遞物件
最佳實踐
- 每個類盡量都有介面或抽象類，或者抽象類和介面兩者都具備這是依賴倒置的基本要求，介面和抽象類都是屬于抽象的，有了抽 象才可能依賴倒置，
- 變數的表面型別盡量是介面或者是抽象類
- 很多書上說變數的型別一定要是介面或者是抽象類，這個有點絕對 化了，比如一個工具類，xxxUtils一般是不需要介面或是抽象類的，還 有，如果你要使用類的clone方法，就必須使用實作類，這個是JDK提供 的一個規范，
- 任何類都不應該從具體類派生
- 如果一個專案處于開發狀態，確實不應該有從具體類派生出子類的 情況，但這也不是絕對的，因為人都是會犯錯誤的，有時設計缺陷是在 所難免的，因此只要不超過兩層的繼承都是可以忍受的，特別是負責項 目維護的同志，基本上可以不考慮這個規則，為什么？維護作業基本上 都是進行擴展開發，修復行為，通過一個繼承關系，覆寫一個方法就可 以修正一個很大的Bug，何必去繼承最高的基類呢？（當然這種情況盡 量發生在不甚了解父類或者無法獲得父類代碼的情況下，）
- 盡量不要覆寫基類的方法
- 如果基類是一個抽象類，而且這個方法已經實作了，子類盡量不要 覆寫，類間依賴的是抽象，覆寫了抽象方法，對依賴的穩定性會產生一 定的影響，
單一職責原則
不要存在多余一個導致類變更的原因
- 類
- 介面
- 方法
只負責一項職責
如果不是這樣設計，一個介面負責兩個職責，一旦需求變更，修改其中一個職責的邏輯代碼會導致另外一個職責的功能發生故障，
案例
用戶資訊案例
上述圖片用戶的屬性和用戶的行為并沒有分開
- 下圖把
- 用戶資訊抽成BO(Business Object,業務物件)
- 用戶行為抽成Biz(Business Logic 業務邏輯物件)
電話
電話通話會發生下面四個程序
- 撥號
- 通話
- 回應
- 掛機
上圖的介面做了兩個事情
- 協議管理
- dial 撥號接通
- hangup 掛機
- 資料傳送
- chat
引起變化的點
- 協議接通會引起會引起變化(連接導致不傳輸資料)
- 可以有不同的通話方式
打電話，上網
從上面可以看到包含了兩個職責，應該考慮拆分成兩個介面
優點
- 類的復雜性降低，實作什么職責都有清晰明確的定義；
- 可讀性提高，復雜性降低，那當然可讀性提高了；
- 可維護性提高，可讀性提高，那當然更容易維護了；
- 變更引起的風險降低，變更是必不可少的，如果介面的單一職責 做得好，一個介面修改只對相應的實作類有影響，對其他的介面無影響，這對系統的擴展性、維護性都有非常大的幫助，
注意
單一職責原則提出了一個撰寫程式的標準，用“職責”或“變 化原因”來衡量介面或類設計得是否優良，但是“職責”和“變化原因”都 是不可度量的，因專案而異，因環境而異，
This is sometimes hard to see，單一職責確實收到很多因素制約
- 工期
- 成本
- 技術水平
- 硬體情況
- 網路情況
- 政府政策
介面隔離原則
- 兩個類之間的依賴應該建立在最小的介面上
- 建立單一介面，
不要建立龐大臃腫的介面 - 盡量細化介面，介面中的方法盡量少
高內聚低耦合
例子
問題
為什么要把IAnimal拆分成IFlyAnimal,ISwimAnimal，不拆分會有什么樣的問題
- 一個類所提供的功能應該是他所真正具有的，不拆分會導致他不提供的功能但是強行需要實作，而且會有臃腫的類出現
- 可能配接器模式也是為了解決這個問題吧
最佳實踐
- 一個介面只服務于一個子模塊或者業務邏輯
- 通過業務邏輯壓縮介面中的public方法，介面時常去回顧，盡量 讓介面達到“滿身筋骨肉”，而不是“肥嘟嘟”的一大堆方法；
- 已經被污染了的介面，盡量去修改，若變更的風險較大，則采用
配接器模式進行轉化處理； - 了解環境，拒絕盲從，每個專案或產品都有特定的環境因素，別看到大師是這樣做的你就照抄，千萬別，環境不同，介面拆分的標準就不同，深入了解業務邏輯，最好的介面設計就出自你的手中！
迪米特法則
一個物件應該對其他物件保證最少的了解,也稱最少知道原則,如果兩個類不必彼此直接通信，那么這兩個類就不應該發生直接的相互作用，如果其中一個類需要呼叫另外一個類的某個方法的話，可以通過第三者轉發這個呼叫
能夠降低類與類之間的耦合
強調只和朋友交流
出現在成員變數、方法的輸入、輸出引數中的類都可以稱之為成員朋友類， 而出現在方法體內部的類不屬于朋友類，
這里面感覺有點職責分開的感覺，不同的物件應該關注不同的內容，所做的事情也應該是自己所關心的
例子
teamLeader只關心結果，不關心Course
錯誤類圖如下
問題
如果以后你要寫代碼和重構代碼你怎么分析怎么重構？
- 先分析相應代碼的職責
- 把不同的物件需要關心的內容抽離出來
- 每個物件應該只創建和關心自己所關心的部分
- 一定要使用的話可以通過三方來使用
- 合適的使用作用域，不要暴露過多的公共方法和非靜態的公共方法
注意
迪米特法則要求類“羞澀”一點，盡量不要對外公布太多的 public方法和非靜態的public變數，盡量內斂，多使用private、packageprivate、protected等訪問權限，
在實際的專案中，需要適度地考慮這個原則，別為了套用原則而做專案，原則只是供參考，如果 違背了這個原則，專案也未必會失敗，這就需要大家在采用原則時反復 度量，不遵循是不對的，嚴格執行就是“過猶不及”，
序列化引起的坑
- 謹慎使用Serializable
- 在一個專案中使用 RMI（Remote Method Invocation，遠程方法呼叫）方式傳遞一個 VO（Value Object，值物件），這個物件就必須實作Serializable介面 （僅僅是一個標志性介面，不需要實作具體的方法），也就是把需要網 絡傳輸的物件進行序列化，否則就會出現NotSerializableException異 常，突然有一天，客戶端的VO修改了一個屬性的訪問權限，從private 變更為public，訪問權限擴大了，如果服務器上沒有做出相應的變更， 就會報序列化失敗，就這么簡單，但是這個問題的產生應該屬于專案管 理范疇，一個類或介面在客戶端已經變更了，而服務器端卻沒有同步更 新，難道不是專案管理的失職嗎？
遵循的原則
? 如果 一個方法放在本類中，既不增加類間關系，也對本類不產生負面影響， 那就放置在本類中，
里氏替換原則
一個軟體物體如果能夠適用一個父親的話，那么一定適用其子類，所有參考父親的地方必須能透明的使用其子類的物件，子類能夠替換父類物件
- 子類可以實作父類的抽象方法，但是不能覆寫父類的非抽象方法
- 子類中可以增加自己特有的方法
- 子類的方法多載父類的方法時，入參要比父類的方法輸入引數更
寬松 - 子類實作父類方法的時候（重寫/多載或實作抽象方法），方法的后置條件（方法的輸出，回傳）要比父類更加
嚴格或者相等
例子
價格重寫問題
價格不是直接重寫，而是新寫一個方法
public class JavaDiscountCourse extends JavaCourse {
public JavaDiscountCourse(Integer id, String name, Double price) {
super(id, name, price);
}
public Double getDiscountPrice(){
return super.getPrice() * 0.61;
}
}
長方形和正方形問題
public static void resize(Rectangle rectangle){
while (rectangle.getWidth() >= rectangle.getHeight()){
rectangle.setHeight(rectangle.getHeight() + 1);
System.out.println("Width:" +rectangle.getWidth() +",Height:" + rectangle.getHeight());
}
System.out.println("Resize End,Width:" +rectangle.getWidth() +",Height:" + rectangle.getHeight());
}
public class Square extends Rectangle {
private long length;
//勝率
@Override
public void setHeight(long height) {
setLength(height);
}
}
當前設計會出現死回圈
解決辦法
抽象介面
public interface QuadRangle {
long getWidth();
long getHeight();
}
回傳共同的length
public class Square implements QuadRangle {
private long length;
public long getLength() {
return length;
}
public void setLength(long length) {
this.length = length;
}
public long getWidth() {
return length;
}
public long getHeight() {
return length;
}
}
當前方式子類就能夠隨時替換父類了
問題
- 你怎么理解里氏替換原則，為什么要保證使用父類的地方可以透明地使用子類
- 子類必須實作父類中沒有實作的方法
- is-a的問題
- 如果父類的地方替換成子類不行的話程式復雜性增加，繼承反而帶來了程式的復雜度
- 子類只能在父類的基礎上增加新的方法
- 在具體場景中怎么保證使用父類的地方可以透明地使用子類
- 父類回傳多使用具體實作，入參多使用抽象或者說頂層介面
- 子類可以新增一些自己特有的方法
注意
如果子類不能完整地實作父類的方法，或者父類的某些方法 在子類中已經發生“畸變”，則建議斷開父子繼承關系，采用依賴、聚 集、組合等關系代替繼承，
盡量避免子類的“個性”，一旦子 類有“個性”，這個子類和父類之間的關系就很難調和了，把子類當做父 類使用，子類的“個性”被抹殺——委屈了點；把子類單獨作為一個業務 來使用，則會讓代碼間的耦合關系變得撲朔迷離——缺乏類替換的標 準，
合成復用原則
盡可能使用物件組合 has-a組合 或者是 contains-a聚合而不是通過繼承來達到軟體復用的目的，
- 繼承是白箱復用
- 所有細節都暴露給了子類
- 組合和聚合是黑箱復用
- 物件歪的物件獲取不到細節
優點
問題
為什么要多用組合和聚合少用繼承
- 繼承是侵入性的
- Java只支持單繼承
- 降低了代碼的靈活性，子類多了很多約束
- 增強了耦合性，父類修改的時候需要考慮子類的修改
- 會導致關鍵代碼被修改
總結
如果你只有一把鐵錘， 那么任何東西看上去都像是釘子，
- 適當的場景使用適當的設計原則
- 需要考慮，人力，成本，時間，質量，不要刻意追求完美
- 需要多思考才能用好工具
我的筆記倉庫地址gitee 快來給我點個Star吧
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/242697.html
標籤：其他
上一篇：DRF認證流程及原始碼分析