面向物件的特徵

主要有抽象、繼承、封裝和多型四個方面，下面是我們來詳細分析它們的含義：

- 抽象：

抽象是將一類物件的共同特徵總結出來構造類的過程，包括資料抽象和行為抽象兩方面。抽象只關注物件有哪些屬性和行為，並不關注這些行為的細節是什麼。 

- 繼承：

繼承是從已有類得到繼承資訊建立新類的過程。提供繼承資訊的類被稱為父類（超類、基類）；得到繼承資訊的類被稱為子類（派生類）。繼承讓變化中的軟體系統有了一定的延續性，同時繼承也是封裝程式中可變因素的重要手段。 

拓展：

    由於實際需要，某個類具有兩個或兩個以上的維度變化（例如我們去吃麵：有拉麵和板面兩種選擇，在這兩中選擇之上還有牛肉麵和雞蛋麵兩種選擇，在這兩層之上還有清淡、微辣、超辣等選擇），如果僅僅使用繼承實現這種需求，設計將會變得非常臃腫，這裡我們可以引入橋接模式。橋接模式的做法就是把程式變化的部分抽象出來，讓變化的部分與主類分離開來，從而將多個維度的變化徹底分離。最後提供一個管理類來組合不同維度上的變化，通過這個組合來滿足業務需要。橋接模式在JavaEE

- 封裝：

通常認為封裝是把資料和操作資料的方法繫結起來，對資料的訪問只能通過已定義的介面。面向物件的本質就是將現實世界描繪成一系列完全自治、封閉的物件。我們在類中編寫的方法就是對實現細節的一種封裝；我們編寫一個類就是對資料和資料操作的封裝。可以說，封裝就是隱藏一切可隱藏的東西，只向外界提供最簡單的程式設計介面（

拓展：

    可以想想普通洗衣機和全自動洗衣機的差別，明顯全自動洗衣機封裝更好因此操作起來更簡單；我們現在使用的智慧手機也是封裝得足夠好的，因為幾個按鍵就搞定了所有的事情。 

- 多型性：

多型性是指允許不同子型別的物件對同一訊息作出不同的響應。簡單的說就是用同樣的物件引用呼叫同樣的方法但是做了不同的事情。多型性分為編譯時的多型性和執行時的多型性。如果將物件的方法視為物件向外界提供的服務，那麼執行時的多型性可以解釋為：當A

 執行時的多型是面向物件最精髓的東西，要實現多型需要做兩件事：

1). 方法重寫（子類繼承父類並重寫父類中已有的或抽象的方法）；

2). 物件造型（用父型別引用引用子型別物件，這樣同樣的引用呼叫同樣的方法就會根據子類物件的不同而表現出不同的行為）。

面向物件的“六原則一法則”：

單一職責原則、開閉原則、依賴倒轉原則、里氏替換原則、介面隔離原則、合成聚合複用原則和迪米特法則。

- 單一職責原則

一個類只做它該做的事情。

單一職責原則想表達的就是"高內聚"，寫程式碼最終極的原則只有六個字"高內聚、低耦合"，就如同葵花寶典或辟邪劍譜的中心思想就八個字"欲練此功必先自宮"，所謂的高內聚就是一個程式碼模組只完成一項功能，在面向物件中，如果只讓一個類完成它該做的事，而不涉及與它無關的領域就是踐行了高內聚的原則，這個類就只有單一職責。我們都知道一句話叫"因為專注，所以專業"，一個物件如果承擔太多的職責，那麼註定它什麼都做不好。這個世界上任何好的東西都有兩個特徵，一個是功能單一，好的相機絕對不是電視購物裡面賣的那種一個機器有一百多種功能的，它基本上只能照相；另一個是模組化，好的自行車是組裝車，從減震叉、剎車到變速器，所有的部件都是可以拆卸和重新組裝的，好的乒乓球拍也不是成品拍，一定是底板和膠皮可以拆分和自行組裝的，一個好的軟體系統，它裡面的每個功能模組也應該是可以輕易的拿到其他系統中使用的，這樣才能實現軟體複用的目標。

- 開閉原則

軟體實體應當對擴充套件開放，對修改關閉。

在理想的狀態下，當我們需要為一個軟體系統增加新功能時，只需要從原來的系統派生出一些新類就可以，不需要修改原來的任何一行程式碼。

要做到開閉有兩個要點：①抽象是關鍵，一個系統中如果沒有抽象類或介面系統就沒有擴充套件點；②封裝可變性，將系統中的各種可變因素封裝到一個繼承結構中，如果多個可變因素混雜在一起，系統將變得複雜而換亂，如果不清楚如何封裝可變性，可以參考《設計模式精解》一書中對橋樑模式的講解的章節。

