在物件導向設計中，抽象類別別與界面的相似性往往造成了設計師的困擾，進而在使用上產生混淆，本篇文章希望能夠透過幾個不同的觀點來描述這兩之間的差異性。
概念上的差異
我們先回到物件導向中關於類別繼承的基本解釋，子類別別與父類別別（註一）之間的關係可以說是一種「Is A」的關係。聽過的會覺得很正常，沒聽過的就會丈二金剛摸不著頭腦。
先舉一個簡單的例子，假設有一個叫做車子的類別，另外有一個叫做卡車的類別。如果卡車是繼承了車子類別別而成為車子的子類別別，我們可以就說卡車「Is A」車子，也就是說卡車是車子的一種。這樣講應該很容易理解。
那麼抽象類別別呢（Abstract Class）？原則上最簡單的解釋是，抽象類別別便是在領域概念中無法具體化的類別。
這樣講似乎還是很籠統，我們再舉一個簡單的例子。假設有一個叫做「形狀」的類別，而「圓形」類別與「方形」類別則是「形狀」類別的子類別別。在這個例子中，「形狀」很明顯的是一種抽像的概念，並無法具體化，因此在設計時，我們便可以選擇將「形狀」定義為一個抽象類別別。
由於「圓形」是「形狀」的子類別別，因此「圓形」具備了「形狀」的一切能力，如果是在繪圖軟體中，「圓形」便可由「形狀」中繼承到拉近的能力。在「形狀」中，設計師便可以先將拉近的能力細節將以描述清楚，「圓形」則可直接使用。
回過頭來，我們來思考界面（Interface）的用處。在概念上，我們可以說界面是一種可以附上在任意類別上的特徵，也是一種規範。
延伸上面的例子，假設「形狀」本身且不具備儲存的能力，我們想幫「圓形」加上這個能力，但是又不想「方形」具備儲存的能力。在這個狀況裡，在父類別別「形狀」中加上儲存的能力是不可行的，因為並不是所有圖形都需要可以儲存。
為了解決這個難題，我們最直覺的方式是在「圓形」中直接加上儲存的能力。理論上這樣是可行的，延伸思考是，如果還有其它的類別，例如「三角形」，也要加上這個能力時，會不會因為設計師的不同而讓兩個類別中的儲存的能力出現不一致，其實做的卻是同一件事情的狀況？這樣狀況就會有些失控了。
此外，假設儲存這個能力是需要與一個物件「大媽」（名字隨便取，不要想太多）相配合關連的，而該「大媽」不可能滿足所有類別實作儲存時的千奇百怪的設計方式，只能滿足一種。
那該怎麼辦才好呢？前面筆者提過了，界面也可以說是一種「規範」。
如果我們將儲存的能力定義在儲存的界面中，任何類別需要增加儲存能力時，只要遵循儲存界面的定義，那麼既可完成這個需求，又可以達到一致性。反過來說，在負責儲存的「大媽」中，他也只需要針對儲存界面來完成他的工作，他並不需要瞭解到底究竟有幾百個類別需要用到他來完成儲存這個功能。
如此豈不完美？
以上筆者用概念上的解釋來說明界面與抽象類別別在用途上的差異，下一篇（註二），我們將來研究如在實作上理解兩者的差異。
註：
一、父類別別是我的Partner建議的，我本來是想用母類別，我比較敬愛母親。
二、下一篇將由我的Partner負責執筆，敬請期待。
2008/6/26 20:58|
閱讀數 : 341
|
我要推薦
|
|
文章分類:
理論基礎
訂閱