要學 PHP 裡的 OOP 時建議

之前在 PTT 上寫的，現在轉過來。
要學 PHP 裡的 OOP 時建議

1. 搞清楚為什麼要用 OOP
2. 去用一套 framework 看看別人怎麼設計，要怎麼使用。
3. 等經驗夠了，自己試著設計，一開始當然會做出一堆的廢 class

要知道怎樣的 class 是合適的，沒有練過幾個案子，光看書恐怕很難有心得。我們在使用 PHP 時若要採用 OOP 的話，在實務上有幾個考量：

1. 專案的本質

程式用來解決問題的（若要說是來賺錢的，我也不反對），所以在採用某項技術時都要問一下採用了這技術對於解決問題有幫助嗎？
若決定採用 PHP ，若不是因為只會 PHP 的話（我想這是個爛理由），一定是這個案子使用 PHP 是合適的。
通常什麼情況下 PHP 是合適的呢？它的最大宗的應用還是在網站開發上面。（當然只要是高手， PHP 可以用在很多方面）
我發現若使用 PHP 製作網站，除非是在一定規模的案子中，邏輯有點複雜，，才需要用 OOP 讓物件們互動。
雖然我是個 OO 控，但是我還是得承認，不夠大的案子直接 coding 可能還比較快結束（前提是在不使用任何的 framework 情況下）。
同時我也發現就算在 PHP 中使用了 OOP，若要應付複雜的 business rule 和一些不能夠出錯的場合（如算錢），仍然不太合適，主要原因不是 OOP 的問題，而是出在 PHP 身上， 因為 PHP 這語言的設計實在是太隨便了！把持不住的人太容易用 PHP 寫出爛程式，出錯的機會大大的增加，相比之下 Java 就嚴謹多了。這並不是說 Java 不會寫出低安全的東西，而是語言在設計上先天就嚴謹。但是對於純粹的網站開發上，Java 又嫌囉嗦。
若要有良好的錯誤處理的話，我想還是找個 framework 來用會比較好，不然用 PHP 原生的方式處理例外和錯誤相當的累人。
若專案需要採用某個 framework，這時就不得不採用 OOP 了。因為我還沒有見過不使用物件導向技術的 framework

提外話：

若真要應付複雜的 business rule 建議採用 web service將複雜的邏輯包裝起來，而 web service 的內容可以用其它的技術或是讓 PHP 高手來寫，這樣可以降低出錯的機會。

2. 開發人員的功力

說實在的 OOP 沒有那麼好學，若用 C++ 和 Java ，光是要把它們對於 OOP 的語法搞清楚就很累人了，何況還要了解它們的意義！ 所以要使用 OOP 的話，開發人員要有一定的素質，才能顯出 OOP 的威力。 在 PHP 裡使用 OOP ，也一定要把些基本的 OOP 語法學好，說實在話比起其它的語言，PHP裡的語法規則是簡單太多了，若還搞不懂，那就實在是太不用功了。偏偏有耐心學完、搞清楚、把它用上的沒幾個，若你是其中一個恭喜你，這世界用功的人實在太少。 若是 OOP 的語法會了，那一些 OO 的原則了不了解？會不會用呢？ 目前的 framework 中 MVC 架構大行其道，但是 M 是什麼？ V 是什麼？ C 是什麼？它的意義是什麼，開發人員能不能講出在做 OOA&D 時 MVC 是藏在哪裡？M 就一定對到資料庫嗎？ C 應該負責哪些事呢？
在實務中最常見的 OO 原則是單一責任原則，這是一個產生高凝聚力程式碼的方式。這個原則說穿了沒什麼，要了解它也不用五分鐘，但是偏偏很多人不知道也不會用。在不會用這一原則的情況下開發人員很容易的造出了一堆零碎而不好用的 class。
當我看到一張資料表就一個 model，有必要嗎？真正要做的事是什麼？要用的 method 是屬於誰的？了解這些問題， OOP 的威力才出得來。 若開發人員造出了一堆零碎而不好用的 class，這樣不僅違反 OO 的規則，維護上還比不使用 OO 還來得麻煩。遇到了這種情況，團隊裡就會有人反彈說為什麼我們要使用 OOP
我們只是做個網站而已，何苦要搞得那麼複雜....

 題外話

說起來PHP 是個不算太優雅語言，可能是當初設計時沒想到它會紅，但是紅了以後就又來不及改。相比之下個人覺得同類輕量級語言 python, ruby 都還比它好。但是 OO 功力差的開發人員，給它再好的語言也沒有用 XD

3. 開發團隊

開發團隊在案子進來的時候，就是利用 OOA&D 在進行嗎？ PM

• 帶頭的 PM 談需求時做得出 USE CASE 嗎？

SA

• 看得懂 PM 的需求嗎？
• 有辦法從需求中規劃出所需要的物件嗎？
• UML是畫好看的還是真有拿來溝通用？大部份使用 UML 只為了 CMMI，它的價值都沒有被發揮出來。

SD

• 願意學嗎？