面向對象的一些概念

參考文獻:http://www.cppblog.com/snowball/archive/2011/10/05/55051.htmlhtml

1.面向對象的三個基本特徵是:封裝、繼承、多態。

o_OOBase.gif

1.1封裝

封裝最好理解了。封裝是面向對象的特徵之一,是對象和類概念的主要特性。java

封裝,也就是把客觀事物封裝成抽象的類,而且類能夠把本身的數據和方法只讓可信的類或者對象操做,對不可信的進行信息隱藏。編程

1.2繼承

面向對象編程 (OOP) 語言的一個主要功能就是 「 繼承 」 。繼承是指這樣一種能力:它可使用現有類的全部功能,並在無需從新編寫原來的類的狀況下對這些功能進行擴展。模塊化

經過繼承建立的新類稱爲「子類」或「派生類」。函數

被繼承的類稱爲 「 基類 」 、 「 父類 」 或 「 超類 」 。編碼

繼承的過程,就是從通常到特殊的過程。spa

要實現繼承,能夠經過 「 繼承 」 ( Inheritance )和 「 組合 」 ( Composition )來實現。.net

在某些 OOP 語言中,一個子類能夠繼承多個基類。可是通常狀況下,一個子類只能有一個基類,要實現多重繼承,能夠經過多級繼承來實現。翻譯

 

繼承概念的實現方式有三類:實現繼承、接口繼承和可視繼承。設計

Ø         實現繼承是指使用基類的屬性和方法而無需額外編碼的能力;

Ø         接口繼承是指僅使用屬性和方法的名稱、可是子類必須提供實現的能力;

Ø         可視繼承是指子窗體(類)使用基窗體(類)的外觀和實現代碼的能力。

在考慮使用繼承時,有一點須要注意,那就是兩個類之間的關係應該是 「 屬於 」 關係。例如, Employee 是一我的, Manager 也是一我的,所以這兩個類均可以繼承 Person 類。可是 Leg 類卻不能繼承 Person 類,由於腿並非一我的。

抽象類僅定義將由子類建立的通常屬性和方法,建立抽象類時,請使用關鍵字 Interface 而不是 Class 。

OO 開發範式大體爲:劃分對象 → 抽象類 → 將類組織成爲層次化結構 ( 繼承和合成 ) → 用類與實例進行設計和實現幾個階段。

1.3多態

多態性( polymorphisn )是容許你將父對象設置成爲和一個或更多的他的子對象相等的技術,賦值以後,父對象就能夠根據當前賦值給它的子對象的特性以不一樣的方式運做。簡單的說,就是一句話:容許將子類類型的指針賦值給父類類型的指針。

實現多態,有二種方式,覆蓋,重載。

覆蓋,是指子類從新定義父類的虛函數的作法。

重載,是指容許存在多個同名函數,而這些函數的參數表不一樣(或許參數個數不一樣,或許參數類型不一樣,或許二者都不一樣)。

其實,重載的概念並不屬於 「 面向對象編程 」 ,重載的實現是:編譯器根據函數不一樣的參數表,對同名函數的名稱作修飾,而後這些同名函數就成了不一樣的函數(至少對於編譯器來講是這樣的)。如,有兩個同名函數: function func(p:integer):integer; 和 function func(p:string):integer; 。那麼編譯器作過修飾後的函數名稱多是這樣的: int_func 、 str_func 。對於這兩個函數的調用,在編譯器間就已經肯定了,是靜態的(記住:是靜態)。也就是說,它們的地址在編譯期就綁定了(早綁定),所以,重載和多態無關!真正和多態相關的是 「 覆蓋 」 。當子類從新定義了父類的虛函數後,父類指針根據賦給它的不一樣的子類指針,動態(記住:是動態!)的調用屬於子類的該函數,這樣的函數調用在編譯期間是沒法肯定的(調用的子類的虛函數的地址沒法給出)。所以,這樣的函數地址是在運行期綁定的(晚邦定)。結論就是:重載只是一種語言特性,與多態無關,與面向對象也無關!引用一句 Bruce Eckel 的話: 「 不要犯傻,若是它不是晚邦定,它就不是多態。 」

那麼,多態的做用是什麼呢?咱們知道,封裝能夠隱藏實現細節,使得代碼模塊化;繼承能夠擴展已存在的代碼模塊(類);它們的目的都是爲了 —— 代碼重用。而多態則是爲了實現另外一個目的 —— 接口重用!多態的做用,就是爲了類在繼承和派生的時候,保證使用 「 家譜 」 中任一類的實例的某一屬性時的正確調用。

2.泛化、聚合、組合和依賴的概念解析

2.1泛化( Generalization )

