面向?qū)ο笤O(shè)計六大原則-資料下載頁
2025-05-07 21:44本頁面
【正文】 印刷，顯得笨重，實現(xiàn)殊為不易；一旦發(fā)現(xiàn)錯字別字，就很難修改，往往需要整塊雕版重新雕刻。 例一： 參考下圖的設(shè)計，在這個設(shè)計里，取款、存款、轉(zhuǎn)帳都使用一個通用界面接口，也就是說，每一個類都被強迫依賴了另兩個類的接口方法，那么每個類有可能因為另外兩個類的方法 (跟自己無關(guān) )而被影響。拿取款來說，它根本不關(guān)心“存款操作”和“轉(zhuǎn)帳操作”，可是它卻要受到這兩個方法的變化的影響。 那么我們該如何解決這個問題呢？參考下圖的設(shè)計，為每個類都單獨設(shè)計專門的操作 接口，使得它們只依賴于它們關(guān)系的方法，這樣就不會互相影了！ 例二： 使用多個專門的接口還能夠體現(xiàn)對象的層次，因為我們可以通過接口的繼承，實現(xiàn)對總接口的定義。例如， .NET 框架中 IList接口的定義。 1. public interface IEnumerable 2. { 3. IEnumerator GetEnumerator()。 4. } 5. public interface ICollection : IEnumerable 6. { 7. void CopyTo(Array array, int index)。 8. 9. // 其余成員略 10. } 11. public interface IList : ICollection, IEnumerable 12. { 13. int Add(object value)。 14. void Clear()。 15. bool Contains(object value)。 16. int IndexOf(object value)。 17. void Insert(int index, object value)。 18. void Remove(object value)。 19. void RemoveAt(int index)。 20. 21. // 其余成員略 22. } 如果不采用這樣的接口繼承方式，而是定義一個總的接口包含上述成員，就無法實現(xiàn) IEnumerable 接口、ICollection接口與 IList接口成員之間的隔離。假如這個總接口名為 IGeneralList，它抹平了 IEnumerable接口、 ICollection 接口與 IList 接口之間的差別，包含了它們的所有方法。現(xiàn)在，如果我們需要定義一個 Hashtable 類。根據(jù)數(shù)據(jù)結(jié)構(gòu)的特性，它將無法實現(xiàn) IGeneralList 接口。因為 Hashtable 包含的 Add()方法，需要提供鍵與值，而之前針對 ArrayList 的 Add()方法，則只需要值即可。這意味著兩者的接口存在差異。我們需要專門為 Hashtable 定義一個接口，例如 IDictionary，但它卻與 IGeneralList 接口不存在任何關(guān)系。正是因為一個總接口的引入，使得我們在可枚舉與集合層面上丟失了共同的抽象意義。雖然Hashtable 與 ArrayList 都是可枚舉的，也都具備集合特征，它 們卻不可互換。 如果遵循接口隔離原則，將各自的集合操作功能分解為不同的接口，那么站在 ICollection 以及IEnumerable 的抽象層面上，可以認(rèn)為 ArrayList 和 Hashtable 是相同的對象。在這一抽象層面上，二者是可替換的，如圖 29所示。這樣的設(shè)計保證了一定程度的重用性與可擴展性。從某種程度來講，接口隔離原則可以看做是接口層的單一職責(zé)原則。 圖 29 遵循接口隔離原則 倘若一個類實現(xiàn) 了所有的專門接口，從實現(xiàn)上看，它與實現(xiàn)一個總接口的方式并無區(qū)別；但站在調(diào)用者的角度，不同的接口代表了不同的關(guān)注點、不同的職責(zé)，甚至是不同的角色。因此，面對需求不同的調(diào)用者，這樣的類就可以提供一個對應(yīng)的細(xì)粒度接口去匹配。此外，一個龐大的接口不利于我們對其進(jìn)行測試，因為在為該接口實現(xiàn) Mock 或 Fake對象 時，需要實現(xiàn)太多的方法。 概括地講，面向?qū)ο笤O(shè)計原則仍然是面向?qū)ο笏枷氲捏w現(xiàn)。例如，單一職責(zé)原則與接口隔離原則體現(xiàn)了封裝的思想，開放封閉原則體現(xiàn)了對象的封裝與多態(tài)，而 Liskov 替換原則是對對象繼承的規(guī)范，至 于依賴倒置原則，則是多態(tài)與抽象思想的體現(xiàn)。在充分理解面向?qū)ο笏枷氲幕A(chǔ)上，掌握基本的設(shè)計原則，并能夠在項目設(shè)計中靈活運用這些原則，就能夠改善我們的設(shè)計，尤其能夠保證可重用性、可維護(hù)性與可擴展性等系統(tǒng)的質(zhì)量屬性。這些核心要素與設(shè)計原則，就是我們設(shè)計的對象法則，它們是理解和掌握設(shè)計模式的必備知識。 7 組合 /聚集復(fù)用原則 組合 /聚合復(fù)用原則（ Composite/Aggregate Reuse Principle CARP） .組合和聚合都是對象建模中關(guān)聯(lián)（ Association）關(guān)系的一種 .聚合表示整體與部分的關(guān) 系，表示“含有”，整體由部分組合而成，部分可以脫離整體作為一個獨立的個體存在。組合則是一種更強的聚合，部分組成整體，而且不可分割，部分不能脫離整體而單獨存在。在合成關(guān)系中，部分和整體的生命周期一樣，組合的新的對象完全支配其組成部分，包括他們的創(chuàng)建和銷毀。一個合成關(guān)系中成分對象是不能與另外一個合成關(guān)系共享。 組合 /聚合和繼承是實現(xiàn)復(fù)用的兩個基本途徑。 合成復(fù)用原則是指盡量使用合成 /聚合，而不是使用繼承。 只有當(dāng)以下的條件全部被滿足時，才應(yīng)當(dāng)使用繼承關(guān)系。 1 子類是超類的一個特殊種類，而不是超類的一個角色，也就 是區(qū)分“ HasA”和“ IsA” .只有“ IsA”關(guān)系才符合繼承關(guān)系，“ HasA”關(guān)系應(yīng)當(dāng)使用聚合來描述。 2 永遠(yuǎn)不會出現(xiàn)需要將子類換成另外一個類的子類的情況。如果不能肯定將來是否會變成另外一個子類的話，就不要使用繼承。 3 子類具有擴展超類的責(zé)任，而不是具有置換掉或注銷掉超類的責(zé)任。如果一個子類需要大量的置換掉超類的行為，那么這個類就不應(yīng)該是這個超類的子類。 錯誤的使用繼承而不是合成 /聚合的一個常見原因是錯誤地把“ HasA”當(dāng)成了“ IsA” .”IsA”代表一個類是另外一個類的一種；而“ HasA”代表一個類是另外一個類的一個角色，而不是另外一個類的特殊種類。 我們需要辦理一張銀行卡，如果銀行卡默認(rèn)都擁有了存款、取款和透支的功能，那么我們辦理的卡都將具有這個功能，此時使用了繼承關(guān)系： 為了靈活地?fù)碛懈鞣N功能，此時可以分別設(shè)立儲蓄卡和信用卡兩種，并有銀行卡來對它們進(jìn)行聚合使用。此時采用了合成復(fù)用原則 銀行卡 + 取款 ()+ 存款 ()+ 透支 ()你的銀行卡+ 取款 ()+ 存款 ()+ 透支 ()我的銀行卡+ 取款 ()+ 存款 ()+ 透支 () 儲蓄卡 + 取款 ()+ 存款 ()信用卡+ 透支 ()銀行卡我的銀行卡+ 取款 ()+ 存款 ()+ 透支 ()
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號-1