引入設計模式的目的：增強系統的可維護性。
設計模式一般不能提高軟件的功能和性能。
設計模式（Design Patterns）：從建筑領域而來，是對軟件設計中普遍存在而又反復出現的各種問題，所提出的解決方案。
設計模式并不直接用來完成程序代碼的編寫，而是描述在各種不同的情況下，要如何解決問題的一種方案。
四人組針對創建優秀的面向對象設計提出的建議：
1、針對接口進行設計；
2、優先使用對象組合，而不是類繼承；
3、找到并封裝變化點。
設計模式可以讓我們：
1、復用解決方案。利用已有的模式開發，可以借鑒他人的經驗，減少開發成本和風險。
2、建立通用術語。在項目的分析和設計階段，模式提供了約定俗成的詞匯和視角，有利于溝通。
3、解放視角。無論針對問題還是設計，設計模式提供了高層次的視角，開發人員不必一開始就埋頭于具體的細節之中。
面相對象：
可維護 改
可復用 替換下來的字仍然有用
可擴展 可加字
靈活性好 可豎排
通過封裝、繼承、多態把程序的耦合度降低。
用設計模式使得程序更加靈活，容易修改，并且易于復用。
編程原則之一：盡可能避免重復。
UML中的集中關系：
依賴關系（Dependency）：
類方法的形參或返回值為其他類的對象。
如，新陳代謝（in o2:氧氣，in water:水）。
虛線箭頭
關聯關系（Association）：
一個類“知道”另一個類。
如，penguin知道climate。
實線箭頭
聚合關系（Aggregation）：
表示一種弱的“擁有”關系，體現的是A對象可以包含B對象，但B對象不是A對象的一部分。
如，雁群擁有大雁。
空心菱形 +實線箭頭
合成關系（Composition）：
是一種強的“擁有”關系，體現了嚴格的部分和整體的關系，部分和整體的生命周期一致。
如，大雁擁有翅膀。
實心菱形 +實線箭頭
設計模式遵循的幾個原則：單一職責原則：就一個類而言，應該僅有一個引起它變化的原因。
如果能夠想到多于一個的動機去改變一個類，那么這個類就具有多于一個的職責。
軟件設計真正要做的許多內容，就是發現職責并把那些職責相互分離。
開放封閉原則：
軟件實體（類、模塊、函數等等）可以擴展，但是不可修改
對于擴展開放（open for extension）
對于更改封閉（closed for modification）
怎樣的設計才能面對需求的改變卻可以保持相對穩定，從而使得系統可以在第一個版本以后不斷推出新的版本呢？
無論模塊多么的“封閉”，都會存在一些無法對之封閉的變化。
既然不可能完全封閉，設計人員必須對于他設計的模塊應該對那種變化封閉做出選擇。
他必須先猜測出最有可能發生的變化種類，然后構造抽象來隔離那些變化。
等到變化發生時立即采取行動。
在最初編寫代碼時，假設變化不會發生。當變化發生時，就創建抽象來隔離以后發生的同類變化。
面對需求，對程序的改動是通過增加新代碼進行的，而不是更改現有的代碼。
希望的是在開發工作展開不久就知道可能發生的變化。
查明可能發生的變化所等待的時間越長，要創建的抽象就越困難。
開放封閉原則是面向對象設計的核心所在。
遵循這個原則可以帶來面向對象技術所聲稱的巨大好處，也就是可維護、可擴展、可復用、靈活性好。
開發人員應該僅對程序中呈現出頻繁變化的那些部分做出抽象。
然而，對于應用程序的每個部分都刻意地進行抽象同樣不是一個好主意。
拒絕不成熟的抽象和抽象本身一樣重要。
里氏代換原則：
子類型必須能夠替換掉它們的父類型。
即一個軟件實體如果使用的是一個父類的話，那么一定適用于其子類，而且它覺察不出父類對象和子類對象的區別。也就是說，在軟件里面，把父類都替換成它的子類，程序行為沒有變化。
只有當子類可以替換掉父類，軟件單位的功能不受到影響時，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行為。
正是由于子類型的可替換性才使得使用父類類型的模塊在無需修改的情況下就可以擴展。
依賴倒轉原則：
A 高層模塊不應該依賴底層模塊。兩個都應該依賴抽象。
B 抽象不應該依賴細節。細節應該依賴抽象。
針對接口編程，不要對實現編程。
依賴倒轉其實可以說是面向對象設計的標志，用那種語言來編寫程序不重要，如果編寫時考慮的都是如何針對抽象編程而不是針對細節編程，即程序中所有的依賴關系都是終止于抽象類或者接口，那就是面向對象的設計，反之那就是過程化設計了。
迪米特法則：
最少知識原則：
如果兩個類不必彼此直接通信，那么這兩個類就不應當發生直接的相互作用。
如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。
迪米特法則首先強調的前提是：在類的結構設計上，每一個類都應當盡量降低成員的訪問權限。
迪米特法則其根本思想，是強調了類之間的松耦合。
類之間的耦合越弱，越有利于復用，一個處在弱耦合的類被修改，不會對有關系的類造成波及。
新聞熱點
疑難解答
