文章目錄

• 代碼質量評判標準
• • 軟件腐化的原因
  • 提高系統可復用性的幾點原則
  • 可維護性與可復用性并不完全一致
• 面向對象設計原則
• • 1. 面向對象設計的六大設計原則表
  • 2. 圖解面向對象涉及的六大原則
  • • 1. 開閉原則
    • 2. 依賴倒置原則
    • 3. 接口隔離原則
• 設計模式
• • 1. 設計模式的編目
  • 2. 設計模式的分類
  • 3.設計模式之間的關聯
  • 4. 如何選擇設計模式
  • 5. 如何使用設計模式
• UML基本關系
• 參考資料
• • 參考鏈接
  • 參考文獻

圖片版權說明: 部分來自于筆者自行整理；另有圖片出自極客時間專欄-設計模式之美、《設計模式：可復用面向對象軟件的基礎》，如有涉及版權問題，請聯系我刪除。

---

代碼質量評判標準

軟件腐化的原因

問題所在設計目標

過于僵硬	可擴展性（新性能可以很容易加入系統）
過于脆弱	靈活性（修改不會波及其它）
復用率低
粘度過高	可插入性（新功能容易加入系統（氣囊加入方向盤））

提高系統可復用性的幾點原則

傳統復用：

代碼的粘帖復用

算法的復用

數據結構的復用

可維護性與可復用性并不完全一致

參考鏈接:https://www.cnblogs.com/zhenyulu/articles/36061.html

---

面向對象設計原則

學習設計模式之前，有必要先學習面向對象設計（OOD：Object Oriented Design）的幾大設計原則，為后面設計模式的學習打下基礎。在學習具體的方法論之前，我們先來看一些更加偏向頂層的指導思想。為了盡量寫出擴展性好的代碼，我們要時刻具備擴展意識、抽象意識、封裝意識。這些“潛意識”可能比任何開發技巧都重要。

1. 面向對象設計的六大設計原則表

縮寫英文名稱中文名稱

SRP	Single Responsibility Principle	單一職責原則
OCP	Open Close Principle	開閉原則
LSP	Liskov Substitution Principle	里氏替換原則
LoD	Law of Demeter （ Least Knowledge Principle）	迪米特法則（最少知道原則）
ISP	Interface Segregation Principle	接口分離原則
DIP	Dependency Inversion Principle	依賴倒置原則

2. 圖解面向對象涉及的六大原則

1. 開閉原則

2. 依賴倒置原則

依賴倒置（Dependence Inversion Principle）原則講的是：要依賴于抽象，不要依賴于具體。

簡單的說，依賴倒置原則要求客戶端依賴于抽象耦合。原則表述：

抽象不應當依賴于細節；細節應當依賴于抽象； 要針對接口編程，不針對實現編程。

圖1中，高層對象A依賴于底層對象B的實現,耦合太緊密；
圖2中，把高層對象A對底層對象的需求抽象為一個接口A，底層對象B實現了接口A，這就是依賴反轉。

3. 接口隔離原則

---

設計模式

1. 設計模式的編目

共包含23個設計模式。它們的名字和意圖列舉如下，以使讀者有個基本了解。

