PHP 5.0物件模型深度探索之起步

　　物件導向編程被設計來為大型軟體項目提供解決方案,尤其是多人合作的項目. 當原始碼增長到一萬行甚至更多的時候,每一個更動都可能導致不希望的副作用. 這種情況發生於模組間結成秘密同盟時候,就像第一次世界大戰前的歐洲。
　　//haohappy注:喻指模組間的關聯度過高,相互依賴性太強.更動一個模組導致其它模組也必須跟著更動。
　　想像一下,如果有一個用來處理登入的模組允許一個信用卡處理模組來分享它的資料庫連接. 當然出發點是好的,節省了進行另一個資料庫連接的支出.然而有時,登入處理模組改變了其中一個變數的名字,就可能割斷了兩者間的協議.導致信用卡模組的處理出錯,進而導致處理的模組出錯. 很快地,體系中所有無關的模組都可能由此出錯.
　　因此,我覺得有點戲劇性地,絕大多數程式員都對耦合和封裝心存感激. 耦合是兩個模組間依賴程度的量度. 耦合越少越好.我們希望能夠從已有的項目中抽走一個模組並在另一個新項目中使用.
　　我們也希望在某個模組內部大規模的更動而不用擔心對其他模組的影響. 封裝的原則可以提供這個解決方案.模組被看待成相對獨立,並且模組間的資料通訊通過介面來進行. 模組不通過彼此的變數名來窺探另一個模組,它們通過函數來禮貌地發送請求.
　　封裝是你可以在任何程式設計語言中使用的一個原則. 在PHP和許多面向過程的語言中,可以偷懶是很有誘惑的.沒有什麼可以阻止你通過模組來構建一個假想的WEB. 物件導向編程是使程式員不會違背封裝原則的一種方法.
　　在物件導向編程中,模組被組織成一個個對象. 這些對象擁有方法和屬性. 從抽象的角度來看,方法是一個對象的所做的動作,而屬性是對象的特性.從編程角度來看,方法就是函數而屬性是變數. 在一個理想化的物件導向體系中,每個部份都是一個對象. 體系由對象及對象間通過方法來形成的聯絡構成.
　　一個類定義了對象的屬性. 如果你在烘烤一組甜餅對象,那麼類將會是甜餅機. 類的屬性和方法是被調用的成員. 人們可以通過說出資料成員或者方法成員來表達.
　　每種語言提供了不同的途徑來訪問對象. PHP從C 中借用概念,提供一個資料類型用來在一個標識符下包含函數和變數。最初設計PHP的時候，甚至PHP3被開發出時，PHP並不打算提供開發超過10萬行代碼的大型項目的能力。隨著PHP和Zend引擎的發展，開發大型項目變得有可能，但無論你的項目規模多大，用類來書寫你的指令碼將可以讓代碼實現重用。這是一個好主意，特別當你願意與別人分享你的代碼的時候。