設計模式六大原則-有解無憂

設計模式六大原則：

　　1、單一職責原則（Single Responsibility Principle）

　　2、里式替換原則（Liskov Substitution Principle）

　　3、依賴倒置原則（Dependence Inversion Principle）

　　4、介面隔離原則（Interface Segregation Principle）

　　5、迪米特法則（Law Of Demeter）//最少知道原則

　　6、開閉原則（Open Closed Principle）

設計模式：

　　面向物件語言開發程序中，遇到種種的場景和問題，提出的解決方案和思路，沉淀下來，設計模式是解決具體問題的套路

設計模式六大原則：

　　面向物件語言開發程序中，推薦的一些指導性原則；沒有明確的招數，而且也會經常被忽視/違背；也是前輩總結，也是為了站在前輩的肩膀上，

　　實際上真實專案很難全部遵循，更多的時候會有一些側重性，設計模式六大原則要能靈活運用，離不開時間的錘煉和思考，把這個真的融入到骨子里，設計確實會不一樣，

1、單一職責（Single Responsibility Principle）

　　類T負責兩個不同的職責，職責P1和職責P2，由于職責P1需求發生改變需要修改T時，有可能會導致原本運行正常職責P2功能發生故障，

　　一個類只負責一件事，面向物件語言開發，類是一個基本單位，單一職責原則就是封裝的粒度，

下面我們來看一個動物類：

public class Animal
{
    private string _Name = null;
    public Animal(string name)
    {
        this._Name = name;
    }
    /// <summary>
    /// 這個方法就挺不穩定，經常各種分支變化經常修改
    /// </summary>
    public void Breath()
    {
        if (this._Name.Equals("雞"))
            Console.WriteLine($"{this._Name} 呼吸空氣");
        else if (this._Name.Equals("牛"))
            Console.WriteLine($"{this._Name} 呼吸空氣");
        else if (this._Name.Equals("魚"))
            Console.WriteLine($"{this._Name} 呼吸水");
        else if (this._Name.Equals("蚯蚓"))
            Console.WriteLine($"{this._Name} 呼吸泥土");
    }
    //BreathChicken  BreathFish

    //應該拆分了
    public void Action()
    {
        if (this._Name.Equals("雞"))
            Console.WriteLine($"{this._Name} flying");
        else if (this._Name.Equals("牛"))
            Console.WriteLine($"{this._Name} walking");
        else if (this._Name.Equals("魚"))
            Console.WriteLine($"{this._Name} Swimming");
        else if (this._Name.Equals("蚯蚓"))
            Console.WriteLine($"{this._Name} Crawling");
    }
}

這樣在不同動物過來時，只要在Animal的建構式中傳遞動物的名字即可：

{
    Animal animal = new Animal("雞");//呼吸空氣
    animal.Breath();
    animal.Action();
}
{
    Animal animal = new Animal("牛");//呼吸空氣
    animal.Breath();
    animal.Action();
}
{
    Animal animal = new Animal("魚");//呼吸水
    animal.Breath();
    animal.Action();
}

　　但是這樣不好，寫了分支判斷，然后執行不同的邏輯，其實這就違背了單一職責，但是功能是可以實作的，

　　需要拆分，拆分父類+子類，每個類很簡單，意味著穩定，意味著強大，現在的東西沒有以前警用，因為功能多了，這不壞就那壞了，

下面抽象出一個父類：

public abstract class AbstractAnimal
{
    protected string _Name = null;
    public AbstractAnimal(string name)
    {
        this._Name = name;
    }

    public abstract void Breath();
    public abstract void Action();
}

現在，有一種動物，只要繼承這個父類，重寫抽象類中的方法即可：

public class Chicken : AbstractAnimal
{
    public Chicken(string name) : base(name)
    {
    }

    public Chicken() : base("雞")
    {
    }

    public override void Breath()
    {
        Console.WriteLine($"{base._Name} 呼吸空氣");
    }
    public override void Action()
    {
        Console.WriteLine($"{base._Name} flying");
    }
}

AbstractAnimal animal = new Chicken();
animal.Breath();
animal.Action();

拆分之后，也會造成代碼量的增加，類多了，使用成本（理解成本）也高了，

