用封裝類來合理的設計PHP項目--談PHP項目中類的封裝

代碼如下	複製代碼
編碼對於合格的PHP程式員來說並不是什麼難事（也許只是花費時間長短的問題），因此系統分析和設計這一階段就顯得尤為重要。不過本文並不打算討論和需求分析、擷取商業邏輯相關的話題，而是針對系統設計方面進行探討。

面臨難題
編碼對於合格的PHP程式員來說並不是什麼難事（也許只是花費時間長短的問題），因此系統分析和設計這一階段就顯得尤為重要。對於一個擔任PHP項目的系統分析員來說，面臨著兩個難題：

1. PHP語言本身的限制。
   這 一點在複雜系統的物件導向設計中尤其顯著。PHP的物件導向特性在現有版本中雖然得到了改善，但是還不甚健全，根本不足以擔任物件導向設計的實現語言；即 使眼光長遠一些，在即將釋出的以Zend Engine 2.0支援的全新PHP中，物件導向特性也不會像現在流行的Java或者C++那樣（關於這方面的內容可以參見我在developerWorks中國網站 發表的另一篇文章）。但是如果採用完全面向過程（準確說是面向Web頁面）的方式，可以想見整個系統的設計會非常複雜，而由此帶來的編碼複雜和維護困難更 加難以應付。
2. 現有資料的嚴重缺乏。
   這是眾所周知的現象即針對Web項目的系統設計資料不足；而在這些有限資料中，關於 PHP的設計資料又非常匱乏。如果本公司或本人也沒有相關的技術積累，系統分析員只能在黑暗中摸索方法（更壞的兩種情況，一是照搬其他項目比如Java或 者C++的設計，二是認為項目簡單而不負責任的草草了事）。

 

認識面對的系統
既然如此，採用何種方法妥善處理PHP系統的分析和設計？最初的構想應該需要分清項目承擔任務的類型：

1. 涉及大量客戶本身或者客戶所在行業的商業邏輯的項目，包括辦公系統、訂單系統以及其他商業系統。
2. 簡單網站項目，包括一些需要承擔高訪問量或要求快速響應的項目比如品牌網站或者即時網頁以及其他一些網站。
3. 綜合性網站項目。通常包含多個相對獨立的子系統比如新聞子系統、論罈子系統、產品陳列子系統等等。

 

PHP 的設計初衷在於解決後兩種項目的迫切需求，語言本身對於這些項目進行了良好的改造。而眾多的PHP開發人員對這些項目也具有或多或少的經驗，相關書籍中的範 例也大都圍繞於此。相對說來第一種系統所有的資料不多，各種出版物對其內容也很少提及。因此在本文中將題所述對第一種類型的項目進行詳細講述（有關MVC 模式和類封裝），同時附帶提及第二種項目（有關駭客代碼）以及第三種項目的設計方法。當然，並不是被歸類的這些項目就只能採用本文描述的方式，系統分析員 需要權衡各方面因素加以選擇。

方案一：涉及大量商業邏輯項目
如何分離使用者介面和後台操作？如何避免將商業邏輯混淆於一般的流程式控制制中？作為一個嚴謹的商用項目，就需要考慮很多類似的問題。對於由PHP擔當的這類項目，貫徹Model-View-Controller（MVC）模式的設計是一個非常好的方法。

理論描述
在 這裡我不想多加解釋MVC模式本身--簡單的從字面上以及應用上說，通過將系統的設計分為Model模型/邏輯、View視圖/介面、 Controller控制/流程三個邏輯部分達到良好的項目效果，以此便利各部分開發人員的工作並降低日後的維護成本。（如果您熟悉JSP開發的Model 2模式，可以發現它也是MVC模式的很好體現。）就現實的項目開發而言，現存的很大問題包括網頁設計人員和程式開發人員的工作交錯和衝突以及商業邏輯嵌入 頁面造成不可重用也很難維護等等。引入MVC模式一方面可以為系統的總體設計指出明確的方向，對於Team Dev的分工也是良好的指導。

既然依照MVC模式要求對系統的總體結構在邏輯上分成三部分，那麼團隊的開發人員中也存在著針對各個部分的開發人員。

開發人員角色	相關係統邏輯	職責
網頁設計人員	View視圖/介面

<