C#實踐設計模式原則SOLID

時間  2020-08-21
標籤 c# 實踐 設計 模式 原則 solid 欄目 C# 简体版
原文   原文鏈接

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

 

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

  1. S - Single Responsibility Principle，單一責任原則
  2. O - Open Closed Principle，開閉原則
  3. L - Liskov Substitution Principle，里氏替換原則
  4. I - Interface Segregation Principle，接口隔離原則
  5. D - Dependency Inversion Principle，依賴倒置原則

嗯，這就是五大原則。c#

後來又加入了一個：Law of Demeter，迪米特法則。因而，就變成了六大原則。設計模式

 

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

    爲了防止不提供原網址的轉載，特在這裏加上原文連接：http://www.javashuo.com/article/p-zpsnnski-nc.htmlapp

1、單一責任原則

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

看代碼：函數

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

    void Logger();
    void Message();
}

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

因此，咱們能夠把它分解成不一樣的接口：this

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();
}

這樣的代碼，看着就漂亮多了。

2、開閉原則

開閉原則要求類、模塊、函數等實體應該對擴展開放，對修改關閉。

 

咱們先來看一段代碼，計算員工的獎金：

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));
    }
}

3、里氏替換原則

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

  1. 子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法；
  2. 子類中能夠增長本身的特有方法；
  3. 當子類重載父類的方法時，方法的前置條件（形參）要比父類的輸入參數更寬鬆；
  4. 當子類實現父類的抽象方法時，方法的後置條件（返回值）要比父類更嚴格。

在前邊開閉原則中，咱們的例子裏，實際上也遵循了部分里氏替換原則，咱們用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());
        }
    }
}

4、接口隔離原則

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

一般的作法，是把一個臃腫的接口拆分紅多個更小的接口，以保證客戶只須要知道與它相關的方法。

這個部分不作代碼演示了，能夠去看看上邊單一責任原則裏的代碼，也遵循了這個原則。

5、依賴倒置原則

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

看代碼：

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();
    }
}

經過這種方式，咱們把代碼之間的耦合降到了最小。

6、迪米特法則

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

在寫代碼的時候，儘量少暴露本身的接口或方法。寫類的時候，能不public就不public，全部暴露的屬性、接口、方法，都是不得不暴露的，這樣能確保其它類對這個類有最小的瞭解。

這個原則沒什麼須要多講的，調用者只須要知道被調用者公開的方法就行了，至於它內部是怎麼實現的或是有其餘別的方法，調用者並不關心，調用者只關心它須要用的。反而，若是被調用者暴露太多不須要暴露的屬性或方法，那麼就可能致使調用者濫用其中的方法，或是引發一些其餘沒必要要的麻煩。

 

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

 

（全文完）

 

 

微信公衆號：老王Plus

掃描二維碼，關注我的公衆號，能夠第一時間獲得最新的我的文章和內容推送

本文版權歸做者全部，轉載請保留此聲明和原文連接
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程