1、寫在前面
設計模式的定義:在面向對象軟件設計過程當中針對特定問題的簡潔而優雅的解決方案
固然咱們能夠用一個通俗的說法:設計模式是解決某個特定場景下對某種問題的解決方案。所以,當咱們遇到合適的場景時,咱們可能會條件反射同樣天然而然想到符合這種場景的設計模式。html
好比,當系統中某個接口的結構已經沒法知足咱們如今的業務需求,但又不能改動這個接口,由於可能原來的系統不少功能都依賴於這個接口,改動接口會牽扯到太多文件。所以應對這種場景,咱們能夠很快地想到能夠用適配器模式來解決這個問題。前端
以上參考自網易考拉前端團隊-JavaScript設計模式算法
2、設計原則
設計哲學準則:shell
- 小便是美
- 讓每一個程序只作好一件事
- 快速創建原型
- 捨棄高效率而取可移植性
- 採用純文原本存儲數據
- 充分利用軟件的槓桿效應(可複用)
- 使用shell腳原本提升槓桿效應和可移植性
- 避免強制性的用戶界面
- 每一個程序都稱爲過濾器
小準則:編程
- 容許用戶定製環境
- 儘可能使操做系統內核小而輕量化
- 使用小寫字母且簡寫 list = ls
- 沉默是金
- 各部分之和大於總體
- 尋求90%的解決方案
3、SOLID設計原則
-
S 單一職責原則 single設計模式
- 一個程序只作好一件事情
- 若是功能複雜就拆分開,每一個部分保持獨立
-
O 開放封閉原則 openpost
- 對擴展開放,對修改封閉
- 增長需求時,擴展新需求,而非修改已有代碼
- 這是軟件設計的終極目標
-
L 李氏置換原則spa
- 子類能覆蓋父類
- 父類能出現的地方子類就能出現
- JS使用較少
-
I 接口獨立原則操作系統
- 保持接口獨立,避免出現「胖接口」
- JS中沒有接口(ts)
-
D 依賴致使原則設計
- 面向接口編程,依賴於抽象而不依賴於具體
- 使用方只關心接口而不關心具體類的實現
- JS使用較少
4、23種設計模式
- 建立型設計模式
是一類處理對象建立的設計模式,經過某種方式控制對象的建立來避免基本對象建立時可能致使設計上的問題或增長設計上的複雜度。工廠模式、單例模式
- 結構型設計模式
關注於如何將類或對象組合成更大、更復雜的結構,以簡化設計。適配器模式、裝飾器模式、代理模式、外觀模式
- 行爲型設計模式
用於不一樣對象之間職責劃分或者算法抽象,行爲型設計模式不只僅涉及類和對象,還涉及類或對象之間的交流模式並加以實現。觀察者模式、迭代器模式、狀態模式
5、UML類圖
UML(Unified Modeling Language)是一種統一建模語言,爲面向對象開發系統的產品進行說明、可視化、和編制文檔的一種標準語言。
5.1 類圖的表示
類圖分三層,第一層顯示類的名稱,若是是抽象類,則就用斜體顯示。第二層是類的特性,一般就是字段和屬性。第三層是類的操做,一般是方法或行爲。前面的符號,+ 表示public,- 表示private,# 表示protected(js中爲嚴格區分,ts中有)
那麼如何根據類圖寫出相應的代碼結構呢?以下:
注:默認不添加屬性或方法類型,即爲 public,所以 public 可省略
5.2 類關係表示
- 泛化關係【繼承】
空心箭頭表示,是一種繼承關係。例如:自行車是車
- 聚合關係
空心菱形箭頭表示,是總體與部分的關係,與組合關係不一樣,總體和部分不是強依賴的。例如,部門撤銷了,人員不會消失,他們依然存在
- 組合關係
實心菱形箭頭表示,是總體與部分的關係,但部分不能離開總體而單獨存在。如公司和部門是總體和部分的關係,沒有公司就不存在部門
- 關聯關係【引用】
實線(可帶單/雙箭頭)表示,是一種擁有的關係,它使一個類知道另外一個類的屬性和方法
除了上述類關係外,還有實現關係,依賴關係等表示法,可參考下面博文:
看懂UML類圖和時序圖
UML 各類圖總結精華
6、真題
1 根據下面的信息畫UML類圖
- 打車時,能夠打快車或者專車。任何車都有車牌號和名稱
- 不一樣車打車價格不一樣,快車1元/千米,專車2元/千米
- 行程開始時顯示車輛信息
- 行程結束時顯示打車金額
2 根據下面的信息畫UML類圖
- 某停車場,分三層,每層100車位
- 每一個車位都能監控到車輛的駛入和離開
- 車輛駛入前,顯示每層空餘車位數量
- 車輛駛入時,攝像頭可識別車牌號和時間
- 車輛出來時,出口顯示器顯示車牌號和停車時間
分析:
- 車是一個大類,快車和專車繼承自車
- 行程是一個單獨的類,鏈接用車和開始結束兩個動做
分析:
- 關係1:車位組成層,層組成車庫。組合關係
- 關係2:攝像機和顯示屏是車庫的部分,且能單獨存在。聚合關係
- 車停入車位時,須要判別該車位狀態(是否爲空車位)
- 車庫須要記錄車駛入駛出的狀態和記錄車位數,須要經過層獲取