PHP程式開發的原則匯總

你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起 。 ----- Arthur J.Riel

(1)所有資料都應該隱藏在所在的類的內部。

(2)類的使用者必須依賴類的共有介面，但類不能依賴它的使用者。

(3)盡量減少類的協議中的訊息。

(4)實現所有類都理解的最基本公有介面[例如，拷貝操作(深拷貝和淺拷貝)、相等性判斷、正確輸出內容、從ASCII描述解析等等]。

(5)不要把實現細節(例如放置共用代碼的私人函數)放到類的公有介面中。

如果類的兩個方法有一段公用代碼，那麼就可以建立一個防止這些公用代碼的私人函數。

(6)不要以使用者無法使用或不感興趣的東西擾亂類的公有介面。

(7)類之間應該零耦合，或者只有匯出耦合關係。也即，一個類要麼同另一個類毫無關係，要麼只使用另一個類的公有介面中的操作。

(8)類應該只表示一個關鍵抽象。

包中的所有類對於同一類性質的變化應該是共同封閉的。一個變化若對一個包影響，則將對包中的所有類產生影響，而對其他的包不造成任何影響 .

(9)把相關的資料和行為集中放置。

設計者應當留意那些通過get之類操作從別的對象中擷取資料的對象。這種類型的行為暗示著這條經驗原則被違反了。

(10)把不相關的資訊放在另一個類中(也即：互不溝通的行為)。

朝著穩定的方向進行依賴.

(11)確保你為之建模的抽象概念是類，而不只是對象扮演的角色。

(12)在水平方向上儘可能統一地分布系統功能，也即：按照設計，頂層類應當統一地共用工作。

(13)在你的系統中不要建立全能類/對象。對名字包含Driver、Manager、System、Susystem的類要特別多加小心。

規劃一個介面而不是實現一個介面。

(14)對公用介面中定義了大量存取方法的類多加小心。大量存取方法意味著相關資料和行為沒有集中存放。

(15)對包含太多互不溝通的行為的類多加小心。

這個問題的另一表現是在你的應用程式中的類的公有介面中建立了很多的get和set函數。

(16)在由同使用者介面互動的物件導向模型構成的應用程式中，模型不應該依賴於介面，介面則應當依賴於模型。

(17)儘可能地按照現實世界建模(我們常常為了遵守系統功能分布原則、避免全能類原則以及集中放置相關資料和行為的原則而違背這條原則) 。

(18)從你的設計中去除不需要的類。

一般來說，我們會把這個類降級成一個屬性。

(19)去除系統外的類。

系統外的類的特點是，抽象地看它們只往系統領域發送訊息但並不接受系統領域內其他類發出的訊息。

(20)不要把操作變成類。質疑任何名字是動詞或者派生自動詞的類，特別是只有一個有意義行為的類。考慮一下那個有意義的行為是否應當遷移到已經存在或者尚未發現的某個類中。

(21)我們在建立應用程式的分析模型時常常引入代理類。在設計階段，我們常會發現很多代理沒有用的，應當去除。

(22)盡量減少類的共同作業者的數量。

一個類用到的其他類的數目應當盡量少。

(23)盡量減少類和共同作業者之間傳遞的訊息的數量。

(24)盡量減少類和共同作業者之間的協作量，也即：減少類和共同作業者之間傳遞的不同訊息的數量。

(25)盡量減少類的扇出，也即：減少類定義的訊息數和發送的訊息數的乘積。

(26)如果類包含另一個類的對象，那麼包含類應當給被包含的對象發送訊息。也即：內含項目關聯性總是意味著使用關係。

(27)類中定義的大多數方法都應當在大多數時間裡使用大多數資料成員。

(28)類包含的對象數目不應當超過開發人員短期記憶的容量。這個數目常常是6。

當類包含多於6個資料成員時，可以把邏輯相關的資料成員劃分為一組，然後用一個新的包含類去包含這一群組成員。

1 2 下一頁

