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