C#實踐設計模式原則SOLID

老王Plus發表於2020-08-19

C#設計模式Solid

理論跟實踐的關係，說遠不遠，說近不近。能不能把理論用到實踐上，還真不好說。

通常講到設計模式，一個最通用的原則是SOLID：

S - Single Responsibility Principle，單一責任原則
O - Open Closed Principle，開閉原則
L - Liskov Substitution Principle，里氏替換原則
I - Interface Segregation Principle，介面隔離原則
D - Dependency Inversion Principle，依賴倒置原則

嗯，這就是五大原則。

後來又加入了一個：Law of Demeter，迪米特法則。於是，就變成了六大原則。

原則好理解。怎麼用在實踐中？

為了防止不提供原網址的轉載，特在這裡加上原文連結：https://www.cnblogs.com/tiger-wang/p/13525841.html

一、單一責任原則

單一責任原則，簡單來說就是一個類或一個模組，只負責一種或一類職責。

看程式碼：

public interface IUser
{
    void AddUser();
    void RemoveUser();
    void UpdateUser();

    void Logger();
    void Message();
}

根據原則，我們會發現，對於IUser來說，前三個方法：AddUser、RemoveUser、UpdateUser是有意義的，而後兩個Logger和Message作為IUser的一部分功能，是沒有意義的並不符合單一責任原則的。

所以，我們可以把它分解成不同的介面：

public interface IUser
{
    void AddUser();
    void RemoveUser();
    void UpdateUser();
}
public interface ILog
{
    void Logger();
}
public interface IMessage
{
    void Message();
}

拆分後，我們看到，三個介面各自完成自己的責任，可讀性和可維護性都很好。

下面是使用的例子，採用依賴注入來做：

public class Log : ILog
{
    public void Logger()
    {
        Console.WriteLine("Logged Error");
    }
}
public class Msg : IMessage
{
    public void Message()
    {
        Console.WriteLine("Messaged Sent");
    }
}
class Class_DI
{
    private readonly IUser _user;
    private readonly ILog _log;
    private readonly IMessage _msg;
    public Class_DI(IUser user, ILog log, IMessage msg)
    {
        this._user = user;
        this._log = log;
        this._msg = msg;
    }
    public void User()
    {
        this._user.AddUser();
        this._user.RemoveUser();
        this._user.UpdateUser();
    }
    public void Log()
    {
        this._log.Logger();
    }
    public void Msg()
    {
        this._msg.Message();
    }
}
public static void Main()
{
    Class_DI di = new Class_DI(new User(), new Log(), new Msg());
    di.User();
    di.Log();
    di.Msg();
}

這樣的程式碼，看著就漂亮多了。

二、開閉原則

開閉原則要求類、模組、函式等實體應該對擴充套件開放，對修改關閉。

我們先來看一段程式碼，計算員工的獎金：

public class Employee
{
    public int Employee_ID;
    public string Name;
    public Employee(int id, string name)
    {
        this.Employee_ID = id;
        this.Name = name;
    }
    public decimal Bonus(decimal salary)
    {
        return salary * .2M;
    }
}
class Program
{
    static void Main(string[] args)
    {
        Employee emp = new Employee(101, "WangPlus");
        Console.WriteLine("Employee ID: {0} Name: {1} Bonus: {2}", emp.Employee_ID, emp.Name, emp.Bonus(10000));
    }
}

現在假設，計算獎金的公式做了改動。

要實現這個，我們可能需要對程式碼進行修改：

public class Employee
{
    public int Employee_ID;
    public string Name;
    public string Employee_Type;

    public Employee(int id, string name, string type)
    {
        this.Employee_ID = id;
        this.Name = name;
        this.Employee_Type = type;
    }
    public decimal Bonus(decimal salary)
    {
        if (Employee_Type == "manager")
            return salary * .2M;
        else
            return
                salary * .1M;
    }
}

顯然，為了實現改動，我們修改了類和方法。

這違背了開閉原則。

那我們該怎麼做？

我們可以用抽象類來實現 - 當然，實際有很多實現方式，選擇最習慣或自然的方式就成：

