PHP面向對象分析設計的61條軍規

(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個數據成員時，能夠把邏輯相關的數據成員劃分爲一組，而後用一個新的包含類去包含這一組成員。 (29)讓系統功能在窄而深的繼承體系中垂直分佈。 (30)在實現語義約束時，最好根據類定義來實現。這經常會致使類氾濫成災，在這種狀況下，約束應當在類的行爲中實現，一般是在構造函數中實現，但不是必須如此。 (31)在類的構造函數中實現語義約束時，把約束測試放在構造函數領域所容許的儘可能深的包含層次中。 (32)約束所依賴的語義信息若是常常改變，那麼最好放在一個集中式的第3方對象中。 (33)約束所依賴的語義信息若是不多改變，那麼最好分佈在約束所涉及的各個類中。 (34)類必須知道它包含什麼，可是不能知道誰包含它。 (35)共享字面範圍(也就是被同一個類所包含)的對象相互之間不該當有使用關係。 (36)繼承只應被用來爲特化層次結構建模。 (37)派生類必須知道基類，基類不該該知道關於它們的派生類的任何信息。 (38)基類中的全部數據都應當是私有的，不要使用保護數據。類的設計者永遠都不該該把類的使用者不須要的東西放在公有接口中。 (39)在理論上，繼承層次體系應當深一點，越深越好。 (40)在實踐中，繼承層次體系的深度不該當超出一個普通人的短時間記憶能力。一個廣爲接受的深度值是6。 (41)全部的抽象類都應當是基類。 (42)全部的基類都應當是抽象類。 (43)把數據、行爲和/或接口的共性儘量地放到繼承層次體系的高端。 (44)若是兩個或更多個類共享公共數據(但沒有公共行爲)，那麼應當把公共數據放在一個類中，每一個共享這個數據的類都包含這個類。 (45)若是兩個或更多個類有共同的數據和行爲(就是方法)，那麼這些類的每個都應當從一個表示了這些數據和方法的公共基類繼承。 (46)若是兩個或更多個類共享公共接口(指的是消息，而不是方法)，那麼只有他們須要被多態地使用時，他們才應當從一個公共基類繼承。 (47)對對象類型的顯示的分狀況分析通常是錯誤的。在大多數這樣的狀況下，設計者應當使用多態。 (48)對屬性值的顯示的分狀況分析經常是錯誤的。類應當解耦合成一個繼承層次結構，每一個屬性值都被變換成一個派生類。 (49)不要經過繼承關係來爲類的動態語義建模。試圖用靜態語義關係來爲動態語義建模會致使在運行時切換類型。 (50)不要把類的對象變成派生類。對任何只有一個實例的派生類都要多加當心。 (51)若是你以爲須要在運行時刻建立新的類，那麼退後一步以認清你要建立的是對象。如今，把這些對象歸納成一個類。 (52)在派生類中用空方法(也就是什麼也不作的方法)來覆寫基類中的方法應當是非法的。 (53)不要把可選包含同對繼承的須要相混淆。把可選包含建模成繼承會帶來氾濫成災的類。 (54)在建立繼承層次時，試着建立可複用的框架，而不是可複用的組件。 (55)若是你在設計中使用了多重繼承，先假設你犯了錯誤。若是沒犯錯誤，你須要設法證實。 (56)只要在面向對象設計中用到了繼承，問本身兩個問題：(1)派生類是不是它繼承的那個東西的一個特殊類型？(2)基類是否是派生類的一部分？ (57)若是你在一個面向對象設計中發現了多重繼承關係，確保沒有哪一個基類其實是另外一個基類的派生類。 (58)在面向對象設計中若是你須要在包含關係和關聯關係間做出選擇，請選擇包含關係。 (59)不要把全局數據或全局函數用於類的對象的薄記工做。應當使用類變量或類方法。 (60)面向對象設計者不該當讓物理設計準則來破壞他們的邏輯設計。可是，在對邏輯設計做出決策的過程當中咱們常常用到物理設計準則。 (61)不要繞開公共接口去修改對象的狀態。