【導讀】使得開發(fā)的系統(tǒng)可擴展性，可維護性，可理解性更好，性能、可靠性更高。使開發(fā)更加快捷，輕松，方便、高效。為系統(tǒng)架構、軟件框架的實現(xiàn)提供指導。公司項目管理人員、質量管理人員，系統(tǒng)設計人員、程序開發(fā)人員。實施維護人員、測試人員。總體的設計和長遠的考慮，導致項目對以后的項目沒有重用性，每一個項目總是基本上從零開始，嚴重影響軟件的質量和制約軟件企業(yè)的發(fā)展。適用于企業(yè)所有基于J2EE或.Net平臺的B/S多層分布式系統(tǒng)。系統(tǒng)的開發(fā)與部署，進而提高可移植性、安全與再用價值。J2EE核心是一組技術規(guī)范與指南，致企業(yè)內部或外部難以互通的窘境。B/S結構即Browser/Server瀏覽器/服務器模式是WEB興起后的一種網絡結構模式，WEB瀏。B/S最大的優(yōu)點就是可以在任何地方進。此外框架設計中遵循“開閉原則”，即關閉修改，開放擴。斷完善，不斷發(fā)展?？蚣車栏癫捎梅謱铀枷耄俗裱萌R塢原則和開閉原則外，在在層內部

　　