public abstract class Employee
{
    public int Employee_ID;
    public string Name;
    public Employee(int id, string name)
    {
        this.Employee_ID = id;
        this.Name = name;
    }
    public abstract decimal Bonus(decimal salary);
}

然後，我們再實現最初的功能：

public class GeneralEmployee : Employee
{
    public GeneralEmployee(int id, string name) : base(id, name)
    {
    }
    public override decimal Bonus(decimal salary)
    {
        return salary * .2M;
    }
}
class Program
{
    public static void Main()
    {
        Employee emp = new GeneralEmployee(101, "WangPlus");
        Console.WriteLine("Employee ID: {0} Name: {1} Bonus: {2}", emp.Employee_ID, emp.Name, emp.Bonus(10000));
    }
}

在這兒使用抽象類的好處是：如果未來需要修改獎金規則，則不需要像前邊例子一樣，修改整個類和方法，因為現在的擴充套件是開放的。

程式碼寫完整了是這樣：

public abstract class Employee
{
    public int Employee_ID;
    public string Name;
    public Employee(int id, string name)
    {
        this.Employee_ID = id;
        this.Name = name;
    }
    public abstract decimal Bonus(decimal salary);
}

public class GeneralEmployee : Employee
{
    public GeneralEmployee(int id, string name) : base(id, name)
    {
    }
    public override decimal Bonus(decimal salary)
    {
        return salary * .1M;
    }
}
public class ManagerEmployee : Employee
{
    public ManagerEmployee(int id, string name) : base(id, name)
    {
    }
    public override decimal Bonus(decimal salary)
    {
        return salary * .2M;
    }
}
class Program
{
    public static void Main()
    {
        Employee emp = new GeneralEmployee(101, "WangPlus");
        Employee emp1 = new ManagerEmployee(102, "WangPlus1");
        Console.WriteLine("Employee ID: {0} Name: {1} Bonus: {2}", emp.Employee_ID, emp.Name, emp.Bonus(10000));
        Console.WriteLine("Employee ID: {0} Name: {1} Bonus: {2}", emp1.Employee_ID, emp1.Name, emp1.Bonus(10000));
    }
}

三、里氏替換原則

里氏替換原則，講的是：子類可以擴充套件父類的功能，但不能改變基類原有的功能。它有四層含義：

子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法；
子類中可以增加自己的特有方法；
當子類過載父類的方法時，方法的前置條件（形參）要比父類的輸入引數更寬鬆；
當子類實現父類的抽象方法時，方法的後置條件（返回值）要比父類更嚴格。

在前邊開閉原則中，我們的例子裡，實際上也遵循了部分里氏替換原則，我們用GeneralEmployee和ManagerEmployee替換了父類Employee。

還是拿程式碼來說。

假設需求又改了，這回加了一個臨時工，是沒有獎金的。

public class TempEmployee : Employee
{
    public TempEmployee(int id, string name) : base(id, name)
    {
    }
    public override decimal Bonus(decimal salary)
    {
        throw new NotImplementedException();
    }
}
class Program
{
    public static void Main()
    {
        Employee emp = new GeneralEmployee(101, "WangPlus");
        Employee emp1 = new ManagerEmployee(101, "WangPlus1");
        Employee emp2 = new TempEmployee(102, "WangPlus2");
        Console.WriteLine("Employee ID: {0} Name: {1} Bonus: {2}", emp.Employee_ID, emp.Name, emp.Bonus(10000));
        Console.WriteLine("Employee ID: {0} Name: {1} Bonus: {2}", emp1.Employee_ID, emp1.Name, emp1.Bonus(10000));
        Console.WriteLine("Employee ID: {0} Name: {1} Bonus: {2}", emp2.Employee_ID, emp2.Name, emp2.Bonus(10000));
        Console.ReadLine();
    }
}

顯然，這個方式不符合里氏替原則的第四條，它丟擲了一個錯誤。

所以，我們需要繼續修改程式碼，並增加兩個介面：

