轉自：www.cnblogs.com/skyhecheng/archive/2007/09/06/883888.html??
只有到了一定層次后才會真正的深入體會到面向對象的一些知識點啊！

不談具體程序，談的是你對軟件的理解

模式：

每一個模式描述了一個在我們周圍不斷重復發生的問題，以及該問題的解決方案的核心。

“模式”這個詞是不局限于軟件開發行業的，它幾乎無處不在，它其實就是一種經驗的積累，就象大多數人的教育經歷都是從小學到初中再到高中再到大學，這也是一種模式，是中國的教育模式；現在越來越火的出國熱，也是另一種模式，海外留學模式

比設計模式更重要：GRASP (職責分配原則)

??? GRASP(General Responsibility Assignment Software Patterns)，中文名稱為“通用職責分配軟件模式”，GRASP一共包括9種模式，它們描述了對象設計和職責分配的基本原則。也就是說，如何把現實世界的業務功能抽象成對象，如何決定一個系統有多少對象，每個對象都包括什么職責，GRASP模式給出了最基本的指導原則

可以說，GRASP是學習使用設計模式的基礎。

1．Information Expert (信息專家)

信息專家模式是面向對象設計的最基本原則

如果某個類擁有完成某個職責所需要的所有信息，那么這個職責就應該分配給這個類來實現。這時，這個類就是相對于這個職責的信息專家。

例如：常見的網上商店里的購物車(ShopCar),需要讓每種商品(SKU)只在購物車內出現一次，購買相同商品，只需要更新商品的數量即可。如下圖：

問題

比較商品是否相同的方法需要放到那里類里來實現呢？

2.????? Creator (創造者)

實際應用中，符合下列任一條件的時候，都應該由類Ａ來創建類Ｂ，這時Ａ是Ｂ的創建者：

a.?????? Ａ是Ｂ的聚合

b.?????? Ａ是Ｂ的容器

c.?????? Ａ持有初始化Ｂ的信息(數據)

d.?????? Ａ記錄Ｂ的實例

e.?????? Ａ頻繁使用Ｂ

如果一個類創建了另一個類，那么這兩個類之間就有了耦合，也可以說產生了依賴關系

我們能做的就是正確地創建耦合關系，不要隨便建立類之間的依賴關系，

?

例如：因為訂單(Order)是商品(SKU)的容器，所以應該由訂單來創建商品。如下圖：

3.?????? Low coupling (低耦合)

低耦合模式的意思就是要我們盡可能地減少類之間的連接。

其作用非常重要：

a.?????? 低耦合降低了因一個類的變化而影響其他類的范圍。

b.?????? 低耦合使類更容易理解，因為類會變得簡單，更內聚。

關于低耦合，還有下面一些基本原則：

a.?????? Don’t Talk to Strangers原則：

意思就是說，不需要通信的兩個對象之間，不要進行無謂的連接，連接了就有可能產生問題，不連接就一了百了啦！

b.?????? 如果A已經和B有連接，如果分配A的職責給B不合適的話(違反信息專家模式)，那么就把B的職責分配給A。

c.?????? 兩個不同模塊的內部類之間不能直接連接，

例如：Creator模式的例子里，實際業務中需要另一個出貨人來清點訂單(Order)上的商品(SKU)，并計算出商品的總價，但是由于訂單和商品之間的耦合已經存在了，那么把這個職責分配給訂單更合適，這樣可以降低耦合，以便降低系統的復雜性。如下圖：

4.????? High cohesion (高內聚)

高內聚的意思是給類盡量分配內聚的職責，也可以說成是功能性內聚的職責。即功能性緊密相關的職責應該放在一個類里，并共同完成有限的功能，那么就是高內聚合。這樣更有利于類的理解和重用，也便于類的維護。

?

例如：一個訂單數據存取類(OrderDAO)，訂單即可以保存為Excel模式，也可以保存到數據庫中；那么，不同的職責最好由不同的類來實現，這樣才是高內聚的設計，如下圖：

5.Polymorphism (多態)

這里的多態跟OO三大基本特征之一的“多態”是一個意思。

?

例如：我們想設計一個繪圖程序，要支持可以畫不同類型的圖形，我們定義一個抽象類Shape,矩形(Rectangle)、圓形(Round)分別繼承這個抽象類，并重寫(override)Shape類里的Draw()方法，這樣我們就可以使用同樣的接口(Shape抽象類)繪制出不同的圖形，如下圖：

6.Pure Fabrication (純虛構)

這里的純虛構跟我們常說的純虛構函數意思相近。高內聚低耦合，是系統設計的終極目標，但是內聚和耦合永遠都是矛盾對立的。高內聚以為這拆分出更多數量的類，但是對象之間需要協作來完成任務，這又造成了高耦合，反過來毅然。該如何解決這個矛盾呢，這個時候就需要純虛構模式，由一個純虛構的類來協調內聚和耦合，可以在一定程度上解決上述問題。

