1. 程式人生 > >C#設計模式原則

C#設計模式原則

原則的誕生:
面向物件:封裝、繼承、多型三大支柱蘊含了用抽象來封裝變化,降低耦合,實現複用的精髓;
封裝:隱藏內部的實現,保護內部資訊;
繼承:實現複用,歸納共性;
多型:改寫物件行為,實現更高級別的繼承
要實現這些目的,就必須遵守一些原則:封裝變化、對介面程式設計、少繼承多聚合
實現系統的可擴充套件、可複用、靈活性好、維護性好
一、開-閉原則(ocp)
1.核心思想:軟體應該是可擴充套件的,而不可修改的
2.對擴充套件開發:有新的需求或變化時,可以對現有程式碼進行擴充套件,以適應新情況
3.對修改關閉:類一旦設計完成,就可以單獨完成自己的工作,而不要再對類進行任何修改。
4.實現方式:抽象,多型,繼承,介面
二、單一職責原則(srp)


1.目的:如果你有多個原因去改變一個類,那麼應該把這些引起變化的原因分離開,把這個類分成多個類,每個類只負責處理一種改變。當你做出某種改變時,只需要修改負責處理該改變的類
2.單一職責原則
.一個類應該只受一種變化的影響
.如果一個類承擔的職責過多,就等於把這些職責耦合在一起,一個職責的變化可能會削弱或者抑制這些個類完成其他職責的能力。這種耦合會導致脆弱的設計,當變化發生時,設計會遭到意想不到的破壞。
.優點:消除耦合,減小因需求變化引起程式碼僵化性臭味
.使用srp注意點:
(1).一個合理的類,應該僅有一個引起它變化的原因,即單一職責;
(2).在沒有變化徵兆的情況下應用srp或其他原則是不明智的;
(3).在需求實際發生變化時就應該應用srp等原則來重構程式碼;
(4).使用測試驅動開發會迫使我們在設計出現臭味之前分離不合理程式碼;
(5).如果測試不能迫使職責分離,僵化性和脆弱性的臭味會變得很強烈,那就應該用facade或proxy模式對程式碼重構
三、介面隔離原則(ISP)

1.目的:當我們設計應用程式的時候,如果一個模組包含多個子模組,那麼我們應該小心對該模組做出抽象。
2.介面隔離原則:表明客戶端不應該被強迫實現一些他們不會使用的介面,應該把胖介面中的方法分組,然後用多個介面代替它,每個介面服務於一個子模組。
四、里氏代換原則(LSP)
1.核心思想:子類必須能夠替換基類
2.在一個軟體系統中,子類應該可以替換任何基類能夠出現的地方,並且經過替換以後,程式碼還能正常工作
3.目的:當我們設計程式模組時,我們會建立一些類層次結構,然後我們通過擴充套件一些類來建立他們的子類,我們必須確保基類的引用可以被子類替換而不影響模組的功能,否則當我們在已有程式模組中使用他們時將會產生不可預料的結果
示例:

 public class Father
    {
        public string type;
        public Father()
        {
            type = "father";
        }
        /// <summary>
        /// 建立虛方法
        /// </summary>
        public virtual void Method()
        { }
        
    }
    public class Son:Father
    {
        public Son()
        {
            type = "son";
        }
        /// <summary>
        /// 重寫父類虛方法
        /// </summary>
        public override void Method()
        {
           
        }
        public static void DoSomeThing(Father f)
        {
            f.Method();
        }
    }    

注:如果Method()被實現為虛方法,並且在子類中可以被重寫,則傳入DoSomeThing的引數既可以是父類型別也可以是子類型別,子類完全可以代替父類在此呼叫自己的方法
總結:Liskov替換原則是關於繼承機制的設計原則,違反了Liskov替換原則必然導致違反開閉原則;Liskov替換原則能夠保證系統具有良好的擴充套件性,同時實現基於多型的抽象機制,能夠減少程式碼冗餘,避免執行期間的型別判斷。子類必須滿足基類和客戶端對其行為的約定,客戶端對行為的期望在子類和基類中必須保持一致。
五、依賴倒轉原則(DIP)
(1)、目的:在一個應用程式中,我們有一些實現了基礎的,主要的操作的底層類和一些封裝了複雜邏輯的上層類。實現這種結構的很自然的方式就是,先編寫底層類,完成後再編寫複雜的上層類。因為上層類是由其他東西定義的,所以這看起來是一種很合理的方式。但是這不是一個靈活的設計,如果我們需要替換一個底層類時會發生什麼?
(2)、依賴:所謂依賴,舉例:一個類Person,另一個類Car,如果Person的某個方法比如說drive,需要引用Car,則稱Person類依賴於Car類
六、組合優先於繼承
(1)繼承:它可以使用現有類的所有功能,並在無需重新編寫原來的類的情況下對這些功能進行擴充套件
(2)組合:通過建立一個由其他物件組合的物件來獲得新功能的重用方法,新功能的獲得是通過呼叫組合物件的功能實現的,有時又叫聚合
(3)繼承與組合:繼承與子類之間是“ls-a”的關係;組合與其它類之間是“Has-a”的關係