那么，什么時候使用單一職責呢？

　　如果型別足夠簡單，方法夠少，是可以在類級別去違背單一職責的；如果型別復雜了，方法多了，建議遵循單一職責原則，

方法級別的單一職責原則：一個方法只負責一件事

類級別的單一職責原則：一個類只負責一件事

類別庫級別的單一職責原則：一個類別庫職責要清晰

專案級別的單一職責：一個專案應該職責要清晰（客戶端/管理后臺/后臺服務/定時任務/分布式引擎）

系統級別的單一職責：為通用功能拆分系統（IP定位/日志/在線統計）

2、里氏替換原則（Liskov Substitution Principle）

　　任何使用基類的地方，都可以透明（安全，不會出現行為不一致）的使用其子類

　　繼承：子類擁有父類的一切屬性和行為，任何父類出現的地方，都可以用子類來代替

　　a、父類有的，子類必須有，如果父類中出現了子類不應該有的東西，那么就應該斷掉繼承，再來一個父類，包含了都有的東西，

　　b、子類可以有自己的屬性和行為，子類出現的地方，父類不一定能代替（白馬非馬），

　　c、父類實作的東西，子類就不要再寫了（就是不要new隱藏），有時候會出現意想不到的地方，行為不一致，如果想修改父類的行為，通過abstract或者virtual，宣告屬性、欄位、變數，盡量宣告為父類，

3、依賴倒置原則（Dependence Inversion Principle）

　　高層模塊不應該依賴于低層模塊，二者應該是通過抽象依賴，依賴抽象，而不是依賴細節，面向物件，盡量使用抽象，80%的設計模式都是跟抽象有關（介面也可以），屬性、欄位、方法引數、回傳值，，，，盡量都是抽象

　　抽象：介面/抽象類---可以包含沒有實作的元素

　　細節：普通類（子類）---一切都是確定的

　　Student-------使用--------手機

　　高層--------------------------低層

就好像三層中：

　　BLL---------------------------DAL

如果在一開始，每個手機都定義通用的方法，學生在呼叫的時候，正常去呼叫，會出現高層依賴低層

 //Student-使用-手機
 //高層---------底層
 {
     iPhone phone = new iPhone();
     student.PlayiPhone(phone);
     student.PlayT(phone);
     student.Play(phone);
 }
 {
     Lumia phone = new Lumia();
     student.PlayLumia(phone);
     student.PlayT(phone);
     student.Play(phone);
 }
 {
     Honor phone = new Honor();
     student.PlayHonor(phone);
     student.PlayT(phone);
     student.Play(phone);
 }

解決上面出現的問題，定義一個手機的抽象父類，里面定義手機通用的功能，

/// <summary>
/// 定義一個手機抽象父類
/// </summary>

public abstract class AbstractPhone
{
    public int Id { get; set; }
    public string Branch { get; set; }
    public abstract void Call();
    public abstract void Text();
}

 /// <summary>
 /// 榮耀手機
 /// </summary>
 public class Honor : AbstractPhone
 {
     public override void Call()
     {
         Console.WriteLine("User {0} Call", this.GetType().Name);
     }

     public override void Text()
     {
         Console.WriteLine("User {0} Call", this.GetType().Name);
     }
 }

 /// <summary>
 /// iPhone
 /// </summary>
 public class iPhone : AbstractPhone
 {
     public override void Call()
     {
         Console.WriteLine("User {0} Call", this.GetType().Name);
     }
     public override void Text()
     {
         Console.WriteLine("User {0} Call", this.GetType().Name);
     }
 }

 /// <summary>
 /// 小米手機
 /// </summary>
 public class Mi : AbstractPhone
 {
     public override void Call()
     {
         Console.WriteLine("User {0} Call", this.GetType().Name);
     }
     public override void Text()
     {
         Console.WriteLine("User {0} Text", this.GetType().Name);
     }

     public void Bracelet()
     {
         Console.WriteLine("User {0} Bracelet", this.GetType().Name);
     }
 }

......只要是一部手機，只要繼承了抽象父類，都可以重寫父類中的抽象方法，實作通用的功能，也可以加上自己特有的功能（增加自己的功能，是不是很強大？后面就看出來了是否合理了），

