理論跟實踐的關係，說遠不遠，說近不近。能不能把理論用到實踐上，還真不好說。
通常講到設計模式，一個最通用的原則是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 掃描二維碼，關注個人公眾號，可以第一時間得到最新的個人文章和內容推送 本文版權歸作者所有，轉載請保留此宣告和原文連結 |