interface IBonus
{
    decimal Bonus(decimal salary);
}
interface IEmployee
{
    int Employee_ID { get; set; }
    string Name { get; set; }
    decimal GetSalary();
}
public abstract class Employee : IEmployee, IBonus
{
    public int Employee_ID { get; set; }
    public string Name { get; set; }
    public Employee(int id, string name)
    {
        this.Employee_ID = id;
        this.Name = name;
    }
    public abstract decimal GetSalary();
    public abstract decimal Bonus(decimal salary);
}
public class GeneralEmployee : Employee
{
    public GeneralEmployee(int id, string name) : base(id, name)
    {
    }
    public override decimal GetSalary()
    {
        return 10000;
    }
    public override decimal Bonus(decimal salary)
    {
        return salary * .1M;
    }
}
public class ManagerEmployee : Employee
{
    public ManagerEmployee(int id, string name) : base(id, name)
    {
    }
    public override decimal GetSalary()
    {
        return 10000;
    }
    public override decimal Bonus(decimal salary)
    {
        return salary * .1M;
    }
}
public class TempEmployee : IEmployee
{
    public int Employee_ID { get; set; }
    public string Name { get; set; }
    public TempEmployee(int id, string name)
    {
        this.Employee_ID = id;
        this.Name = name;
    }
    public decimal GetSalary()
    {
        return 5000;
    }
}
class Program
{
    public static void Main()
    {
        Employee emp = new GeneralEmployee(101, "WangPlus");
        Employee emp1 = new ManagerEmployee(102, "WangPlus1");
        Console.WriteLine("Employee ID: {0} Name: {1} Salary: {2} Bonus:{3}", emp.Employee_ID, emp.Name, emp.GetSalary(), emp.Bonus(emp.GetSalary()));
        Console.WriteLine("Employee ID: {0} Name: {1} Salary: {2} Bonus:{3}", emp1.Employee_ID, emp1.Name, emp1.GetSalary(), emp1.Bonus(emp1.GetSalary()));

        List<IEmployee> emp_list = new List<IEmployee>();
        emp_list.Add(new GeneralEmployee(101, "WangPlus"));
        emp_list.Add(new ManagerEmployee(102, "WangPlus1"));
        emp_list.Add(new TempEmployee(103, "WangPlus2"));
        foreach (var obj in emp_list)
        {
            Console.WriteLine("Employee ID: {0} Name: {1} Salary: {2} ", obj.EmpId, obj.Name, obj.GetSalary());
        }
    }
}

四、介面隔離原則

介面隔離原則要求客戶不依賴於它不使用的介面和方法；一個類對另一個類的依賴應該建立在最小的介面上。

通常的做法，是把一個臃腫的介面拆分成多個更小的介面，以保證客戶只需要知道與它相關的方法。

這個部分不做程式碼演示了，可以去看看上邊單一責任原則裡的程式碼，也遵循了這個原則。

五、依賴倒置原則

依賴倒置原則要求高層模組不能依賴於低層模組，而是兩者都依賴於抽象。另外，抽象不應該依賴於細節，而細節應該依賴於抽象。

看程式碼：

public class Message
{
    public void SendMessage()
    {
        Console.WriteLine("Message Sent");
    }
}
public class Notification
{
    private Message _msg;

    public Notification()
    {
        _msg = new Message();
    }
    public void PromotionalNotification()
    {
        _msg.SendMessage();
    }
}
class Program
{
    public static void Main()
    {
        Notification notify = new Notification();
        notify.PromotionalNotification();
    }
}

這個程式碼中，通知完全依賴Message類，而Message類只能傳送一種通知。如果我們需要引入別的型別，例如郵件和SMS，則需要修改Message類。

下面，我們使用依賴倒置原則來完成這段程式碼：

public interface IMessage
{
    void SendMessage();
}
public class Email : IMessage
{
    public void SendMessage()
    {
        Console.WriteLine("Send Email");
    }
}
public class SMS : IMessage
{
    public void SendMessage()
    {
        Console.WriteLine("Send Sms");
    }
}
public class Notification
{
    private IMessage _msg;
    public Notification(IMessage msg)
    {
        this._msg = msg;
    }
    public void Notify()
    {
        _msg.SendMessage();
    }
}
class Program
{
    public static void Main()
    {
        Email email = new Email();
        Notification notify = new Notification(email);
        notify.Notify();

        SMS sms = new SMS();
        notify = new Notification(sms);
        notify.Notify();
    }
}