下面有兩種方式去呼叫：泛型+父類約束=========》用抽象類，是等價的

public void PlayT<T>(T phone) where T : AbstractPhone
{
    Console.WriteLine("這里是{0}", this.Name);
    phone.Call();
    phone.Text();
}

public void Play(AbstractPhone phone)
{
    Console.WriteLine("這里是{0}", this.Name);
    phone.Call();
    phone.Text();

    //phone.Bracelet();
}

面向抽象有啥好處？

　　一個方法既滿足不同型別的引數，只要是實作了這個抽象類，都可以用；還支持擴展，不用修改Student類；面向抽象后，不能使用子類特別的內容，

　　在呼叫的時候，studen.Play(phone);如果，這個phone是一個小Mi手機的子類呢？Bracelet（手環功能）是有的，但是方法不能用，編譯器決定了是不能用Bracelet（dynamic/反射是可以呼叫的），不能常規呼叫，這個問題是解決不了的，

　　你這樣想，如果小米手機都是自己特有的功能，那還用抽象父類干嘛？直接小米手機自己搞一個不就行了？因為面向物件不止一個型別，用的就是通用功能；非通用功能，那就不應該面向物件了，

　　面向物件語言開發，只要抽象不變，高層就不變，

　　面向物件語言開發，就是類與類之間進行互動，如果高層直接依賴低層的細節，細節是多變的，那么低層的變化就導致上層的變化；如果層數多了，低層的修改會直接水波效應傳遞到最上層，一點細微的改動，都會導致整個系統從下往上的修改（這就是大家經常加班的原因），

　　面向抽象，如果高層和低層沒有直接依賴，而是依賴于抽象，抽象一般是穩定的，低層細節的變化擴展就不會影響到高層，這樣就能支持層內部的橫向擴展，不會影響到其他地方，這樣的程式架構就是穩定的，

　　依賴倒置原則（理論基礎）------IOC控制反轉（實踐封裝）-----DI依賴注入（實作IOC的手段），

4、介面隔離原則（Interface Segregation Principle）

　　客戶端不應該依賴它不需要的介面，一個類對另外一個類的依賴應該建立在最小的介面上，在作業中，80%都是用介面的，

　　AbstractPhone定義了Id、Branch、Call()、Text()，現在的智能手機，都有map、movie、online、game等功能，是否應該把這幾個功能上升到AbstractPhone里面去？

　　答案是不應該的，OldManPhone也是手機，但是沒有這些功能，AbstractPhone就只能放入任何手機都有的功能，

　　雖然這些東西不適合放在抽象類中，但是面向抽象編程，還有一個介面，抽象類 is a，介面 can do，面向物件編程中，是單繼承多實作的，將這些東西定義在介面中，不局限產品，

　　介面是什么？　　

　　　　簡單來說，介面就是，當一些東西都有相同的功能，但是有不能抽象出合理的父類的時候，這個時候就可以抽象為介面，

  public interface IExtend
  {
      void Photo();
      void Online();
      void Game();
      void Record();
      void Movie();
      void Map();//
      void Pay();
  }//都拆成一個方法一個介面

　　Camera能拍照，也能錄像，既然面向抽象，那么有些功能的物件都能傳遞進來，那就讓Camera也去實作IExtend介面？

　　不可以的，實作了IExtend介面，Camera出現了很多自己沒有的功能，不應該使用這種大而全的介面，所以要把介面的功能進一步拆分，因為介面是可以多實作的，

 public interface IExtend
 {
     //void Photo();
     //void Online();
     //void Game();
     void Record();
     //void Movie();
     void Map();//
     void Pay();
 }//都拆成一個方法一個介面


 //電視--上網 玩游戲
 public interface IExtendHappy : IExtendGame
 {
     void Online();
     //void Game();
 }
 //掌中游戲機：俄羅斯方塊--玩游戲不能上網

 public interface IExtendGame
 {
     void Game();
 }

 public interface IExtendVideo
 {
     void Photo();
     void Movie();//打開相機--切換模式--start--Suspend--End
 }

這樣拆分下去，都拆成一個方法一個介面了，肯定也不好，

