前兩天，和一朋友聊到OO設計原則時，對設計模式有了更深的瞭解，在這裡總結一下，與大家分享。
OO(Object–Oriented )面向物件 
  OO方法(Object-Oriented Method，面向物件方法，面向物件的方法)是一種把面向物件的思想應用於軟體開發過程中，指導開發活動的系統方法，簡稱OO (Object-Oriented)方法，是建立在“物件”概念基礎上的方法學。物件是由資料和容許的操作組成的封裝體，與客觀實體有直接對應關係，一個物件類定義了具有相似性質的一組物件。而每繼承性是對具有層次關係的類的屬性和操作進行共享的一種方式。所謂面向物件就是基於物件概念，以物件為中心，以類和繼承為構造機制，來認識、理解、刻畫客觀世界和設計、構建相應的軟體系統。

OO的設計目標：

• 可擴充套件性：有了新的需求，新的效能可以容易新增到系統中，不影響現有的效能，也不會帶來新的缺陷。
• 可修改性：系統一部分的程式碼要修改時不會破壞系統的現有結構，也不會影響到其它的部分。
• 可替換性：可以將系統中的某些程式碼替換為相同介面的其它類，不會影響到系統。

設計模式的設計原則：

• “開放--封閉”原則：
  設計模式的核心原則。軟體實體（類，模組，函式）對於擴充套件是開放的,對於修改是關閉的 。實現開閉原則的關鍵就是抽象化。“開放--封閉”原則中，不允許修改的是抽象的類或者介面。允許擴充套件的是具體的實現類,抽象類和介面在“開-閉”原則中扮演著極其重要的角色 。
• 封裝變化點原則：
  這是對"開-閉"原則最好的實現..不要把你的可變因素放在多個類中,或者散落在程式的各個角落..你應該將可變的因素,封套起來..並且切忌不要把所用的可變因素封套在一起..最好的解決辦法是,分塊封套你的可變因素!!避免超大類,超長類,超長方法的出現!!給你的程式增加藝術氣息,將程式藝術化是我們的目標!!
• 里氏代換原則：
  任何基類可以出現的地方，子類也可以出現 。
• 依賴倒轉原則：
  要依賴抽象,而不要依賴具體的實現。抽象不應當依賴於細節，細節應當依賴於抽象；要針對介面程式設計，不要針對實現程式設計
• 單一職責原則：
  一個類應該只有一個引起它變化的原因。
• 介面隔離法則 ：
  為了做到儘可能小的耦合性，我們需要使用介面來規範類，用介面來約束類。要達到迪米特法則的要求，最好就是實現介面隔離法則。使用多個專門的介面比使用單一的總介面要好.從一個客戶類的角度來講：一個類對另外一個類的依賴性應當是建立在最小的介面上的。一個介面應當簡單地代表一個角色，而不是多個角色。多個演員可以同時演一個角色，就象孫悟空的孩兒一樣。
• 合成/聚合原則：
  要儘量使用合成/聚合原則,而不是繼承關係達到軟體複用的目的。聚合用來表示“擁有”或整體與部分的關係，而合成則用來表示一種強得多的“擁有”關係。在一個合成關係裡，部分和整體的生命週期是一樣的。合成就象所說的“合成品”，拆開就壞。
• 迪米特法則：
  系統中的類,儘量不要與其他類互相作用，減少類之間的耦合度。 一個物件應當對其它物件有儘可能少的瞭解，兩個類不必直接通訊，可以通過第三者(抽象)轉發這個呼叫，這個抽象的第三者可以是門面，可以是調停者，甚至是一個抽象類或介面，模組要獨立，獨立被封裝，他們只靠public的API來通訊，只要有可能，一個類應當設計成不變類，其屬性都應該是私有的，如果一個類有太多的public訪問許可權的方法，可以考慮使用多個類把一個類的私有方法和公有方法分開。

聚合(Aggregation):

   這是一種鬆散的物件間的關係.舉個例子:計算機和他的外圍裝置就是一例.

  用來表示擁有關係或者整體與部分的關係。

組合(Composition):

這是一種非常強的物件間的關係,舉個例子,樹和它的樹葉之間的關係.

在一個合成裡，部分與整體的生命週期都是一樣的。一個合成的新物件完全擁有對其組成

部分的支配權。包括他們的建立和毀滅。

最後總結一下：

聚合：

•  聚合有時能夠不依賴部分而存在，有時又不能
• 部分可以獨立於聚合而存在
• 如果有一部分遺失，聚合會給人一種不完全的感覺
• 部分的所有權可以由幾個聚合來共享，比如印表機

合成：

• 部分某一時刻只能屬於某一個組成
• 組成唯一的負責處理它的所有部分--這就意味著負責他們的建立與銷燬
• 倘若對於部分的職責由其他物件來承擔的話，組成也就可以放鬆這些職責。
• 如果組成銷燬的話，它必須銷燬所有的部分，或者把負責他們的權利轉移給其他物件。

設計模式所解決的問題：
通過顯示指定類建立物件:
     相關的設計模式：簡單工廠、工廠方法、抽象工廠。
緊耦合:
    相關的設計模式：抽象工廠、命令模式、外觀模式、中介者模式、觀察者模式、職責鏈模式等。
對物件表示或實現的依賴:
     相關的設計模式：抽象工廠、橋接模式、備忘錄模式、代理模式等。
通過生成子類擴充套件功能:
     相關的設計模式：橋接模式、職責鏈模式、組合模式、裝飾模式、觀察者模式、策略模式等。
有能方便地修改類:
     相關的設計模式：介面卡模式、裝飾模式、訪問者模式等。
對演算法的依賴:
     相關設計模式： 生成器模式、迭代模式、策略模式、模板方法模式、訪問者模式等。
對軟硬體環境的依賴:
     相關設計模式：抽象工廠模式、橋接模式等。