模式的誕生與定義 -Context（模式可適用的前提條件）-Theme或Problem（在特定條件下要解決的目標問題）-Solution（對目標問題求解過程中各種物理關係的記述） 設計模式的分類 Gof設計模式 創建型模式（關註對象的創建過程，對類的實例化過程進行抽象，描述如何將對象的創建和使用分離 ...
- 模式的誕生與定義
- 模式(Pattern)起源於建築業而非軟體業(小本本記下來～～)
- 模式之父--美國加利佛尼亞大學環境結構中心研究所所長Christopher Alexander博士;
- 模式 ：
-Context（模式可適用的前提條件）
-Theme或Problem（在特定條件下要解決的目標問題）
-Solution（對目標問題求解過程中各種物理關係的記述） - 模式是在特定環境下人們解決某類重覆出現問題的一套成功有效的解決方案。（簡單來說就是為了減少工作量）。
- 程式設計的最大的特點： 變化 因為環境、設備、用戶的需求等原因， 導致程式經常發生變化
- 基本結構
- 設計模式的定義：一套被反覆使用的，多數人知曉的，經過分類遍目的、代碼設計經驗的總結，使用設計模式是為了可重覆使用代碼，讓代碼更容易被他人理解並且提高代碼的可靠性(目的)。設計模式是一種對軟體系統中不斷重覆出現的設計問題的解決方案進行文檔化的技術，也是一種共用專家設計經驗的技術。
- 基本要素 ：模式名稱(Pattern Name)、問題(Problem) 、解決方案(Solution)、效果(Consequences)
- 設計模式的分類
- 根據目的（模式是用來做什麼的）：可分為創建型(Creational)，結構型(Structural)和行為型(Behavioral)三類
- 根據範圍，即模式主要是處理類之間的關係還是處理對象之間的關係，可分為類模式和對象模式兩種：
- 類模式處理類和子類之間的關係，這些關係通過繼承建立，在編譯時刻就被確定下來，是一種靜態關係
- 對象模式處理對象間的關係，這些關係在運行時變化，更具動態性
- GoF設計模式
- “四人組(Gang of Four，GoF，分別是Erich Gamma, Richard Helm, Ralph Johnson和John Vlissides)”於1994年歸納發表了23種在軟體開發中使用頻率較高的設計模式，旨在用模式來統一溝通面向對象方法在分析、設計和實現間的鴻溝。
-
創建型模式（關註對象的創建過程，對類的實例化過程進行抽象，描述如何將對象的創建和使用分離）
抽象工廠模式(Abstract Factory) ★★★★★
建造者模式(Builder) ★★☆☆☆
工廠方法模式(Factory Method) ★★★★★(GoF 之外：簡單工廠模式)
原型模式(Prototype) ★★★☆☆
單例模式(Singleton) ★★★★☆ -
結構型模式(關註如何將現有類或對象組織在一起形成更加強大的結構)
適配器模式(Adapter) ★★★★☆
橋接模式(Bridge) ★★★☆☆
組合模式(Composite) ★★★★☆
裝飾模式(Decorator) ★★★☆☆
外觀模式(Facade) ★★★★★
享元模式(Flyweight) ★☆☆☆☆
代理模式(Proxy) ★★★★☆ -
行為型模式(關註系統中對象間的交互，研究系統在運行時對象之間的相互通信與協作進一步明確對象的職責)
職責鏈模式(Chain of Responsibility) ★★☆☆☆
命令模式(Command) ★★★★☆
解釋器模式(Interpreter) ★☆☆☆☆
迭代器模式(Iterator) ★★★★★
中介者模式(Mediator) ★★☆☆☆
備忘錄模式(Memento) ★★☆☆☆
觀察者模式(Observer) ★★★★★
狀態模式(State) ★★★☆☆
策略模式(Strategy) ★★★★☆
模板方法模式(Template Method) ★★★☆☆
訪問者模式(Visitor) ★☆☆☆☆
- 常用面向對象設計的原則
- 單一職責原則(Single Responsibility Principle, SRP)| ★★★★☆ : 一個對象應該只包含單一的職責，並且該職責被完整地封裝在一個類中
- 另一種定義方式：就一個類而言，應該僅有一個引起它變化的原因。簡單而言，就是一個類如果職責越多，那麼它被覆用的可能性就越低。即這個類中一個職責變化，可能會影響到其他的職責的運作。因此，單一職責原則就是實現高內聚，低耦合，將一個類的職責降低到最小，即類的數目很多，類中職責很少，因而類被覆用的可能性被提高。
- 開閉原則(Open-Closed Principle,OCP) | ★★★★★ : 軟體實體應當對擴展開放，對修改關閉
- 開閉原則是復用設計的第一塊基石。在軟體實體中應在儘量不修改原有代碼的情況下進行擴展
- 里氏代換原則(Liskov Substitution Principle,LSP)| ★★★★★ : 所有引用基類的地方必須能透明地使用其子類的對象
- 在軟體中將一個基類對象替換成它的子類對象，程式將不會產生任何的錯誤和異常，反之不成立。例如：我喜歡動物，那麼我一定喜歡狗，因為狗是動物的子類，反之不成立
- 依賴倒轉原則(Dependence Inversion Principle,DIP) | ★★★★★ : 高層模塊不應該依賴低層模塊，它們應該依賴抽象。抽象不應該依賴於細節，細節應該依賴於抽象
- 要針對介面編程，不針對實現編程。一個具體類應當只實現介面或抽象類中聲明過的方法，而不給出多餘的方法，否在無調用到在子類中增加的新方法
- 介面隔離原則(Interface Segregation Principle,ISP)| ★★☆☆☆ : 客戶端不應該依賴那些它不需要的介面
- 當一個介面太大時，將它分割成一些更細小的介面，使用該介面的客戶端只要知道與之相關的方法即可
- 合成復用原則(Composite Reuse Principle,CRP)| ★★★☆☆:優先使用對象組合，而不是繼承來達到復用的目的
- 在一個新的對象里通過關聯關係(包括組合和聚合關係)來使用一些已有的對象，使之成為新對象的一部分，新對象通過委派調用已有對象的方法達到復用功能的目的
- 迪米特法則(Law of Demeter,LoD)| ★★★☆☆ : 每一個軟體單位對其他的單位都只有最少的知識，而且局限於那些與本單位密切相關的軟體單位
- 又稱最少知識原則，一個軟體實體應儘可能少地與其他類發生相互作用
- 設計模式的優點
- 融合了眾多專家的經驗，並以一種標準的形式供廣大開發人員所用
- 提供了一套通用的設計辭彙和一種通用的語言，以方便開發人員之間進行溝通和交流，使得設計方案更加通俗易懂
- 讓人們可以更加簡單方便地復用成功的設計和體繫結構
- 使得設計方案更加靈活，且易於修改
- 將提高軟體系統的開發效率和軟體質量，且在一定程度上節約設計成本
- 有助於初學者更深入地理解面向對象思想，方便閱讀和學習現有類庫與其他系統中的源代碼，還可以提高軟體的設計水平和代碼質量
- 設計模式的缺點
- 要說缺點的話，每一種都有它適用的地方和不適用之處，若使用不當，缺點往往會暴露的很明顯。因此，學習到位，理解透徹，運用的多了，自然懂得如何揚長避短了，因而模式的缺點就儘可能的最小化了