• Abstract Factory: 提供一個創建一系列相關或相互依賴對象的接口，而無須指定它們具體的類。
• Adapter: 將一個類的接口轉換成客戶希望的另外一個接口。 Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。
• Bridge:將抽象部分與它的實現部分分離，使它們都可以獨立地變化。
• Builder:將一個復雜對象的構建與它的示分離，使得同樣的構建過程可以創建不同的表示。
• Chain of Responsibility:解除請求的發送者和接收者之間的耦合，使多個對象都有機會處理這個請求。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它。
• Command:將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日志，以及支持可取消的操作
• Composite:將對象組合成樹形結構以表示“分-整體”的層次結構. Composite使得客戶對單個對象和組合對象的使用具有一致性。
• Decorator:動態地給一個對象添加一些額外職責。就擴展功能而言， Decorator模式比生成子類方式更為靈活。
• Facade:為子系統中的一組接口提供一個一致的界面， Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。
• Factory Method:定義一個用于創建對象的接口，讓子類決定將哪一個類實例化。 Factory Method使一個類的實例化延遲到其子類。
• Flyweight:運用共享技術有效地支持大量細粒度的對象。
• Interpreter:給定一個語言，定義它的文法的一種表示，并定義一個解釋器，該解釋器使用該表示來解釋語言中的句子。
• Iterator:提供一種方法順序訪問一個聚合對象中的各個元素，而又不需要暴露該對象的內部表示。
• Mediator:用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。
• Memento:在不破壞封裝性的前提下，捕獲個對象的內部狀態，并在該對象之外保存這個狀態。這樣以后就可將該對象恢復到保存的狀態。
• Observer:定義對象間的一種一對多的依賴關系，以便當一個對象的狀態發生改變時，所有依賴于它的對象都得到通知并自動刷新。
• Prototype:用原型實例指定創建對象的種類，并且通過拷貝這個原型來創建新的對象。
• Proxy:為其他對象提供一個代理以控制對這個對象的訪問。
• Singleton:保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。
• State:允許一個對象在其內部狀態改變時改變它的行為。對象看起來似乎修改了它所屬的類。
• Strategy:定義一系列的算法，把它們一個個封裝起來，并且使它們可相互替換本模式使得算法的變化可獨立于使用它的客戶。
• Template Method:定義一個操作中的算法的骨架，而將一些步驟延遲到子類中.Template Method使得子類不改變一個算法的結構即可定義該算法的某些特定步驟。
• Visitor:表示一個作用于某對象結構中的各元素的操作。它使你可以在不改變各素的類的前提下定義作用于這些元素的新操作。

2. 設計模式的分類

3.設計模式之間的關聯

圖片來源自https://popdaniel.wordpress.com/2012/09/26/design-patterns-week-1-2/

4. 如何選擇設計模式

考慮設計模式是怎樣解決設計問題的。
有幾個參考維度：合適的對象、決定對象的粒度、指定對象接口、設計模式解決設計問題的幾個其他方法。

瀏覽設計模式的意圖部分
通讀每個模式的意圖，找出和問題相關的一個或者多個模式。具體可以參考下圖:

研究模式如何互相關聯(參考博客第三小節)

研究目的相似的模式

檢查重新設計的原因

• 通過顯示地指定一個類來創建對象
• 對于特殊操作的依賴
• 對硬件、軟件平臺的依賴
• 對對象表示或實現的依賴
• 算法依賴
• 緊耦合
• 通過生成子類來擴充功能
• 不能方便地對類進行修改

考慮你的設計中有哪些是可變的 ：與關注引起重新設計的原因剛好相反，不是考慮什么會迫使你的設計改變，而是考慮你想要什么變化又不會引起重新設計。最主要一點是封裝變化的概念，這個是許多設計模式的主題。具體可以參考下標，列出諸多設計模式允許你獨立變化的方面，你可以改變它們而又不會重新設計。

• 創建型設計模式

設計模式可變的方面

Abstract Factory	產品對象家族
Builder	如何創建一個組合對象
Factory Method	被實例化的子類
Prototype	被實例化的類
Singleton	一個類唯一的實例

• 結構型設計模式

設計模式可變的方面

Adapter	對象的接口
Bridge	對象的實現
Composite	一個對象的結構和組成
Decorator	對象的職責，不生成子類
Facade	一個子系統的接口
Flyweight	對象的存儲開銷
Proxy	如何訪問一個對象；該對象的位置

• 行為型設計模式

設計模式可變的方面

Chain of Responsibility	滿足一個請求的對象
Command	何時、怎樣滿足一個對象
Interpreter	一個語言的文法與解釋
Iterator	如何遍歷、訪問一個聚合的各元素
Mediator	對象間怎樣交互、和誰交互
Memento	一個對象中有哪些私有信息存放在該對象之外，以及在什么時候進行存儲
Observer	多個對象依賴于另一個對象，而這些對象又如何保持一致
State	對象的狀態
Strategy	算法
Template Method	算法中的某些步驟
Visitor	某些可作用于一個(或一組)對象上的操作，但不修改這些對象的類