o_Generalization.gif

圖表 1 泛化

在上圖中,空心的三角表示繼承關係(類繼承),在 UML 的術語中,這種關係被稱爲泛化( Generalization )。 Person( 人 ) 是基類, Teacher( 教師 ) 、 Student( 學生 ) 、Guest( 來賓 ) 是子類。

若在邏輯上 B 是 A 的「一種」,而且 A 的全部功能和屬性對 B 而言都有意義,則容許 B 繼承 A 的功能和屬性。

例如, 教師是人, Teacher 是 Person 的「一種」( a kind of )。 那麼類 Teacher 能夠從類 Person 派生(繼承)。

若是 A 是基類, B 是 A 的派生類,那麼 B 將繼承 A 的數據和函數。

若是類 A 和類 B 絕不相關,不能夠爲了使 B 的功能更多些而讓 B 繼承 A 的功能和屬性。

若在邏輯上 B 是 A 的「一種」( a kind of ),則容許 B 繼承 A 的功能和屬性。

2.2聚合(組合)

o_aggregationBase.gif

圖表 2 組合

若在邏輯上 A 是 B 的「一部分」( a part of ),則不容許 B 從 A 派生,而是要用 A 和其它東西組合出 B 。

例如,眼( Eye )、鼻( Nose )、口( Mouth )、耳( Ear )是頭( Head )的一部分,因此類 Head 應該由類 Eye 、 Nose 、 Mouth 、 Ear 組合而成,不是派生(繼承)而成。

聚合的類型分爲無、共享 ( 聚合 ) 、複合 ( 組合 ) 三類。

2.3聚合( aggregation )

 

o_aggregation.gif

圖表 3 共享

上面圖中,有一個菱形(空心)表示聚合( aggregation )(聚合類型爲共享),聚合的意義表示 has-a 關係。聚合是一種相對鬆散的關係,聚合類 B 不須要對被聚合的類 A負責。

2.4組合( composition )

o_composition.gif

圖表 4 複合

這幅圖與上面的惟一區別是菱形爲實心的,它表明了一種更爲堅固的關係 —— 組合( composition )(聚合類型爲複合)。組合表示的關係也是 has-a ,不過在這裏, A 的生命期受 B 控制。即 A 會隨着 B 的建立而建立,隨 B 的消亡而消亡。

2.5依賴 (Dependency)

o_Dependency.gif

圖表 5 依賴

這裏 B 與 A 的關係只是一種依賴 (Dependency) 關係,這種關係代表,若是類 A 被修改,那麼類 B 會受到影響。

3接口與抽象類有什麼區別

abstract class和interface是Java語言中對於抽象類定義進行支持的兩種機制,正是因爲這兩種機制的存在,才賦予了Java強大的面向對象能力。abstract class和interface之間在對於抽象類定義的支持方面具備很大的類似性,甚至能夠相互替換,所以不少開發者在進行抽象類定義時對於abstract class和interface的選擇顯得比較隨意。其實,二者之間仍是有很大的區別的,對於它們的選擇甚至反映出對於問題領域本質的理解、對於設計意圖的理解是否正確、合理。本文將對它們之間的區別進行一番剖析,試圖給開發者提供一個在兩者之間進行選擇的依據。

3.1理解抽象類

abstract class和interface在Java語言中都是用來進行抽象類(本文中的抽象類並不是從abstract class翻譯而來,它表示的是一個抽象體,而abstract class爲Java語言中用於定義抽象類的一種方法,請讀者注意區分)定義的,那麼什麼是抽象類,使用抽象類能爲咱們帶來什麼好處呢?

在面向對象的概念中,咱們知道全部的對象都是經過類來描繪的,可是反過來卻不是這樣。並非全部的類都是用來描繪對象的,若是一個類中沒有包含足夠的信息來描繪一個具體的對象,這樣的類就是抽象類。抽象類每每用來表徵咱們在對問題領域進行分析、設計中得出的抽象概念,是對一系列看上去不一樣,可是本質上相同的具體概念的抽象。好比:若是咱們進行一個圖形編輯軟件的開發,就會發現問題領域存在着圓、三角形這樣一些具體概念,它們是不一樣的,可是它們又都屬於形狀這樣一個概念,形狀這個概念在問題領域是不存在的,它就是一個抽象概念。正是由於抽象的概念在問題領域沒有對應的具體概念,因此用以表徵抽象概念的抽象類是不可以實例化的。

