文章出處
三、LSP優點:
文章列表
一、LSP簡介(LSP--Liskov Substitution Principle):
定義:如果對于類型S的每一個對象o1,都有一個類型T的對象o2,使對于任意用類型T定義的程序P,將o2替換為o1,P的行為保持不變,則稱S為T的一個子類型。
子類型必須能夠替換它的基類型。LSP又稱里氏替換原則。
對于這個原則,通俗一些的理解就是,父類的方法都要在子類中實現或者重寫。
二、舉例說明:
對于依賴倒置原則,說的是父類不能依賴子類,它們都要依賴抽象類。這種依賴是我們實現代碼擴展和運行期內綁定(多態)的基礎。因為一旦類的使用者依賴某個具體的類,那么對該依賴的擴展就無從談起;而依賴某個抽象類,則只要實現了該抽象類的子類,都可以被類的使用者使用,從而實現了系統的擴展。
但是,光有依賴倒置原則,并不一定就使我們的代碼真正具有良好的擴展性和運行期內綁定。請看下面的代碼:
但是,光有依賴倒置原則,并不一定就使我們的代碼真正具有良好的擴展性和運行期內綁定。請看下面的代碼:
public class Animal
{
private string name;
public Animal(string name)
{
this.name = name;
}
public void Description()
{
Console.WriteLine("This is a(an) " + name);
}
}
{
private string name;
public Animal(string name)
{
this.name = name;
}
public void Description()
{
Console.WriteLine("This is a(an) " + name);
}
}
//下面是它的子類貓類:
public class Cat : Animal
{
public Cat(string name)
{
}
public void Mew()
{
Console.WriteLine("The cat is saying like 'mew'");
}
}
public class Cat : Animal
{
public Cat(string name)
{
}
public void Mew()
{
Console.WriteLine("The cat is saying like 'mew'");
}
}
//下面是它的子類狗類:
public class Dog : Animal
{
public Dog(string name)
{
public class Dog : Animal
{
public Dog(string name)
{
}
public void Bark()
{
Console.WriteLine("The dog is saying like 'bark'");
}
}
public void Bark()
{
Console.WriteLine("The dog is saying like 'bark'");
}
}
//最后,我們來看客戶端的調用:
public void DecriptionTheAnimal(Animal animal)
{
if (typeof(animal) is Cat)
{
Cat cat = (Cat)animal;
Cat.Decription();
Cat.Mew();
}
else if (typeof(animal) is Dog)
{
Dog dog = (Dog)animal;
Dog.Decription();
Dog.Bark();
}
}
public void DecriptionTheAnimal(Animal animal)
{
if (typeof(animal) is Cat)
{
Cat cat = (Cat)animal;
Cat.Decription();
Cat.Mew();
}
else if (typeof(animal) is Dog)
{
Dog dog = (Dog)animal;
Dog.Decription();
Dog.Bark();
}
}
通過上面的代碼,我們可以看到雖然客戶端的依賴是對抽象的依賴,但依然這個設計的擴展性不好,運行期綁定沒有實現。
是什么原因呢?其實就是因為不滿足里氏替換原則,子類如Cat有Mew()方法父類根本沒有,Dog類有Bark()方法父類也沒有,兩個子類都不能替換父類。這樣導致了系統的擴展性不好和沒有實現運行期內綁定。
是什么原因呢?其實就是因為不滿足里氏替換原則,子類如Cat有Mew()方法父類根本沒有,Dog類有Bark()方法父類也沒有,兩個子類都不能替換父類。這樣導致了系統的擴展性不好和沒有實現運行期內綁定。
現在看來,一個系統或子系統要擁有良好的擴展性和實現運行期內綁定,有兩個必要條件:第一是依賴倒置原則;第二是里氏替換原則。這兩個原則缺一不可。
我們知道,在我們的大多數的模式中,我們都有一個共同的接口,然后子類和擴展類都去實現該接口。
下面是一段原始代碼:
if(action.Equals(“add”))
{
//do add action
}
else if(action.Equals(“view”))
{
//do view action
}
else if(action.Equals(“delete”))
{
//do delete action
}
else if(action.Equals(“modify”))
{
//do modify action
}
{
//do add action
}
else if(action.Equals(“view”))
{
//do view action
}
else if(action.Equals(“delete”))
{
//do delete action
}
else if(action.Equals(“modify”))
{
//do modify action
}
我們首先想到的是把這些動作分離出來,就可能寫出如下的代碼:
public class AddAction
{
public void add()
{
//do add action
}
}
public class ViewAction
{
public void view()
{
//do view action
}
}
public class deleteAction
{
public void delete()
{
//do delete action
}
}
public class ModifyAction
{
public void modify()
{
//do modify action
}
}
{
public void add()
{
//do add action
}
}
public class ViewAction
{
public void view()
{
//do view action
}
}
public class deleteAction
{
public void delete()
{
//do delete action
}
}
public class ModifyAction
{
public void modify()
{
//do modify action
}
}
我們可以看到,這樣代碼將各個行為獨立出來,滿足了單一職責原則,但這遠遠不夠,因為它不滿足依賴顛倒原則和里氏替換原則。
下面我們來看看命令模式對該問題的解決方法:
下面我們來看看命令模式對該問題的解決方法:
public interface Action
{
public void doAction();
}
//然后是各個實現:
public class AddAction : Action
{
public void doAction()
{
//do add action
}
}
public class ViewAction : Action
{
public void doAction()
{
//do view action
}
}
public class deleteAction : Action
{
public void doAction()
{
//do delete action
}
}
public class ModifyAction : Action
{
public void doAction()
{
//do modify action
}
}
//這樣,客戶端的調用大概如下:
public void execute(Action action)
{
action.doAction();
}
{
public void doAction();
}
//然后是各個實現:
public class AddAction : Action
{
public void doAction()
{
//do add action
}
}
public class ViewAction : Action
{
public void doAction()
{
//do view action
}
}
public class deleteAction : Action
{
public void doAction()
{
//do delete action
}
}
public class ModifyAction : Action
{
public void doAction()
{
//do modify action
}
}
//這樣,客戶端的調用大概如下:
public void execute(Action action)
{
action.doAction();
}
看,上面的客戶端代碼再也沒有出現過typeof這樣的語句,擴展性良好,也有了運行期內綁定的優點。
三、LSP優點:
1、保證系統或子系統有良好的擴展性。只有子類能夠完全替換父類,才能保證系統或子系統在運行期內識別子類就可以了,因而使得系統或子系統有了良好的擴展性。
2、實現運行期內綁定,即保證了面向對象多態性的順利進行。這節省了大量的代碼重復或冗余。避免了類似instanceof這樣的語句,或者getClass()這樣的語句,這些語句是面向對象所忌諱的。
3、有利于實現契約式編程。契約式編程有利于系統的分析和設計,指我們在分析和設計的時候,定義好系統的接口,然后再編碼的時候實現這些接口即可。在父類里定義好子類需要實現的功能,而子類只要實現這些功能即可。
2、實現運行期內綁定,即保證了面向對象多態性的順利進行。這節省了大量的代碼重復或冗余。避免了類似instanceof這樣的語句,或者getClass()這樣的語句,這些語句是面向對象所忌諱的。
3、有利于實現契約式編程。契約式編程有利于系統的分析和設計,指我們在分析和設計的時候,定義好系統的接口,然后再編碼的時候實現這些接口即可。在父類里定義好子類需要實現的功能,而子類只要實現這些功能即可。
四、使用LSP注意點:
1、此原則和OCP的作用有點類似,其實這些面向對象的基本原則就2條:1:面向接口編程,而不是面向實現;2:用組合而不主張用繼承
2、LSP是保證OCP的重要原則
3、這些基本的原則在實現方法上也有個共同層次,就是使用中間接口層,以此來達到類對象的低偶合,也就是抽象偶合!
3、這些基本的原則在實現方法上也有個共同層次,就是使用中間接口層,以此來達到類對象的低偶合,也就是抽象偶合!
4、派生類的退化函數:派生類的某些函數退化(變得沒有用處),Base的使用者不知道不能調用f,會導致替換違規。在派生類中存在退化函數并不總是表示違反了LSP,但是當存在這種情況時,應該引起注意。
5、從派生類拋出異常:如果在派生類的方法中添加了其基類不會拋出的異常。如果基類的使用者不期望這些異常,那么把他們添加到派生類的方法中就可以能會導致不可替換性。
5、從派生類拋出異常:如果在派生類的方法中添加了其基類不會拋出的異常。如果基類的使用者不期望這些異常,那么把他們添加到派生類的方法中就可以能會導致不可替換性。
文章列表
全站熱搜