網站製作學習誌

有個問題請教：

如果有個抽象類別，他裡面的方法純粹是一些機制的產生和互動，而繼承他的類別，跟這個抽象類別間，並沒有分類學上「是個什麼」的關係，反而比較接近「能做什麼」。

不過若是用介面來實做的話，會發生大量的 copy / paste ，那該如何作選擇呢？

To tokimeki:

我是認為介面比較偏向宣告的一種，告訴 Client 端它能做些什麼。

舉個例子：人和車是屬於不同的繼承體系，但是它們都會跑。那麼我怎麼讓 Client 知道它們都會跑？ 所以我必須讓它們實作一個「會跑的」這個介面，而這個介面包含了一個「跑」的方法。

然而人怎麼跑的？或是車怎麼跑的？這個就是它們自己要實作的，因為一般人是用腿跑，車是用輪子跑的。

如果會有大量的 copy/paste ，我想我會採用 plugin / behavior 的方式，將類別交由外部的機制來處理，也就是 Strategy 模式。

換句話說，我可以把實際上跑的這個實作拿到另一個類別中，然後讓「跑」這個方法去呼叫它。舉例來說，我把「用輪子跑」這個實作獨立成一個 Behavior 類別，讓車子的「跑」去呼叫它；而不屬於車子體系，但也需要「用輪子跑」的類別，就可以直接使用這個 Behavior ，這樣就不會有大量 copy / paste 的問題了。

以上是我的想法，歡迎討論 :)

我這邊說的比較接近大量委託方法的問題，你看過我寫的插件類別，應該比較能理解我的焦慮。

舉個實例來說，如果我要寫一個 DB Layer 的套件，希望能把 PHP 支援的資料庫都包山包海納進來，在這個 DB Layer 我又希望它能分層切割成幾個不同 Plugin (DML, DDL, 其他的操作等等)、或是對應特殊資料結構的操作（比如對資料表的狀狀結構），這算是個有點複雜的問題，我想光用策略模式來作還是會有多餘的程式碼出現。

針對這樣的問題，你有什麼意見嗎？

To tokimeki:

還真的有點難以理解，請原諒我的愚昧....Orz

我想你要的可能是 Abstract Factory 吧？把這些功能先以抽象的方式表達出來，然後交給底下的子類別去個別實作相關的功能。目前 Zend_Db 是這樣做的，你可以參考看看。

另外狀狀結構是指？ (我猜你可能是筆誤，但我無法聯想出正確的名詞。)

hmm....所以說，實作 正妹Interface 是不正確的，我們應該先實作 正妹的 Abstract 之後再去實作 追正妹的 Interface 囉？

@hermes:

此 interface 非彼 interface 呀~