MySQL常見的七種鎖詳細介紹
阿新 • • 發佈：2020-08-19
理論跟實踐的關係，說遠不遠，說近不近。能不能把理論用到實踐上，還真不好說。
通常講到設計模式，一個最通用的原則是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，所有暴露的屬性、介面、方法，都是不得不暴露的，這樣能確保其它類對這個類有最小的瞭解。
這個原則沒什麼需要多講的，呼叫者只需要知道被呼叫者公開的方法就好了，至於它內部是怎麼實現的或是有其他別的方法，呼叫者並不關心，呼叫者只關心它需要用的。反而，如果被呼叫者暴露太多不需要暴露的屬性或方法，那麼就可能導致呼叫者濫用其中的方法，或是引起一些其他不必要的麻煩。
最後說兩句：所謂原則，不是規則，不是硬性的規定。在程式碼中，能靈活應用就好，不需要非拘泥於形式，但是，用好了，會讓程式碼寫得很順手，很漂亮。
（全文完）