在.Net中，有IList<T>，是索引相關；ICollection<T>，集合相關操作；IEnumerable<T>，迭代器foreach....

介面到底該怎么定義？

　　a、既不能是大而全，會強迫實作沒有的東西，也會依賴自己不需要的東西

　　b、也不能一個方法一個介面，這樣，面向抽象也沒意義了，

　　　　按照功能的密不可分可定義介面，而且應該是動態的，隨著業務發展會有變化的，但是在設計的時候，要留好提前量，避免抽象變化，這里沒有標準答案，隨著業務來調整的，

　　c、介面合并，Map----定位/導航/搜索，這種就屬于固定步驟，業務細節，盡量的內聚，在介面也不要暴露太多細節，

5、迪米特法則（Law Of Demeter）最少知道原則：高內聚低耦合

　　一個物件應該對其他物件保持最少的了解，只與直接的朋友通信，

　　面向物件----萬物皆物件-----類與類互動才能產生功能，這不就是耦合了嗎？要高內聚低耦合

　　類與類之間的關系：

　　　　縱向：繼承≈實作（最密切）

　　　　橫向：聚合>組合>包含>依賴（出現在方法內部）

　　迪米特法則：降低類與類之間的耦合，只與直接的朋友通信，就是要盡量避免依賴更多型別，

　　基類別庫（BCL-系統/框架內置）的型別除外

　　迪米特，也會增加一些成本

　　作業中，會去早一個中介（中間層）

　　上層UI下訂單-----訂單系統&支付&支付系統&倉儲&物流

　　門面模式----上層互動門面----門面依賴子系統

　　三層架構中：UI----BLL-----DAL

　　去掉內部依賴

　　降低訪問修飾符權限，private、protected、internal、protected internal、public

　　迪米特，依賴別人更少，讓別人了解更少

/// <summary>
/// 學生
/// </summary>
public class Student
{
    public int Id { get; set; }
    public string StudentName { get; set; }
    public int Height { private get; set; }

    public int Salay;

    public void ManageStudent()
    {
        Console.WriteLine(" {0}Manage {1} ", this.GetType().Name, this.StudentName);
    }
}

/// <summary>
/// 班級
/// </summary>
public class Class
{
    public int Id { get; set; }
    public string ClassName { get; set; }

    public List<Student> StudentList { get; set; }


    public void ManageClass()
    {
        Console.WriteLine(" {0}Manage {1} ", this.GetType().Name, this.ClassName);
        foreach (Student s in this.StudentList)
        {
            s.ManageStudent();
            //Console.WriteLine(" {0}Manage {1} ", s.GetType().Name, s.StudentName);
        }

    }


}

/// 學校
/// </summary>
public class School
{
    public int Id { get; set; }
    public string SchoolName { get; set; }
    public List<Class> ClassList { get; set; }

    public void Manage()
    {
        Console.WriteLine("Manage {0}", this.GetType().Name);
        foreach (Class c in this.ClassList)
        {
            //Console.WriteLine(" {0}Manage {1} ", c.GetType().Name, c.ClassName);
            c.ManageClass();//1 遵循了迪米特
            //List<Student> studentList = c.StudentList;
            //foreach (Student s in studentList)
            //{
            //    Console.WriteLine(" {0}Manage {1} ", s.GetType().Name, s.StudentName);
            //}//2 違背了迪米特法則

        }
    }


}

6、開閉原則（Open Closed Principle）

　　對擴展開放，對修改關閉

　　修改：修改現有代碼（類）

　　擴展：增加代碼（類）

　　面向物件語言是一種靜態語言，最害怕變化，會波及很多東西，全面測驗，嘴里將就是新增類，對原有代碼沒有改動，原有的代碼才是可信的，

　　開閉原則只是一個目標，并沒有任何的手段，也別成為總則，其他5個原則的建議，就是為了更好的做到OCP，開閉原則也是面向物件語言開發的一個終極目標，

　　如果有功能增加/修改的需求，那么就修改現有的方法---增加方法---增加類----增加/替換類別庫，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/46474.html

標籤：設計模式

上一篇：C#中增量類功能的方式之繼承與擴展

下一篇：設計模式-結構型-配接器模式