面向?qū)ο缶幊讨蓄愒O計的幾個原則
1. 開閉原則(the Open Closed Principle OCP)
一個模塊在擴展性方面應該是開放的而在更改性方面應該是封閉的。因此在進行面向?qū)ο笤O計時要盡量考慮接口封裝機制、抽象機制和多態(tài)技術。該原則同樣適合于非面向?qū)ο笤O計的方法，是軟件工程設計方法的重要原則之一。我們以收音機的例子為例，講述面向?qū)ο蟮拈_閉原則。我們收聽節(jié)目時需要打開收音機電源，對準電臺頻率和進行音量調(diào)節(jié)。但是對于不同的收音機，實現(xiàn)這三個步驟的細節(jié)往往有所不同。比如自動收縮電臺的收音機和按鈕式收縮在操作細節(jié)上并不相同。因此，我們不太可能針對每種不同類型的收音機通過一個收音機類來實現(xiàn)(通過重載)這些不同的操作方式。但是我們可以定義一個收音機接口，提供開機、關機、增加頻率、降低頻率、增加音量、降低音量六個抽象方法。不同的收音機繼承并實現(xiàn)這六個抽象方法。這樣新增收音機類型不會影響其它原有的收音機類型，收音機類型擴展極為方便。此外，已存在的收音機類型在修改其操作方法時也不會影響到其它類型的收音機。
2. 替換原則 (the Liskov Substitution Principle LSP)
子類應當可以替換父類并出現(xiàn)在父類能夠出現(xiàn)的任何地方。這個原則是Liskov于1987年提出的設計原則。它同樣可以從Bertrand Meyer 的DBC (Design by Contract) 的概念推出。
我們以學生為例，夜校生為學生的子類，因此在任何學生可以出現(xiàn)的地方，夜校生均可出現(xiàn)。這個例子有些牽強，一個能夠反映這個原則的例子時圓和橢圓，圓是橢圓的一個特殊子類。因此任何出現(xiàn)橢圓的地方，圓均可以出現(xiàn)。但反過來就可能行不通。
運用替換原則時，我們盡量把類B設計為抽象類或者接口，讓C類繼承類B(接口B)并實現(xiàn)操作A和操作B，運行時，類C實例替換B，這樣我們即可進行新類的擴展(繼承類B或接口B)，同時無須對類A進行修改。
3. 依賴原則 (the Dependency Inversion Principle DIP)
在進行業(yè)務設計時，與特定業(yè)務有關的依賴關系應該盡量依賴接口和抽象類，而不是依賴于具體類。具體類只負責相關業(yè)務的實現(xiàn)，修改具體類不影響與特定業(yè)務有關的依賴關系。
在結構化設計中，我們可以看到底層的模塊是對高層抽象模塊的實現(xiàn)(高層抽象模塊通過調(diào)用底層模塊)，這說明，抽象的模塊要依賴具體實現(xiàn)相關的模塊，底層模塊的具體實現(xiàn)發(fā)生變動時將會嚴重影響高層抽象的模塊，顯然這是結構化方法的一個"硬傷"。
面向?qū)ο蠓椒ǖ囊蕾囮P系剛好相反，具體實現(xiàn)類依賴于抽象類和接口。
為此，我們在進行業(yè)務設計時，應盡量在接口或抽象類中定義業(yè)務方法的原型，并通過具體的實現(xiàn)類(子類)來實現(xiàn)該業(yè)務方法，業(yè)務方法內(nèi)容的修改將不會影響到運行時業(yè)務方法的調(diào)用。
4. 接口分離原則(the Interface Segregation Principle ISP)
采用多個與特定客戶類有關的接口比采用一個通用的涵蓋多個業(yè)務方法的接口要好。
ISP原則是另外一個支持諸如COM等組件化的使能技術。缺少ISP，組件、類的可用性和移植性將大打折扣。
這個原則的本質(zhì)相當簡單。如果你擁有一個針對多個客戶的類，為每一個客戶創(chuàng)建特定業(yè)務接口，然后使該客戶類繼承多個特定業(yè)務接口將比直接加載客戶所需所有方法有效。
以上四個原則是面向?qū)ο笾谐３Ｓ玫降脑瓌t。此外，除上述四原則外，還有一些常用的經(jīng)驗諸如類結構層次以三到四層為宜、類的職責明確化(一個類對應一個具體職責)等可供我們在進行面向?qū)ο笤O計參考。但就上面的幾個原則看來，我們看到這些類在幾何分布上呈現(xiàn)樹型拓撲的關系，這是一種良好、開放式的線性關系、具有較低的設計復雜度。一般說來，在軟件設計中我們應當盡量避免出現(xiàn)帶有閉包、循環(huán)的設計關系，它們反映的是較大的耦合度和設計復雜化。
【編輯推薦】