?

例如：上面多態模式的例子，如果我們的繪圖程序需要支持不同的系統，那么因為不同系統的API結構不同，繪圖功能也需要不同的實現方式，那么該如何設計更合適呢？如下圖：

7.Indirection (間接)

“間接”顧名思義，就是這個事不能直接來辦，需要繞個彎才行。繞個彎的好處就是，本來直接會連接在一起的對象彼此隔離開了，一個的變動不會影響另一個。就想我在前面的低耦合模式里說的一樣，“兩個不同模塊的內部類之間不能直接連接”，但是我們可以通過中間類來間接連接兩個不同的模塊，這樣對于這兩個模塊來說，他們之間仍然是沒有耦合/依賴關系的。

8.????? Controller (控制器)

用來接收和處理系統事件的職責，一般應該分配給一個能夠代表整個系統的類，這樣的類通常被命名為“XX處理器”、“XX協調器”或者“XX會話”。

關于控制器類，有如下原則：

a.?????? 系統事件的接收與處理通常由一個高級類來代替。

b.?????? 一個子系統會有很多控制器類，分別處理不同的事

9.????? Protected Variations (受保護變化)

預先找出不穩定的變化點，使用統一的接口封裝起來，如果未來發生變化的時候，可以通過接口擴展新的功能，而不需要去修改原來舊的實現。也可以把這個模式理解為OCP(開閉原則)原則，就是說一個軟件實體應當對擴展開發，對修改關閉。在設計一個模塊的時候，要保證這個模塊可以在不需要被修改的前提下可以得到擴展。這樣做的好處就是通過擴展給系統提供了新的職責，以滿足新的需求，同時又沒有改變系統原來的功能

幾位名人的話：

1．人與人之間的交互是復雜的，并且其效果從來難以預期，但卻是工作中最為重要的方面

???????????????????????????????????????????????????????????????????????????? ----Tom DeMacro和Timothly Lister

==團隊力量

2．教堂尖端上的風標，即使由鋼鐵制成，如果不懂順應風勢的藝術，一樣會被暴風立即摧毀。

???????????????????????????????????????????????????????????????????????????? -----海因里希.海捏

==實踐的力量

敏捷軟件開發宣言

?????? 我們正在通過親身實踐以及幫助他人實踐，揭示更好的軟件開發方法。通過這項工作，我們認為：

?????? 個體和交互????????????????? 勝過????????????? 過程和工具

?????? 可以工作的軟件?????????? 勝過????????????? 面面具到的文檔

?????? 客戶合作???????????????????? 勝過????????????? 合同談判

?????? 響應變化???????????????????? 勝過????????????? 遵循計劃

?????? 雖然右項也具有價值，但是我們認為左項具有更大的價值

個人理解和認為需要添加的

?????? 個人理解：

1．?一個團隊里的成員需要相互開源，相互交流，相互探討，不過不是在自己沒有獨立思考的討論，這樣的工作環境要比你用好的中間件，好的開發工具更有成效。

2．?針對客戶用不同的開發模式，一個可以工作的軟件表達的意思要比任何文明了，簡潔，沒有二義性。但不認為文檔不重要，有些文檔必要，數據字典，進度報表，人員安排，類關系圖等

3．?關于客戶方面接觸不是很多

4．?變化是設計模式的產生的原因，是面向對象產生的根本

?????? 添加點：

通俗易懂的例子??? 勝過????????????? 抽象的算法???

即：用形象的例子，用生活中的事物去解釋程序的算法

12條原則

1．?我們最優先要做的是通過盡早的，持續的交付有價值的軟件來使客戶滿意

2．?即使到了開發后期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。

3．?經常性地交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付時間間隔越短越好。

4．?在整個項目開發期間，業務人員和開發人員必須天天一起工作

5．?圍繞被激勵起來的個人來構建項目。給他們提供需要的環境和支持，并且信任他們能夠完成工作

6．?在團隊內部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談。

7．?工作的軟件是首要的進度度量標準

8．?敏捷過程提倡可持續的開發速度。責任人，開發責和用戶應該能夠保持長期的，恒定的開發速度。

9．?不斷的關注優秀的技能和好的設計會增強敏捷能力

10．????????????? 簡單—使未完成的工作量最大化藝術---是根本的

11．????????????? 最好的構架，需求和設計出自于自組織的團隊。

12．????????????? 每隔一定時間，團隊會在如何才能更有效地工作進行反省，然后相應地對自己的行為進行調整。

面向對象基本原則

單一職責原則(SRP)

?????? 就一個類而言，應該僅有一個引發他們變化的原因

開放—封閉原則(OCP)

?????? “軟件實體(類、模塊、函數等)應該是可以擴展的，但是不可修改

依賴倒置原則(DIP)