- 依賴倒轉原則

面向介面程式設計。

該原則說得直白和具體一些就是宣告方法的引數型別、方法的返回型別、變數的引用型別時，儘可能使用抽象型別而不用具體型別，因為抽象型別可以被它的任何一個子型別所替代，請參考下面的里氏替換原則。

-里氏替換原則

任何時候都可以用子型別替換掉父型別。

關於里氏替換原則的描述，Barbara Liskov女士的描述比這個要複雜得多，但簡單的說就是能用父型別的地方就一定能使用子型別。里氏替換原則可以檢查繼承關係是否合理，如果一個繼承關係違背了里氏替換原則，那麼這個繼承關係一定是錯誤的，需要對程式碼進行重構。例如讓貓繼承狗，或者狗繼承貓，又或者讓正方形繼承長方形都是錯誤的繼承關係，因為你很容易找到違反里氏替換原則的場景。需要注意的是：子類一定是增加父類的能力而不是減少父類的能力，因為子類比父類的能力更多，把能力多的物件當成能力少的物件來用當然沒有任何問題。

- 介面隔離原則

介面要小而專，絕不能大而全。

臃腫的介面是對介面的汙染，既然介面表示能力，那麼一個介面只應該描述一種能力，介面也應該是高度內聚的。例如，琴棋書畫就應該分別設計為四個介面，而不應設計成一個介面中的四個方法，因為如果設計成一個介面中的四個方法，那麼這個介面很難用，畢竟琴棋書畫四樣都精通的人還是少數，而如果設計成四個介面，會幾項就實現幾個介面，這樣的話每個介面被複用的可能性是很高的。Java中的介面代表能力、代表約定、代表角色，能否正確的使用介面一定是程式設計水平高低的重要標識。

- 合成聚合複用原則

優先使用聚合或合成關係複用程式碼。

通過繼承來複用程式碼是面向物件程式設計中被濫用得最多的東西，因為所有的教科書都無一例外的對繼承進行了鼓吹從而誤導了初學者，類與類之間簡單的說有三種關係，Is-A關係、Has-A關係、Use-A關係，分別代表繼承、關聯和依賴。其中，關聯關係根據其關聯的強度又可以進一步劃分為關聯、聚合和合成，但說白了都是Has-A關係，合成聚合複用原則想表達的是優先考慮Has-A關係而不是Is-A關係複用程式碼，原因嘛可以自己從百度上找到一萬個理由，需要說明的是，即使在Java的API中也有不少濫用繼承的例子，例如Properties類繼承了Hashtable類，Stack類繼承了Vector類，這些繼承明顯就是錯誤的，更好的做法是在Properties類中放置一個Hashtable型別的成員並且將其鍵和值都設定為字串來儲存資料，而Stack類的設計也應該是在Stack類中放一個Vector物件來儲存資料。記住：任何時候都不要繼承工具類，工具是可以擁有並可以使用的，而不是拿來繼承的。

- 迪米特法則

迪米特法則又叫最少知識原則，一個物件應當對其他物件有儘可能少的瞭解。

迪米特法則簡單的說就是如何做到"低耦合"，門面模式和調停者模式就是對迪米特法則的踐行。

拓展：

對於門面模式可以舉一個簡單的例子，你去一家公司洽談業務，你不需要了解這個公司內部是如何運作的，你甚至可以對這個公司一無所知，去的時候只需要找到公司入口處的前臺美女，告訴她們你要做什麼，她們會找到合適的人跟你接洽，前臺的美女就是公司這個系統的門面。再複雜的系統都可以為使用者提供一個簡單的門面，Java Web開發中作為前端控制器的Servlet或Filter不就是一個門面嗎，瀏覽器對伺服器的運作方式一無所知，但是通過前端控制器就能夠根據你的請求得到相應的服務。調停者模式也可以舉一個簡單的例子來說明，例如一臺計算機，CPU、記憶體、硬碟、顯示卡、音效卡各種裝置需要相互配合才能很好的工作，但是如果這些東西都直接連線到一起，計算機的佈線將異常複雜，在這種情況下，主機板作為一個調停者的身份出現，它將各個裝置連線在一起而不需要每個裝置之間直接交換資料，這樣就減小了系統的耦合度和複雜度。

如下圖所示：

使用門面模式後：

迪米特法則用通俗的話來將就是不要和陌生人打交道，如果真的需要，找一個自己的朋友，讓他替你和陌生人打交道。