【正文】 級 結 點新 增 下 級 結 點刪 除 當 前 結 點部 門 維 護 界 面部 門 維 護 界 面部 門 編 碼 : 部 門 名 稱 :上 級 編 碼 : 上 級 名 稱 :保 存 刪 除 關 閉B M 0 7 0 2成 本 科清 空 重 置負 責 人 :王 法 林B M 0 7財 務 科. . .備 注 :于 9 8 年 成 立結 點 信 息 第 46 頁 20201213 部 門 及 人 員 管 理 人 員 維 護部 門 及 人 員 管 理 人 員 維 護所 有 部 門管 理 部運 營 部財 務 部住 院 部后 勤 部資 產 明 細部 門 編 碼 : 部 門 名 稱 :負 責 人 : 654321序 號 Z G 0 8 7 6 5Z G 0 0 7 6 4Z G 0 8 7 6 7Z G 8 7 6 5 6Z G 0 0 8 7 6Z G 0 0 7 8 9 人 員 編 碼注 冊 會 計 師高 級 會 計 師中 級 會 計 師會 計 人 員財 務出 納職 務查 詢 五 寧張 淳 皓張 鐵 林王 成 林張 寧王 平姓 名 女男男男女男姓 別結 點 信 息新 增 同 級 結 點新 增 下 級 結 點刪 除 當 前 結 點相 關 結 點 部 門 人 員新 增 刪 除 ? 附注說明： ? 結點刪除時將連同結點下的所有子結點一并被刪除。 ? 該框架同時持是否允許刪除有子結點的結點，通過對樹的配置進行來決定。 在展示其明細數據時同時也支持是否對列表信息維護的支持，通過用用 戶配置來決定是否折疊（折壘起來的列表結點信息的維護界面用戶仍可通過展開按鈕進行展開）。 6 附錄 面向對象設計原則 類設計原則 ? SRP 單一職責原則 ： 一個類應該有且只有一個改變的理由。 ? OCP 原則 即 開封閉原則 一個模塊在擴展性方面應該 是開放的而在更改性方面應該是封閉的 ，開閉原則換句話就是說系統(tǒng)發(fā)生變化時應對修改關閉，才擴展開放。 在進行面向對象設計時要盡量考慮接口封裝機制、抽象機制和多態(tài)技術。該原則同樣適合于非面向對象設計的方法，是軟件工程設計方法的 第 47 頁 20201213 重要原則之一。 其它幾種原則如 ：里氏替換原則，依賴倒置原則，合成聚合原則，迪米特原則，接口隔離原則，都是對開閉原則的補充 和保證 。 ? LSP 原則： 派生類要與其基類自相容。 凡父類可以出現(xiàn)的地方子類均 可以出現(xiàn)，該 原則是 Liskov于 1987 年提出的設計原則。它同樣可以從 Bertrand Meyer 的 DBC (Design by Contract) 的概念推出。 里氏替換原則：反過來則不成立，即凡子類出現(xiàn)的地方，父類不一定可以出現(xiàn)。 如抽象工廠模式，工廠方法等設計模式均采用該里氏原則 。 ? DIP： 依賴倒置原則 該原則是指 依賴于抽象而不是實現(xiàn)。 在進行業(yè)務設計時，與特定業(yè)務有關的依賴關系應該盡量依賴接口和抽象類，而不是依賴于具體類。具體類只負責相關業(yè)務的實現(xiàn)，修改具體類不 影響與特定業(yè)務有關的依賴關系。為此，我們在進行業(yè)務設計時，應盡量在接口或抽象類中定義業(yè)務方法的原型，并通過具體的實現(xiàn)類 (子類 )來實現(xiàn)該業(yè)務方法，業(yè)務方法內容的修改將不會影響到運行時業(yè)務方法的調用。 該原則與 面向接口編程思想是一致的。 ? 合成聚合原則 盡量 使用 引用關系，而不要且繼承，引用關系可以看作是一種特殊的繼承。在軟件工程中高內聚，低藕合，引用關系藕合程度就低。 同時也遵循了面向對象封裝原則。 ? 迪米特原則 最少知識原則，也可以理解為不要與陌生人講話。它指出系統(tǒng)內部之間盡可以少地通信，廣義的迪米特原則即指通信的廣 度，同時也指通信的深度，廣度如門面模式，如中介者（又叫調停者模式）， 門面模式。 ? ISP:接口隔離原則 ，客戶只要關注它們所需的接口。 接口盡可能少地單一性，如 IDispose,IClone 接口， 還有 迭代器，將接口開放給用戶，這是主要是指限制通信的廣度。 包設計原則 ? REP， 重用發(fā)布等價原則 ，重用的粒度就是發(fā)布的粒度。 ? CCP， 共同封閉原則 ，包中的所有類對于同一類性質的變化應該是共同封閉的。 ? CRP， 共 同重用原則 ，一個包中的所有類應該是共同重用的。 第 48 頁 20201213 包之間關系設計原則 ? ADP， 無環(huán)依賴原則 ，在包的依賴關系圖中不允許存在環(huán)。 ? SDP， 穩(wěn)定依賴原則 ，朝著穩(wěn)定的方向進行依賴。 ? SAP， 穩(wěn)定抽象原則 ，包的抽象程度應該和其穩(wěn)定程度一致。 面向對象 經驗 原則 “ 你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那么警鈴就會響起。 ” Arthur 1) 所有數據都應該隱藏在所在的類的內部。 2) 類的使用者必須依賴類的共有接口，但類不能依賴它的使用者。 3) 盡量減少類的協(xié)議中的消息。 4) 實現(xiàn)所有類都理解的最基本公有接口 [例如，拷貝操作 (深拷貝和淺拷貝 )、相等性判斷、正確輸出內容、從 ASCII描述解析等等 ]。 5) 不要把實現(xiàn)細節(jié) (例如放置共用代碼的私有函數 )放到類的公有接口中。如果類的兩個方法有一段公共代碼，那么就可以創(chuàng)建一個防止這些公共代碼的私有函數。 6) 不要以用戶無法使用或不感興趣的東西擾亂類的公有接口。 7) 類之間應該零耦合，或者只有導出耦合關系。也即，一個類要么同另一個類毫無關系，要么只使用另一個類的公有接口中的操作。 8) 類應該只表示一個關鍵抽象。 包中的所有類對于同一類性質的變化應該是共同 封閉的。一個變化若對一個包影響，則將對包中的所有類產生影響，而對其他的包不造成任何影響 . 9) 把相關的數據和行為集中放置。 設計者應當留意那些通過 get之類操作從別的對象中獲取數據的對象。這種類型的行為暗示著這條經驗原則被違反了。 10) 把不相關的信息放在另一個類中 (也即：互不溝通的行為 )。 朝著穩(wěn)定的方向進行依賴 . 11) 確保你為之建模的抽象概念是類，而不只是對象扮演的角色。 12) 在水平方向上盡可能統(tǒng)一地分布系統(tǒng)功能，也即：按照設計，頂層類應當統(tǒng)一地共享工作。 第 49 頁 20201213 13) 在你的系統(tǒng)中不要創(chuàng)建全能類 /對象。對名字包含 Driver、 Manager、 System、 Susystem的類要特別多加小心。 規(guī)劃一個接口而不是實現(xiàn)一個接口。 14) 對公共接口中定義了大量訪問方法的類多加小心。大量訪問方法意味著相關數據和行為沒有集中存放。 15) 對包含太多互不溝通的行為的類多加小心。 這個問題的另一表現(xiàn)是在你的應用程序中的類的公有接口中創(chuàng)建了很多的 get和 set函數。 16) 在由同用戶界面交互的面向對象模型構成的應用程序中，模型不應該依賴于界面，界面則應當依賴于模型。 17) 盡可能地按照現(xiàn)實世界建模 (我們常常為了遵守系統(tǒng)功能分布原則、避免全能類原則以及集中放置相關 數據和行為的原則而違背這條原則 ) 。 18) 從你的設計中去除不需要的類。 一般來說，我們會把這個類降級成一個屬性。 19) 去除系統(tǒng)外的類。 系統(tǒng)外的類的特點是，抽象地看它們只往系統(tǒng)領域發(fā)送消息但并不接受系統(tǒng)領域內其他類發(fā)出的消息。 20) 不要把操作變成類。質疑任何名字是動詞或者派生自動詞的類，特別是只有一個有意義行為的類?？紤]一下那個有意義的行為是否應當遷移到已經存在或者尚未發(fā)現(xiàn)的某個類中。 21) 我們在創(chuàng)建應用程序的分析模型時常常引入代理類。在設計階段，我們常會發(fā)現(xiàn)很多代理沒有用的，應當去除。 22) 盡量減少類的協(xié)作者的數量。 一 個類用到的其他類的數目應當盡量少。 23) 盡量減少類和協(xié)作者之間傳遞的消息的數量。 24) 盡量減少類和協(xié)作者之間的協(xié)作量，也即：減少類和協(xié)作者之間傳遞的不同消息的數量。 25) 盡量減少類的扇出，也即：減少類定義的消息數和發(fā)送的消息數的乘積。 26) 如果類包含另一個類的對象，那么包含類應當給被包含的對象發(fā)送消息。也即：包含關系總是意味著使用關系。 27) 類中定義的大多數方法都應當在大多數時間里使用大多數數據成員。 第 50 頁 20201213 28) 類包含的對象數目不應當超過開發(fā)者短期記憶的容量。這個數目常常是 6。 當類包含多于 6個數據成員時，可以把邏輯相關的數據成員劃分 為一組，然后用一個新的包含類去包含這一組成員。 29) 讓系統(tǒng)功能在窄而深的繼承體系中垂直分布。 30) 在實現(xiàn)語義約束時，最好根據類定義來實現(xiàn)。這常常會導致類泛濫成災，在這種情況下，約束應當在類的行為中實現(xiàn)，通常是在構造函數中實現(xiàn)，但不是必須如此。 31) 在類的構造函數中實現(xiàn)語義約束時，把約束測試放在構造函數領域所允許的盡量深的包含層次中。 32) 約束所依賴的語義信息如果經常改變，那么最好放在一個集中式的第 3方對象中。 33) 約束所依賴的語義信息如果很少改變，那么最好分布在約束所涉及的各個類中。 34) 類必須知道它包含什么，但是不能知道誰包含 它。 35) 共享字面范圍 (也就是被同一個類所包含 )的對象相互之間不應當有使用關系。 36) 繼承只應被用來為特化層次結構建模。 37) 派生類必須知道基類，基類不應該知道關于它們的派生類的任何信息。 38) 基類中的所有數據都應當是私有的，不要使用保護數據。 類的設計者永遠都不應該把類的使用者不需要的東西放在公有接口中。 39) 在理論上，繼承層次體系應當深一點，越深越好。 40) 在實踐中，繼承層次體系的深度不應當超出一個普通人的短期記憶能力。一個廣為接受的深度值是 6。 41) 所有的抽象類都應當是基類。 42) 所有的基類都應當是抽象類。 43) 把數據、行為和 /或接口 的共性盡可能地放到繼承層次體系的高端。 44) 如果兩個或更多個類共享公共數據 (但沒有公共行為 )，那么應當把公共數據放在一個類中，每個共享這個數據的類都包含這個類。 45) 如果兩個或更多個類有共同的數據和行為 (就是方法 )，那么這些類的每一個都應當從一個表示了這些數據和方法的公共基類繼承。 46) 如果兩個或更多個類共享公共接口 (指的是消息，而不是方法 )，那么只有他們需要被多態(tài)地使用時，他們才應當從一個公共基類繼承。 47) 對對象類型的顯示的分情況分析一般是錯誤的。在大多數這樣的情況下，設計者應當使用多態(tài)。 第 51 頁 20201213 48) 對屬性值的顯示的分情況分析常 常是錯誤的。類應當解耦合成一個繼承層次結構，每個屬性值都被變換成一個派生類。 49) 不要通過繼承關系來為類的動態(tài)語義建模。試圖用靜態(tài)語義關系來為動態(tài)語義建模會導致在運行時切換類型。 50) 不要把類的對象變成派生類。對任何只有一個實例的派生類都要多加小心。 51) 如果你覺得需要在運行時刻創(chuàng)建新的類，那么退后一步以認清你要創(chuàng)建的是對象?，F(xiàn)在，把這些對象概括成一個類。 52) 在派生類中用空方法 (也就是什么也不做的方法 )來覆寫基類中的方法應當是非法的。 53) 不要把可選包含同對繼承的需要相混淆。把可選包含建模成繼承會帶來泛濫成災的類。 54) 在創(chuàng)建繼 承層次時，試著創(chuàng)建可復用的框架，而不是可復用的組件。 55) 如果你在設計中使用了多重繼承，先假設你犯了錯誤。如果沒犯錯誤，你需要設法證明。 56) 只要在面向對象設計中用到了繼承，問自己兩個問題： (1)派生類是否是它繼承的那個東西的一個特殊類型？ (2)基類是不是派生類的一部分？ 57) 如果你在一個面向對象設計中發(fā)現(xiàn)多重繼承關系，確保沒有哪個基類實際上是另一個基類的派生類。 58) 在面向對象設計中如果你需要在包含關系和關聯(lián)關系間作出選擇，請選擇包含關系。 59) 不要把全局數據或全局函數用于類的對象的薄記工作。應當使用類變量或類方法。 60) 面向 對象設計者不應當讓物理設計準則來破壞他們的邏輯設計。但是，在對邏輯設計作出決策的過程中我們經常用到物理設計準則。 61) 不要繞開公共接口去修改對象的狀態(tài)。