【正文】 我們需要辦理一張銀行卡，如果銀行卡默認都擁有了存款、取款和透支的功能，那么我們辦理的卡都將具有這個功能，此時使用了繼承關系： 為了靈活地擁有各種功能，此時可以分別設立儲蓄卡和信用卡兩種，并有銀行卡來對它們進行聚合使用。如果一個子類需要大量的置換掉超類的行為，那么這個類就不應該是這個超類的子類。如果不能肯定將來是否會變成另外一個子類的話，就不要使用繼承。 1 子類是超類的一個特殊種類，而不是超類的一個角色，也就 是區(qū)分“ HasA”和“ IsA” .只有“ IsA”關系才符合繼承關系，“ HasA”關系應當使用聚合來描述。 合成復用原則是指盡量使用合成 /聚合，而不是使用繼承。一個合成關系中成分對象是不能與另外一個合成關系共享。組合則是一種更強的聚合，部分組成整體，而且不可分割，部分不能脫離整體而單獨存在。這些核心要素與設計原則，就是我們設計的對象法則，它們是理解和掌握設計模式的必備知識。例如，單一職責原則與接口隔離原則體現(xiàn)了封裝的思想，開放封閉原則體現(xiàn)了對象的封裝與多態(tài)，而 Liskov 替換原則是對對象繼承的規(guī)范，至 于依賴倒置原則，則是多態(tài)與抽象思想的體現(xiàn)。此外，一個龐大的接口不利于我們對其進行測試，因為在為該接口實現(xiàn) Mock 或 Fake對象 時，需要實現(xiàn)太多的方法。 圖 29 遵循接口隔離原則 倘若一個類實現(xiàn) 了所有的專門接口，從實現(xiàn)上看，它與實現(xiàn)一個總接口的方式并無區(qū)別；但站在調用者的角度，不同的接口代表了不同的關注點、不同的職責，甚至是不同的角色。這樣的設計保證了一定程度的重用性與可擴展性。 如果遵循接口隔離原則，將各自的集合操作功能分解為不同的接口，那么站在 ICollection 以及IEnumerable 的抽象層面上，可以認為 ArrayList 和 Hashtable 是相同的對象。正是因為一個總接口的引入，使得我們在可枚舉與集合層面上丟失了共同的抽象意義。這意味著兩者的接口存在差異。根據(jù)數(shù)據(jù)結構的特性，它將無法實現(xiàn) IGeneralList 接口。假如這個總接口名為 IGeneralList，它抹平了 IEnumerable接口、 ICollection 接口與 IList 接口之間的差別，包含了它們的所有方法。 19. void RemoveAt(int index)。 17. void Insert(int index, object value)。 15. bool Contains(object value)。 8. 9. // 其余成員略 10. } 11. public interface IList : ICollection, IEnumerable 12. { 13. int Add(object value)。 1. public interface IEnumerable 2. { 3. IEnumerator GetEnumerator()。 那么我們該如何解決這個問題呢？參考下圖的設計，為每個類都單獨設計專門的操作 接口，使得它們只依賴于它們關系的方法，這樣就不會互相影了！ 例二： 使用多個專門的接口還能夠體現(xiàn)對象的層次，因為我們可以通過接口的繼承，實現(xiàn)對總接口的定義。 例一： 參考下圖的設計，在這個設計里，取款、存款、轉帳都使用一個通用界面接口，也就是說，每一個類都被強迫依賴了另兩個類的接口方法，那么每個類有可能因為另外兩個類的方法 (跟自己無關 )而被影響。多個專門的接口就好比采用活字制版，可以隨時拼版拆版，既利于修改，又利于文字的重用。 6 接口 隔離原則 (ISP) 接口隔離原則 認為： 使用多個專門的接口比使用單一的總接口要好 。 封裝變化，是實現(xiàn)開放封閉原則的重要手段，對于經(jīng)常發(fā)生變化的狀態(tài)，一般將其封裝為一個抽象，例如銀行業(yè)務中 IBankProcess 接口。 設計建議： 開放封閉原則，是最為重要的設計原則， Liskov 替換原則和合成 /聚合復用原則為開放封閉原則提供保證。 } } 這樣當業(yè)務變更時，只需要修改對應的業(yè)務實現(xiàn)類就可以，其他不相干的業(yè)務就不必修改。 break。 break。 break。 } } public class BankStaff { private IBankProcess bankpro = null。 } } public class WithDrawProcess : IBankProcess { public void Process() { //辦理取款業(yè)務 (Process WithDraw)。 以下是符合 OCP 的設計： 首先聲明一個業(yè)務處理接口 public interface IBankProcess { void Process()。當有新的功能時，不需要再對現(xiàn)有業(yè)務進行重新梳理，然后再對系統(tǒng)做大的修改。 從開放封閉的角度來分析，在銀行系統(tǒng)中最可能擴展的就是業(yè)務功能的增加或變更。 } } } 這種設計顯然是存在問題的，目前設計中就只有存款，取款和轉賬三個功能，將來如果業(yè)務增加了，比如增加申購基金功能，理財功能等，就必須要修改 BankProcess 業(yè)務類。 //轉賬 case transfer: ()。 //取 款 case withdraw: ()。 public void BankHandle(Client client) { switch () { //存款 case deposite: ()。而封裝變化，是實現(xiàn)這一原則的重要手段， 將經(jīng)常變化的狀態(tài)封裝為一個類。 對于違反這一原則的類，必須通過重構來進行改善。 如何做到對擴展開放，對修改封閉呢？ 實現(xiàn)開放封閉的核心思想就是對抽象編程，而不對具體編程，因為抽象相對穩(wěn)定。 對修改封閉，意味著類一旦設計完成，就可以獨立其工作，而不要對類盡任何修改。軟件設計本身所追求的目標就是封裝變化，降低耦合，而開放封閉原