在面向對象領域,抽象類主要用來進行類型隱藏。咱們能夠構造出一個固定的一組行爲的抽象描述,可是這組行爲卻可以有任意個可能的具體實現方式。這個抽象描述就是抽象類,而這一組任意個可能的具體實現則表現爲全部可能的派生類。模塊能夠操做一個抽象體。因爲模塊依賴於一個固定的抽象體,所以它能夠是不容許修改的;同時,經過從這個抽象體派生,也可擴展此模塊的行爲功能。熟悉OCP的讀者必定知道,爲了可以實現面向對象設計的一個最核心的原則OCP(Open-Closed Principle),抽象類是其中的關鍵所在。

3.2從語法定義層面看abstract class和interface

在語法層面,Java語言對於abstract class和interface給出了不一樣的定義方式,下面以定義一個名爲Demo的抽象類爲例來講明這種不一樣。

使用abstract class的方式定義Demo抽象類的方式以下:

abstract class Demo { 
abstract void method1(); 
abstract void method2(); 
… 

使用interface的方式定義Demo抽象類的方式以下:

interface Demo { 
void method1(); 
void method2(); 
… 
}

在abstract class方式中,Demo能夠有本身的數據成員,也能夠有非abstarct的成員方法,而在interface方式的實現中,Demo只可以有靜態的不能被修改的數據成員(也就是必須是static final的,不過在interface中通常不定義數據成員),全部的成員方法都是abstract的。從某種意義上說,interface是一種特殊形式的abstract class。

從編程的角度來看,abstract class和interface均可以用來實現"design by contract"的思想。可是在具體的使用上面仍是有一些區別的。

首先,abstract class在Java語言中表示的是一種繼承關係,一個類只能使用一次繼承關係。可是,一個類卻能夠實現多個interface。也許,這是Java語言的設計者在考慮Java對於多重繼承的支持方面的一種折中考慮吧。

其次,在abstract class的定義中,咱們能夠賦予方法的默認行爲。可是在interface的定義中,方法卻不能擁有默認行爲,爲了繞過這個限制,必須使用委託,可是這會 增長一些複雜性,有時會形成很大的麻煩。

在抽象類中不能定義默認行爲還存在另外一個比較嚴重的問題,那就是可能會形成維護上的麻煩。由於若是後來想修改類的界面(通常經過abstract class或者interface來表示)以適應新的狀況(好比,添加新的方法或者給已用的方法中添加新的參數)時,就會很是的麻煩,可能要花費不少的時間(對於派生類不少的狀況,尤其如此)。可是若是界面是經過abstract class來實現的,那麼可能就只須要修改定義在abstract class中的默認行爲就能夠了。

一樣,若是不能在抽象類中定義默認行爲,就會致使一樣的方法實現出如今該抽象類的每個派生類中,違反了"one rule,one place"原則,形成代碼重複,一樣不利於之後的維護。所以,在abstract class和interface間進行選擇時要很是的當心。

3.3從設計理念層面看abstract class和interface

上面主要從語法定義和編程的角度論述了abstract class和interface的區別,這些層面的區別是比較低層次的、非本質的。本小節將從另外一個層面:abstract class和interface所反映出的設計理念,來分析一下兩者的區別。做者認爲,從這個層面進行分析才能理解兩者概念的本質所在。

前面已經提到過,abstarct class在Java語言中體現了一種繼承關係,要想使得繼承關係合理,父類和派生類之間必須存在"is a"關係,即父類和派生類在概念本質上應該是相同的(參考文獻〔3〕中有關於"is a"關係的大篇幅深刻的論述,有興趣的讀者能夠參考)。對於interface 來講則否則,並不要求interface的實現者和interface定義在概念本質上是一致的,僅僅是實現了interface定義的契約而已。爲了使論述便於理解,下面將經過一個簡單的實例進行說明。

考慮這樣一個例子,假設在咱們的問題領域中有一個關於Door的抽象概念,該Door具備執行兩個動做open和close,此時咱們能夠經過abstract class或者interface來定義一個表示該抽象概念的類型,定義方式分別以下所示:

使用abstract class方式定義Door:

abstract class Door { 
abstract void open(); 
abstract void close(); 
}

使用interface方式定義Door:

interface Door { 
void open(); 
void close(); 
}

其餘具體的Door類型能夠extends使用abstract class方式定義的Door或者implements使用interface方式定義的Door。看起來好像使用abstract class和interface沒有大的區別。

若是如今要求Door還要具備報警的功能。咱們該如何設計針對該例子的類結構呢(在本例中,主要是爲了展現abstract class和interface反映在設計理念上的區別,其餘方面無關的問題都作了簡化或者忽略)?下面將羅列出可能的解決方案,並從設計理念層面對這些不一樣的方案進行分析。

解決方案一:

簡單的在Door的定義中增長一個alarm方法,以下:

abstract class Door { 
abstract void open(); 
abstract void close(); 
abstract void alarm(); 
}

或者

interface Door { 
void open(); 
void close(); 
void alarm(); 
}

那麼具備報警功能的AlarmDoor的定義方式以下:

class AlarmDoor extends Door { 
void open() { … } 
void close() { … } 
void alarm() { … } 
}

或者

class AlarmDoor implements Door { 
void open() { … } 
void close() { … } 
void alarm() { … } 

這種方法違反了面向對象設計中的一個核心原則ISP(Interface Segregation Priciple),在Door的定義中把Door概念自己固有的行爲方法和另一個概念"報警器"的行爲方法混在了一塊兒。這樣引發的一個問題是那些僅僅依賴於Door這個概念的模塊會由於"報警器"這個概念的改變(好比:修改alarm方法的參數)而改變,反之依然。

解決方案二:

既然open、close和alarm屬於兩個不一樣的概念,根據ISP原則應該把它們分別定義在表明這兩個概念的抽象類中。定義方式有:這兩個概念都使用abstract class方式定義;兩個概念都使用interface方式定義;一個概念使用abstract class方式定義,另外一個概念使用interface方式定義。

顯然,因爲Java語言不支持多重繼承,因此兩個概念都使用abstract class方式定義是不可行的。後面兩種方式都是可行的,可是對於它們的選擇卻反映出對於問題領域中的概念本質的理解、對於設計意圖的反映是否正確、合理。咱們一一來分析、說明。

若是兩個概念都使用interface方式來定義,那麼就反映出兩個問題:一、咱們可能沒有理解清楚問題領域,AlarmDoor在概念本質上究竟是Door仍是報警器?二、若是咱們對於問題領域的理解沒有問題,好比:咱們經過對於問題領域的分析發現AlarmDoor在概念本質上和Door是一致的,那麼咱們在實現時就沒有可以正確的揭示咱們的設計意圖,由於在這兩個概念的定義上(均使用interface方式定義)反映不出上述含義。

若是咱們對於問題領域的理解是:AlarmDoor在概念本質上是Door,同時它有具備報警的功能。咱們該如何來設計、實現來明確的反映出咱們的意思呢?前面已經說過,abstract class在Java語言中表示一種繼承關係,而繼承關係在本質上是"is a"關係。因此對於Door這個概念,咱們應該使用abstarct class方式來定義。另外,AlarmDoor又具備報警功能,說明它又可以完成報警概念中定義的行爲,因此報警概念能夠經過interface方式定義。以下所示:

abstract class Door { 
abstract void open(); 
abstract void close(); 

interface Alarm { 
void alarm(); 

class AlarmDoor extends Door implements Alarm { 
void open() { … } 
void close() { … } 
void alarm() { … } 
}

這種實現方式基本上可以明確的反映出咱們對於問題領域的理解,正確的揭示咱們的設計意圖。其實abstract class表示的是"is a"關係,interface表示的是"like a"關係,你們在選擇時能夠做爲一個依據,固然這是創建在對問題領域的理解上的,好比:若是咱們認爲AlarmDoor在概念本質上是報警器,同時又具備Door的功能,那麼上述的定義方式就要反過來了。

小結

