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
一、單一責任原則
單一責任原則,簡單來說就是一個類或一個模組,只負責一種或一類職責。
看程式碼:
publicinterfaceIUser
{
voidAddUser();
voidRemoveUser();
voidUpdateUser();
voidLogger();
voidMessage();
}
根據原則,我們會發現,對於IUser
來說,前三個方法:AddUser
、RemoveUser
、UpdateUser
是有意義的,而後兩個Logger
Message
作為IUser
的一部分功能,是沒有意義的並不符合單一責任原則的。
所以,我們可以把它分解成不同的介面:
publicinterfaceIUser
{
voidAddUser();
voidRemoveUser();
voidUpdateUser();
}
publicinterfaceILog
{
voidLogger();
}
publicinterfaceIMessage
{
voidMessage();
}
拆分後,我們看到,三個介面各自完成自己的責任,可讀性和可維護性都很好。
下面是使用的例子,採用依賴注入來做:
publicclassLog:ILog
{
publicvoidLogger ()
{
Console.WriteLine("LoggedError");
}
}
publicclassMsg:IMessage
{
publicvoidMessage()
{
Console.WriteLine("MessagedSent");
}
}
classClass_DI
{
privatereadonlyIUser_user;
privatereadonlyILog_log;
privatereadonlyIMessage_msg;
publicClass_DI(IUseruser,ILoglog,IMessagemsg)
{
this._user=user;
this._log=log;
this._msg=msg;
}
publicvoidUser()
{
this._user.AddUser();
this._user.RemoveUser();
this._user.UpdateUser();
}
publicvoidLog()
{
this._log.Logger();
}
publicvoidMsg()
{
this._msg.Message();
}
}
publicstaticvoidMain()
{
Class_DIdi=newClass_DI(newUser(),newLog(),newMsg());
di.User();
di.Log();
di.Msg();
}
這樣的程式碼,看著就漂亮多了。
二、開閉原則
開閉原則要求類、模組、函式等實體應該對擴充套件開放,對修改關閉。
我們先來看一段程式碼,計算員工的獎金:
publicclassEmployee
{
publicintEmployee_ID;
publicstringName;
publicEmployee(intid,stringname)
{
this.Employee_ID=id;
this.Name=name;
}
publicdecimalBonus(decimalsalary)
{
returnsalary*.2M;
}
}
classProgram
{
staticvoidMain(string[]args)
{
Employeeemp=newEmployee(101,"WangPlus");
Console.WriteLine("EmployeeID:{0}Name:{1}Bonus:{2}",emp.Employee_ID,emp.Name,emp.Bonus(10000));
}
}
現在假設,計算獎金的公式做了改動。
要實現這個,我們可能需要對程式碼進行修改:
publicclassEmployee
{
publicintEmployee_ID;
publicstringName;
publicstringEmployee_Type;
publicEmployee(intid,stringname,stringtype)
{
this.Employee_ID=id;
this.Name=name;
this.Employee_Type=type;
}
publicdecimalBonus(decimalsalary)
{
if(Employee_Type=="manager")
returnsalary*.2M;
else
return
salary*.1M;
}
}
顯然,為了實現改動,我們修改了類和方法。
這違背了開閉原則。
那我們該怎麼做?
我們可以用抽象類來實現 - 當然,實際有很多實現方式,選擇最習慣或自然的方式就成:
publicabstractclassEmployee
{
publicintEmployee_ID;
publicstringName;
publicEmployee(intid,stringname)
{
this.Employee_ID=id;
this.Name=name;
}
publicabstractdecimalBonus(decimalsalary);
}
然後,我們再實現最初的功能:
publicclassGeneralEmployee:Employee
{
publicGeneralEmployee(intid,stringname):base(id,name)
{
}
publicoverridedecimalBonus(decimalsalary)
{
returnsalary*.2M;
}
}
classProgram
{
publicstaticvoidMain()
{
Employeeemp=newGeneralEmployee(101,"WangPlus");
Console.WriteLine("EmployeeID:{0}Name:{1}Bonus:{2}",emp.Employee_ID,emp.Name,emp.Bonus(10000));
}
}
在這兒使用抽象類的好處是:如果未來需要修改獎金規則,則不需要像前邊例子一樣,修改整個類和方法,因為現在的擴充套件是開放的。
程式碼寫完整了是這樣:
publicabstractclassEmployee
{
publicintEmployee_ID;
publicstringName;
publicEmployee(intid,stringname)
{
this.Employee_ID=id;
this.Name=name;
}
publicabstractdecimalBonus(decimalsalary);
}
publicclassGeneralEmployee:Employee
{
publicGeneralEmployee(intid,stringname):base(id,name)
{
}
publicoverridedecimalBonus(decimalsalary)
{
returnsalary*.1M;
}
}
publicclassManagerEmployee:Employee
{
publicManagerEmployee(intid,stringname):base(id,name)
{
}
publicoverridedecimalBonus(decimalsalary)
{
returnsalary*.2M;
}
}
classProgram
{
publicstaticvoidMain()
{
Employeeemp=newGeneralEmployee(101,"WangPlus");
Employeeemp1=newManagerEmployee(102,"WangPlus1");
Console.WriteLine("EmployeeID:{0}Name:{1}Bonus:{2}",emp.Employee_ID,emp.Name,emp.Bonus(10000));
Console.WriteLine("EmployeeID:{0}Name:{1}Bonus:{2}",emp1.Employee_ID,emp1.Name,emp1.Bonus(10000));
}
}
三、里氏替換原則
里氏替換原則,講的是:子類可以擴充套件父類的功能,但不能改變基類原有的功能。它有四層含義:
- 子類可以實現父類的抽象方法,但不能覆蓋父類的非抽象方法;
- 子類中可以增加自己的特有方法;
- 當子類過載父類的方法時,方法的前置條件(形參)要比父類的輸入引數更寬鬆;
- 當子類實現父類的抽象方法時,方法的後置條件(返回值)要比父類更嚴格。
在前邊開閉原則中,我們的例子裡,實際上也遵循了部分里氏替換原則,我們用GeneralEmployee
和ManagerEmployee
替換了父類Employee
。
還是拿程式碼來說。
假設需求又改了,這回加了一個臨時工,是沒有獎金的。
publicclassTempEmployee:Employee
{
publicTempEmployee(intid,stringname):base(id,name)
{
}
publicoverridedecimalBonus(decimalsalary)
{
thrownewNotImplementedException();
}
}
classProgram
{
publicstaticvoidMain()
{
Employeeemp=newGeneralEmployee(101,"WangPlus");
Employeeemp1=newManagerEmployee(101,"WangPlus1");
Employeeemp2=newTempEmployee(102,"WangPlus2");
Console.WriteLine("EmployeeID:{0}Name:{1}Bonus:{2}",emp.Employee_ID,emp.Name,emp.Bonus(10000));
Console.WriteLine("EmployeeID:{0}Name:{1}Bonus:{2}",emp1.Employee_ID,emp1.Name,emp1.Bonus(10000));
Console.WriteLine("EmployeeID:{0}Name:{1}Bonus:{2}",emp2.Employee_ID,emp2.Name,emp2.Bonus(10000));
Console.ReadLine();
}
}
顯然,這個方式不符合里氏替原則的第四條,它丟擲了一個錯誤。
所以,我們需要繼續修改程式碼,並增加兩個介面:
interfaceIBonus
{
decimalBonus(decimalsalary);
}
interfaceIEmployee
{
intEmployee_ID{get;set;}
stringName{get;set;}
decimalGetSalary();
}
publicabstractclassEmployee:IEmployee,IBonus
{
publicintEmployee_ID{get;set;}
publicstringName{get;set;}
publicEmployee(intid,stringname)
{
this.Employee_ID=id;
this.Name=name;
}
publicabstractdecimalGetSalary();
publicabstractdecimalBonus(decimalsalary);
}
publicclassGeneralEmployee:Employee
{
publicGeneralEmployee(intid,stringname):base(id,name)
{
}
publicoverridedecimalGetSalary()
{
return10000;
}
publicoverridedecimalBonus(decimalsalary)
{
returnsalary*.1M;
}
}
publicclassManagerEmployee:Employee
{
publicManagerEmployee(intid,stringname):base(id,name)
{
}
publicoverridedecimalGetSalary()
{
return10000;
}
publicoverridedecimalBonus(decimalsalary)
{
returnsalary*.1M;
}
}
publicclassTempEmployee:IEmployee
{
publicintEmployee_ID{get;set;}
publicstringName{get;set;}
publicTempEmployee(intid,stringname)
{
this.Employee_ID=id;
this.Name=name;
}
publicdecimalGetSalary()
{
return5000;
}
}
classProgram
{
publicstaticvoidMain()
{
Employeeemp=newGeneralEmployee(101,"WangPlus");
Employeeemp1=newManagerEmployee(102,"WangPlus1");
Console.WriteLine("EmployeeID:{0}Name:{1}Salary:{2}Bonus:{3}",emp.Employee_ID,emp.Name,emp.GetSalary(),emp.Bonus(emp.GetSalary()));
Console.WriteLine("EmployeeID:{0}Name:{1}Salary:{2}Bonus:{3}",emp1.Employee_ID,emp1.Name,emp1.GetSalary(),emp1.Bonus(emp1.GetSalary()));
List<IEmployee>emp_list=newList<IEmployee>();
emp_list.Add(newGeneralEmployee(101,"WangPlus"));
emp_list.Add(newManagerEmployee(102,"WangPlus1"));
emp_list.Add(newTempEmployee(103,"WangPlus2"));
foreach(varobjinemp_list)
{
Console.WriteLine("EmployeeID:{0}Name:{1}Salary:{2}",obj.EmpId,obj.Name,obj.GetSalary());
}
}
}
四、介面隔離原則
介面隔離原則要求客戶不依賴於它不使用的介面和方法;一個類對另一個類的依賴應該建立在最小的介面上。
通常的做法,是把一個臃腫的介面拆分成多個更小的介面,以保證客戶只需要知道與它相關的方法。
這個部分不做程式碼演示了,可以去看看上邊單一責任原則裡的程式碼,也遵循了這個原則。
五、依賴倒置原則
依賴倒置原則要求高層模組不能依賴於低層模組,而是兩者都依賴於抽象。另外,抽象不應該依賴於細節,而細節應該依賴於抽象。
看程式碼:
publicclassMessage
{
publicvoidSendMessage()
{
Console.WriteLine("MessageSent");
}
}
publicclassNotification
{
privateMessage_msg;
publicNotification()
{
_msg=newMessage();
}
publicvoidPromotionalNotification()
{
_msg.SendMessage();
}
}
classProgram
{
publicstaticvoidMain()
{
Notificationnotify=newNotification();
notify.PromotionalNotification();
}
}
這個程式碼中,通知完全依賴Message
類,而Message
類只能傳送一種通知。如果我們需要引入別的型別,例如郵件和SMS,則需要修改Message
類。
下面,我們使用依賴倒置原則來完成這段程式碼:
publicinterfaceIMessage
{
voidSendMessage();
}
publicclassEmail:IMessage
{
publicvoidSendMessage()
{
Console.WriteLine("SendEmail");
}
}
publicclassSMS:IMessage
{
publicvoidSendMessage()
{
Console.WriteLine("SendSms");
}
}
publicclassNotification
{
privateIMessage_msg;
publicNotification(IMessagemsg)
{
this._msg=msg;
}
publicvoidNotify()
{
_msg.SendMessage();
}
}
classProgram
{
publicstaticvoidMain()
{
Emailemail=newEmail();
Notificationnotify=newNotification(email);
notify.Notify();
SMSsms=newSMS();
notify=newNotification(sms);
notify.Notify();
}
}
通過這種方式,我們把程式碼之間的耦合降到了最小。
六、迪米特法則
迪米特法則也叫最少知道法則。從稱呼就可以知道,意思是:一個物件應該對其它物件有最少的瞭解。
在寫程式碼的時候,儘可能少暴露自己的介面或方法。寫類的時候,能不public
就不public
,所有暴露的屬性、介面、方法,都是不得不暴露的,這樣能確保其它類對這個類有最小的瞭解。
這個原則沒什麼需要多講的,呼叫者只需要知道被呼叫者公開的方法就好了,至於它內部是怎麼實現的或是有其他別的方法,呼叫者並不關心,呼叫者只關心它需要用的。反而,如果被呼叫者暴露太多不需要暴露的屬性或方法,那麼就可能導致呼叫者濫用其中的方法,或是引起一些其他不必要的麻煩。
最後說兩句:所謂原則,不是規則,不是硬性的規定。在程式碼中,能靈活應用就好,不需要非拘泥於形式,但是,用好了,會讓程式碼寫得很順手,很漂亮。
(全文完)
微信公眾號:老王Plus 掃描二維碼,關注個人公眾號,可以第一時間得到最新的個人文章和內容推送 本文版權歸作者所有,轉載請保留此宣告和原文連結 |