## 連載:面向對象葵花寶典:思想、技巧與實踐(9) - “抽象類” 詳解
抽象類是一種特殊的類,其特殊性在于**抽象類只能用于繼承,不能被實例化為具體的對象**。例如在Java中不能new一個抽象類,但可以extends一個抽象類。
?
抽象類的定義其實很簡單,但其使用并不那么簡單,有幾個問題我們需要深入研究一下。
?
**第一個問題是:有了類,為什么還要抽象類,為什么設計一種只能繼承,不能實例化的類?**
答案就在于:某些場景下普通類不夠用。例如,“蘋果”、“桔子”、“香蕉”都是“水果”,這里的“水果”就是一個抽象類。你可以說你喜歡吃“水果”,但你真正吃“水果”的時候,要么是“蘋果”,要么是“桔子”,要么是“香蕉”。。。。。。但你絕不可能真正吃到一個叫做“水果”的東東。
?
從設計的角度來看,抽象類是更高層次的抽象。如果說普通類是從現實對象抽象出來的,那么抽象類就是基于類而抽象出來的。例如上面的樣例,從“蘋果”、“桔子”、“香蕉”這幾個普通類,抽象出了“水果”這個類。
?
從實現的角度來看,抽象類與普通類不同的地方在于:抽象類有的存在抽象方法(方法只有聲明,沒有定義),子類必須自己定義這些抽象方法,而不能像普通的方法一樣,通過繼承就可以獲得父類的方法。這一點上來看,抽象類和接口有點類似。
?
**第二個問題是:抽象類和接口有什么區別,為什么有了接口,還要有抽象類?**
答案就在于:抽象類本質上還是類,強調一組事物的相似性,包括屬性和方法的相似性;而接口只強調方法的相似性,并且僅僅體現在方法聲明上的相似性,而沒有方法定義上的相似性。
?
例如:假設我們設計一個游戲,其中使用“蘋果”、“桔子”、“香蕉”來做“補血”,“蘋果”、“桔子”、“香蕉”都有“顏色”、“重量”這樣的屬性,但每種水果的補血方式是不一樣的。這種情況下,使用抽象類可以很好的表達,我們設計一個抽象類“水果”,將“顏色”、“重量”作為“水果”的屬性,“獲取顏色”、“獲取重量”、“減少重量”等方法作為“水果”的方法,將“補血”作為“水果”的抽象方法。這樣設計能夠大大減少“蘋果”、“桔子”、“香蕉”幾個普通類的實現工作量,它們只需要實現“補血”方法,其它的屬性和方法都只需繼承“水果”類即可。而如果采用接口的方式實現,則“蘋果”、“桔子”、“香蕉”每個類都需要自己增加“顏色”、“重量”屬性,增加“獲取顏色”、“獲取重量”、“減少重量”、“補血”等方法,工作量和代碼量大大增加。
?
綜合上述的分析,我們可以看出,抽象類看起來是一個介于類和接口之間的一個概念,同時具備類和接口的部分特性。
- 前言
- (1) - 程序設計思想的發展
- (2) - 面向對象語言發展歷史
- (3) - 面向過程 vs 面向對象
- (4) - 面向對象是瑞士軍刀還是一把錘子?
- (5) - 面向對象迷思:面向對象導致性能下降?
- (6) - 不要說你懂“類”
- (7) - “對象”新解
- (8) - “接口” 詳解
- (9) - “抽象類” 詳解
- (10) - “抽象” 詳解
- (11) - “封裝” 詳解
- (12) - “繼承” 詳解
- (13) - “多態” 詳解
- (14) - 面向對象開發技術流程
- (15) - 需求詳解
- (16) - 需求分析終極目的
- (17) - 需求分析518方法
- (18) - 用例分析
- (19) - 功能點提取
- (20) - 用例圖的陷阱
- (21) - SSD
- (22) - 領域模型
- (23) - 領域建模三字經
- (24) - 設計模型
- (25) - 類模型
- (26) - 類模型三板斧
- (27) - 動態模型設計
- (28) - 設計原則:內聚&耦合
- (29) - 高內聚低耦合
- (30) - SRP原則
- (31) - OCP原則
- (32) - LSP原則
- (33) - ISP原則
- (34) - DIP原則
- (35) - NOP原則
- (36) - 設計原則如何用?
- (37) - 設計模式:瑞士軍刀 or 錘子?
- (38) - 設計模式之道
- (39) - 設計原則 vs 設計模式
- (40) - DECORATOR模式
- (完)- 書籍已經出版