  1. abstract class 在 Java 語言中表示的是一種繼承關係,一個類只能使用一次繼承關係。可是,一個類卻能夠實現多個interface。
  2. 在abstract class 中能夠有本身的數據成員,也能夠有非abstarct的成員方法,而在interface中,只可以有靜態的不能被修改的數據成員(也就是必須是static final的,不過在 interface中通常不定義數據成員),全部的成員方法都是abstract的。
  3. abstract class和interface所反映出的設計理念不一樣。其實abstract class表示的是"is-a"關係,interface表示的是"like-a"關係。 
  4. 實現抽象類和接口的類必須實現其中的全部方法。抽象類中能夠有非抽象方法。接口中則不能有實現方法。
  5. 接口中定義的變量默認是public static final 型,且必須給其初值,因此實現類中不能從新定義,也不能改變其值。
  6. 抽象類中的變量默認是 friendly 型,其值能夠在子類中從新定義,也能夠從新賦值。 
  7. 接口中的方法默認都是 public,abstract 類型的。

結論

  abstract class 和 interface 是 Java語言中的兩種定義抽象類的方式,它們之間有很大的類似性。可是對於它們的選擇卻又每每反映出對於問題領域中的概 念本質的理解、對於設計意圖的反映是否正確、合理,由於它們表現了概念間的不一樣的關係(雖然都可以實現需求的功能)。這其實也是語言的一種的慣用法,但願讀者朋友可以細細體會。
相關文章
相關標籤/搜索