通過這種方式，我們把程式碼之間的耦合降到了最小。

六、迪米特法則

迪米特法則也叫最少知道法則。從稱呼就可以知道，意思是：一個物件應該對其它物件有最少的瞭解。

在寫程式碼的時候，儘可能少暴露自己的介面或方法。寫類的時候，能不public就不public，所有暴露的屬性、介面、方法，都是不得不暴露的，這樣能確保其它類對這個類有最小的瞭解。

這個原則沒什麼需要多講的，呼叫者只需要知道被呼叫者公開的方法就好了，至於它內部是怎麼實現的或是有其他別的方法，呼叫者並不關心，呼叫者只關心它需要用的。反而，如果被呼叫者暴露太多不需要暴露的屬性或方法，那麼就可能導致呼叫者濫用其中的方法，或是引起一些其他不必要的麻煩。

最後說兩句：所謂原則，不是規則，不是硬性的規定。在程式碼中，能靈活應用就好，不需要非拘泥於形式，但是，用好了，會讓程式碼寫得很順手，很漂亮。

（全文完）

微信公眾號：老王Plus

掃描二維碼，關注個人公眾號，可以第一時間得到最新的個人文章和內容推送

本文版權歸作者所有，轉載請保留此宣告和原文連結

實踐GoF的23種設計模式：SOLID原則（上）
2022-03-01
Go設計模式Solid
SOLID 設計原則
2019-04-10
Solid
SOLID架構設計原則
2021-03-01
Solid架構
C# 設計模式（0）——設計原則
2021-12-06
C#設計模式
SOLID 五大設計原則
2021-03-05
Solid
面向JavaScript的SOLID設計原則
2014-01-26
JavaScriptSolid
六大設計原則(SOLID)
2024-04-23
Solid
如何實踐設計原則
2016-01-09
SOLID 原則：軟體設計的基本原則
2024-04-19
Solid
《JavaScript設計模式與開發實踐》原則篇（2）—— 最少知識原則
2018-12-30
JavaScript設計模式
C#設計模式學習筆記：設計原則
2020-12-22
C#設計模式筆記
SOLID原則
2023-03-01
Solid
SOLID 原則
2017-12-23
Solid
Java的SOLID程式設計原則 - Filippo Buletto
2019-02-24
JavaSolid程式設計
《JavaScript設計模式與開發實踐》原則篇（1）—— 單一職責原則
2018-12-28
JavaScript設計模式
《JavaScript設計模式與開發實踐》原則篇（3）—— 開放-封閉原則
2019-01-03
JavaScript設計模式
設計原則設計模式
2020-08-24
設計模式
設計模式 - 設計原則
2021-04-14
設計模式
【設計模式】設計原則
2022-06-29
設計模式
物件導向設計的六大原則（SOLID原則）-——里氏替換原則
2024-03-14
物件Solid
設計模式的設計原則
2021-11-11
設計模式
【設計模式——六原則】
2016-03-12
設計模式
SOLID原則的堅實指南| Baeldung
2019-02-06
Solid
SOLID：物件導向設計的前五項原則
2020-07-24
Solid物件
架構設計的五大原則-SOLID
2018-10-25
架構Solid
講講solid原則
2019-05-01
Solid
SOLID原則筆記
2024-06-23
Solid筆記
Javascript 設計模式之設計原則
2019-07-21
JavaScript設計模式
JavaScript設計模式（一）設計原則
2018-11-08
JavaScript設計模式
設計模式（07）——設計原則（2）
2020-12-05
設計模式
設計模式（06）——設計原則（1）
2020-12-01
設計模式
設計模式學習-設計原則
2017-12-21
設計模式
鮑勃大叔：SOLID原則適合函式程式設計嗎？
2019-08-27
Solid函式程式設計
設計模式 -- 設計模式七大原則
2020-11-01
設計模式
設計模式六大設計原則
2021-07-23
設計模式
設計模式 #1（7大設計原則）
2020-09-13
設計模式
設計模式-六大設計原則
2022-03-19
設計模式
【架構設計】你真的理解軟體設計中的SOLID原則嗎？
2023-01-14
架構Solid