抽象不應該依賴于細節。細節應該依賴于抽象。”關于這個原則，還有種說法是.“高層不應該依賴于底層，兩者都應該依賴于抽象。”其實怎么說都是對的，關鍵就是要理解一點，只有抽象的東西才是最穩定的，也就是說，我們依賴的是它的穩定。

接口隔離原則(ISP)

“不應該強迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結構。”這個說得很明白了，再通俗點說，不要強迫客戶使用它們不用的方法，如果強迫用戶使用它們不使用的方法，那么這些客戶就會面臨由于這些不使用的方法的改變所帶來的改變。

面向對象原則分析：

SRP:例子

?????? 一般做法:

????????????

???????SRP做法:
???????????????
OCP:
????

DIP:

????? 例如：參考下圖的設計，一個開關跟燈直接連接在一起了，也就是說開關依賴于燈的打開和關閉方法，那么如果我想用這個開關也可以打開其他東西呢，比如電視、音響。顯然這個設計是無法滿足這個要了，因為我們依賴了細節而不是抽象，這個開關已經等價于“燈的開關”
????????
????????????

DIP：

????????????????
ISP:

?????
ISP：

????????

個人認為也可以用抽象類

職責：

?????? 變化的原因

1．?考慮能夠工作的最簡單事情：使用簡單的方案完成需求

EJB(企業級Java Bean) ,socket,ORB(對象請求代理)RMI(遠程方法調用)

2．?你將不需要它

3．?一次，并且只有一次：

不能容忍重復代碼。無論在哪里發現重復代碼，都要消滅。

消除重復的方法是抽象

SRP，單一職責原則：就一個類而言，應該僅有一個引起它變化的原因

·??????? 將過多的職責耦合在一個類中導致了脆弱設計

·??????? 職責是變化的原因

·??????? 如果應用程序變化的方式總是導致兩個職責同時變化，則不應該分離他們

·??????? 把業務規則和持久化子系統綁定在一起是自討苦吃，這違反了單一職責原則。可以使用 Facade 或者 Proxy 模式進行重構，以解除這種耦合

·??????? 軟件設計真正要做的許多內容，就是發現職責并把那些職責相互分離

OCP，開放封閉原則：軟件實體（類、模塊、函數等等）應該是可擴展的，但是不可修改的

·??????? 任何系統在其生命周期內都回變化

·??????? 變化應該是導致添加新的代碼，而不是修改已經正常運行的代碼

·??????? OCP的關鍵是抽象

·??????? 接口和客戶的關系要比實現它的類和客戶的關系更密切

·??????? 策略模式和模板模式是用以滿足OCP的最常用方法

·??????? 沒有對于所有情況都貼切的模型，也即不可能完全封閉，所以應該預先猜測出最有可能的變化種類

·??????? 拒絕不成熟的抽象和抽象本身一樣重要

LSP，LISKOV可替換原則：子類型必須能夠替換它們的基類型

·??? ????對于LSP的違反也潛在的違反了OCP

·??????? 正方形從長方形繼承的例子微妙的違反了這種原則

·??????? 在考慮一個特定的設計是否恰當時，不能孤立地來看這個解決方案，必須根據設計的使用者所做出的合理假設來審視它

·??????? 對象的行為方式是軟件真正所關注的問題， IS A 關系是就行為而言的

·??????? 派生類只能使用相等或更弱的前置條件來替換原始的前置條件，只能使用相等或更強的前置條件來替換原始的后置條件。

·??????? 完成的功能少于基類的派生類通常不能替換基類，也不符合LSP

·??????? 派生類不應該拋出基類不能預計的異常，否則違反LSP

DIP，依賴倒置原則：高層模塊不應該依賴于底層模塊，二者都應該依賴于抽象

·??????? 抽象不應該依賴于細節，細節應該依賴于抽象

·??????? 所有結構良好的面向對象架構都具有清晰的層次定義，每個層次通過一個定義良好的受控接口向外提供一組內聚的服務

·??????? 一個對象持有另外一個具體對象的引用可能破壞了DIP

·??????? 策略不應該依賴于細節，細節和策略都應該依賴于抽象

·??? ????如果依賴關系是倒置的，那么就是面向對象的設計，否則就是過程化的設計。

ISP，接口隔離原則：不應該強迫客戶依賴于他們不用的方法，將不同的接口分離，而不是集合

·??????? 如果強迫客戶程序依賴于那些他們不使用的方法，那么這些客戶程序就面臨著由于這些未使用方法的改變而帶來的變更。

·??????? 使用委托分離接口

·??????? 使用多重集成分離接口

?

轉載于:https://www.cnblogs.com/allenzhaox/archive/2012/08/14/3201815.html

總結

以上是生活随笔為你收集整理的面向对象原则之GOF是招式，九大原则才是精髓的全部內容，希望文章能夠幫你解決所遇到的問題。

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