聊過了類別的封裝，我們要繼續實例討論物件導向的第二特性，
也就是所謂擴充的能力。

這有點像是在玩遊戲，

假設你在遊戲裡操作著一隻小豬，這隻小豬有一個特技叫做「吃」，
每次當你遇到某個謎題時，都必需讓小豬「吃」的能力成長，

可能需要吃鐵，吃火，吃土…等等，
而每當你拿到一種新的「吃」的能力，小豬的封號也會隨之改變。

上面這個情景很類似我們對於物件導向擴充的描述，
讓我們繼續延伸前一篇的程式內容，把這個遊戲情景給套用進去

目前我們手上持有的是一個叫 dataHandler 的類別，
裡面一共具有三種不同的輸出方式，分別是

output_select
output_list
output_radio

仔細想想，每次都我們輸入資料產生出一個物件時，
實際上真正會使用到的輸出行為都只是三種中的其中一種，

那換個角度，我們是否能讓這個處理資料的類別具有合適的擴充能力？

ok，沒有命題就不會有 fu，我們需要一個假設性的命題，

如果當你在執行這個案子的時候，你敏銳的觸感神經已經預計到，
客戶很有可能又額外提出六種輸出方式和三種統一驗證，
那這個時候要做什麼就很明確了，

我們需要這個類別具有輸出上的可擴充性，套用故事裡的情境，
也就是這個小豬（類別），需要可以增加不同的吃（輸出）的能力。

當然最簡單的方法就是增加類別內的 output_* 函式，
反正客戶要幾個就加給他幾個，

但也可以這樣思考，我們有沒有可能把整個擴充方式從扁平改成立體？

既然現在面對的擴充是針對「輸出」這件事，
那就來規規矩矩把輸出部份給抽象化，

於是原本的類別會變成：

class dataHandler {

var $_data = Array ();

function __construct ($data) { （省略） }
function data_remove_sexy () { （省略） }
function data_check_add_admin () { （省略） }

function output () {
// 空的
}
}

仔細看，三種不同的 output 此刻只剩下一種，
而且這個 output 函式還是個貨真價實的空蕩蕩的函式，裡面沒有半行程式碼，

為什麼呢？

因為我們要從原本「在類別內的橫式擴充」，
改成「藉由類別衍生所產生的直式擴充」，

剛剛上面這個 class dataHandler 其實只是一個初始類別，
真正可以拿來使用的會是下面這三個子類別：

class dataHandler_OutputSelect extends dataHandler {

function output () {
// 輸出 select 的程式碼
}
}

class dataHandler_OutputList extends dataHandler {

function output () {
// 輸出 list 的程式碼
}
}

class dataHandler_OutputRadio extends dataHandler {

function output () {
// 輸出 radio 的程式碼
}
}

如果你需要進行一個 select 輸出，你會這樣使用：

$data = mysql_fetch_* ($sql);
$dh = new dataHandler_OutputSelect ($data);

$dh->output ();


如果今天是一個 radio 輸出，你會這樣使用

$data = mysql_fetch_* ($sql);
$dh = new dataHandler_OutputRadio ($data);

$dh->output ();


我知道板友們一定會開始有種被騙的感覺，這跟

$dh->output_select () 和 $dh->output_radio ()

的作法有什麼不同？而且感覺還多寫了一堆 code（額外三個 class）！


請容小弟解釋一下，這兩種不同作法當中存在著很巨大的差異，

其一是這樣的程式在擴充上會更清楚明瞭，

因為往往一個類別不會只有單個函式需要做擴充，
如果同一個類別內存在著一堆相似又不同的函式，那真的是閱讀和維護上的痛苦。


其二是這樣的作法讓物件本身操作具有了一致性，

只要是 dataHandler 的子類別，
你永遠知道它具有一個關鍵的函式是 output，而且可以毫不猶豫地呼叫它，

這點非常重要，但我們會在下一篇裡面再來詳談，
因為也就是垂直擴充的物件具有了操作的一致化，第三個物件導向特性才得以成立


其三，則是一個比較難以理解的概念，那就是「決策點」的不同，

（這部份如果看不懂也沒有太大關係，因為需要有經驗才比較能體會）

如果要打個比方，「決策」的概念比較像是籃球賽裡面，
你有整整 30 秒可以出手，跟被強迫在最後 0 秒出手的不同是一樣的，

這樣講好了，

當我們在嘗試把一整個程式邏輯慢慢拆解成幾種類別時，
有的類別存在週期會很長，有的則是很短，

也就是說，

有些類別會在你程式一開始的時候就已經產生物件，並持續使用到最後，
（最常見的就是封裝成類別的資料庫操作）

有的類別則是「當下產出物件」-「當下使用」而已，
（就像是我們剛剛的資料輸出類別）

所以此時你在設計程式流程時會有兩個選擇，

從類別 new 出物件時做決策，
（像決定你要使用哪一種輸出類別，
dataHandler_OutputSelect 還是 dataHandler_OutputRadio）

或是在最後函式呼叫時做決策，
（像決定你要使用哪一種輸出函式，
dataHandler 下的 $dh->output_select 還是 $dh->output_radio）


這當中各有各的使用時機，就端看你整體程式的運作流程要怎麼設計來決定，
其中很多複雜的運用同樣也是在導入了設計模式之後才會發現的。


講到這裡，物件導向的第二特性 - 繼承也差不多講完了。

關於繼承的詳細定義和宣告方式，不熟悉的板友可以再去看一下，
這部份小弟就不贅言了。



--
頭痛中…（炸）

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.45.241.224