5. 如何使用設計模式

一旦選擇了一個設計模式，該怎么使用它呢?這里給出一個有效應用設計模式的循序漸進的方法。

大致瀏覽一遍模式特別注意其適用性部分和效果部分，確定它適合你的問題。

回頭研究結構部分、參與者部分和協作部分確保你理解這個模式的類和對象以及它們是怎樣關聯的。

看代碼示例部分，看看這個模式代碼形式的具體例子研究代碼將有助于你實現模式

選擇模式參與者的名字，使它們在應用上下文中有意義設計模式參與者的名字通 常過于抽象 而不會直接出現在應用中。然而，將參與者的名字和應用中出現的名字合并起來
是很有用的。這會幫助你在實現中更顯式地體現出模式來。例如，如果你在文本組合算法中 使用了 Strategy模式，那么你可能有名為
SimpleLayoutStrategy ak TeXLayoutStrategy這樣的類。

定義類聲明它們的接口，建立它們的繼承關系，定義代表數據和對象引用的實例變量。識別模式會影響到你的應用中存在的類，并做出相應的修改。

定義模式中專用于應用的操作名稱這里再一次體現出名字一般依賴于應用。使用與每一個操作相關聯的責任和協作作為指導。還有，你的名字約定要一致。例如，可以使用
Create-”前綴統一標記 Factory方法。

實現執行模式中責任和協作的操作實現部分提供線索指導你進行實現。代碼示例部分的例子也能提供幫助。

這些只對你一開始使用模式起指導作用，以后你會有自己的設計模式使用方法。

關于設計模式，如果不提一下它們的使用限制，那么關于怎樣使用它們的討論就是不完整的。
設計模式不能夠隨意使用。通常你通過引入額外的間接層次獲得靈活性和可變性的同時，也使設計變得更復雜和/或犧牲了一定的性能。一個設計模式只有當它提供的靈活性是真正需要的時候，才有必要使用。 當衡量一個模的得失時，它的效果部分是最能提供幫助的。

---

UML基本關系

• 繼承，繼承可以使得子類具有父類別的各種屬性和方法，而不需要再次編寫相同的代碼。在令子類別繼承父類別的同時，可以重新定義某些屬性，并重寫某些方法，即覆蓋父類別的原有屬性和方法，使其獲得與父類別不同的功能。
• 泛化，可以簡單地理解為繼承關系；
• 實現，一般是接口和實現類之間的關系；
• 關聯，一種擁有關系，比如老師類中有學生列表，那么老師類和學生類就是擁有關系；
• 聚合，整體與部分的關系，但是整體和部分是可以分離而獨立存在的，如汽車類和輪胎類；
• 組合，整體與部分的關系，但是二者不可分離，分離了就沒有意義了，例如，公司類和部門類，沒有公司就沒有部門；
• 依賴，一種使用關系，例如創建 A類必須要有 B 類。

• [例圖] UML 類圖關系（泛化 、繼承、實現、依賴、關聯、聚合、組合）

參考資料

參考鏈接

https://popdaniel.wordpress.com/2012/09/26/design-patterns-week-1-2/
https://popdaniel.wordpress.com/category/teaching/design-patterns/page/2/
https://www.oodesign.com/
https://en.wikipedia.org/wiki/SOLID
https://www.cnblogs.com/zhenyulu/articles/36061.html

參考文獻

閻宏，《Java與模式》，電子工業出版社

[美]James W. Cooper，《C#設計模式》，電子工業出版社

[美]Alan Shalloway James R. Trott，《Design Patterns Explained》，中國電力出版社

[美]Robert C. Martin，《敏捷軟件開發－原則、模式與實踐》，清華大學出版社

[美]Don Box, Chris Sells，《.NET本質論 第1卷：公共語言運行庫》，中國電力出版社

[美] 埃里克·伽瑪（Erich Gamma） 等 著 《設計模式：可復用面向對象軟件的基礎》

[日] 結城浩 著 《圖解設計模式(圖靈出品)》

總結

以上是生活随笔為你收集整理的代码质量评判标准、设计模式、面向对象设计原则速查表的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。