一、LSP簡(jiǎn)介（LSP--Liskov Substitution Principle）：
定義：如果對(duì)于類型S的每一個(gè)對(duì)象o1，都有一個(gè)類型T的對(duì)象o2，使對(duì)于任意用類型T定義的程序P，將o2替換為o1，P的行為保持不變，則稱S為T的一個(gè)子類型。
子類型必須能夠替換它的基類型。LSP又稱里氏替換原則。
對(duì)于這個(gè)原則，通俗一些的理解就是，父類的方法都要在子類中實(shí)現(xiàn)或者重寫。
二、舉例說(shuō)明：
對(duì)于依賴倒置原則，說(shuō)的是父類不能依賴子類，它們都要依賴抽象類。這種依賴是我們實(shí)現(xiàn)代碼擴(kuò)展和運(yùn)行期內(nèi)綁定（多態(tài)）的基礎(chǔ)。因?yàn)橐坏╊惖氖褂谜咭蕾嚹硞€(gè)具體的類，那么對(duì)該依賴的擴(kuò)展就無(wú)從談起；而依賴某個(gè)抽象類，則只要實(shí)現(xiàn)了該抽象類的子類，都可以被類的使用者使用，從而實(shí)現(xiàn)了系統(tǒng)的擴(kuò)展。phpma開(kāi)源
但是，光有依賴倒置原則，并不一定就使我們的代碼真正具有良好的擴(kuò)展性和運(yùn)行期內(nèi)綁定。請(qǐng)看下面的代碼：
public class Animal
{
private string name;
public Animal(string name)
{
this.name = name;
}
public void Description()
{
Console.WriteLine("This is a(an) " + name);
}
}
//下面是它的子類貓類：phpma開(kāi)源
public class Cat : Animal
{
public Cat(string name)
{
}
public void Mew()
{
Console.WriteLine("The cat is saying like 'mew'");
}
}
//下面是它的子類狗類：phpma開(kāi)源
public class Dog : Animal
{
public Dog(string name)
{
}
public void Bark()
{
Console.WriteLine("The dog is saying like 'bark'");
}
}
//最后，我們來(lái)看客戶端的調(diào)用：
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();
}
}
通過(guò)上面的代碼，我們可以看到雖然客戶端的依賴是對(duì)抽象的依賴，但依然這個(gè)設(shè)計(jì)的擴(kuò)展性不好，運(yùn)行期綁定沒(méi)有實(shí)現(xiàn)。phpma開(kāi)源
是什么原因呢？其實(shí)就是因?yàn)椴粷M足里氏替換原則，子類如Cat有Mew()方法父類根本沒(méi)有，Dog類有Bark()方法父類也沒(méi)有，兩個(gè)子類都不能替換父類。這樣導(dǎo)致了系統(tǒng)的擴(kuò)展性不好和沒(méi)有實(shí)現(xiàn)運(yùn)行期內(nèi)綁定。
現(xiàn)在看來(lái)，一個(gè)系統(tǒng)或子系統(tǒng)要擁有良好的擴(kuò)展性和實(shí)現(xiàn)運(yùn)行期內(nèi)綁定，有兩個(gè)必要條件：第一是依賴倒置原則；第二是里氏替換原則。這兩個(gè)原則缺一不可。
我們知道，在我們的大多數(shù)的模式中，我們都有一個(gè)共同的接口，然后子類和擴(kuò)展類都去實(shí)現(xiàn)該接口。
下面是一段原始代碼：
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
}
我們首先想到的是把這些動(dòng)作分離出來(lái)，就可能寫出如下的代碼：phpma開(kāi)源
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
}
}
我們可以看到，這樣代碼將各個(gè)行為獨(dú)立出來(lái)，滿足了單一職責(zé)原則，但這遠(yuǎn)遠(yuǎn)不夠，因?yàn)樗粷M足依賴顛倒原則和里氏替換原則。phpma開(kāi)源
下面我們來(lái)看看命令模式對(duì)該問(wèn)題的解決方法：
public interface Action
{
public void doAction();
}
//然后是各個(gè)實(shí)現(xiàn)：
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
}
}
//這樣，客戶端的調(diào)用大概如下：
public void execute(Action action)
{
action.doAction();
}
看，上面的客戶端代碼再也沒(méi)有出現(xiàn)過(guò)typeof這樣的語(yǔ)句，擴(kuò)展性良好，也有了運(yùn)行期內(nèi)綁定的優(yōu)點(diǎn)。
三、LSP優(yōu)點(diǎn)：
1、保證系統(tǒng)或子系統(tǒng)有良好的擴(kuò)展性。只有子類能夠完全替換父類，才能保證系統(tǒng)或子系統(tǒng)在運(yùn)行期內(nèi)識(shí)別子類就可以了，因而使得系統(tǒng)或子系統(tǒng)有了良好的擴(kuò)展性。
2、實(shí)現(xiàn)運(yùn)行期內(nèi)綁定，即保證了面向?qū)ο蠖鄳B(tài)性的順利進(jìn)行。這節(jié)省了大量的代碼重復(fù)或冗余。避免了類似instanceof這樣的語(yǔ)句，或者getClass()這樣的語(yǔ)句，這些語(yǔ)句是面向?qū)ο笏芍M的。
3、有利于實(shí)現(xiàn)契約式編程。契約式編程有利于系統(tǒng)的分析和設(shè)計(jì)，指我們?cè)诜治龊驮O(shè)計(jì)的時(shí)候，定義好系統(tǒng)的接口，然后再編碼的時(shí)候?qū)崿F(xiàn)這些接口即可。在父類里定義好子類需要實(shí)現(xiàn)的功能，而子類只要實(shí)現(xiàn)這些功能即可。
四、使用LSP注意點(diǎn)：
1、此原則和OCP的作用有點(diǎn)類似，其實(shí)這些面向?qū)ο蟮幕驹瓌t就2條：1：面向接口編程，而不是面向?qū)崿F(xiàn)；2：用組合而不主張用繼承
2、LSP是保證OCP的重要原則
3、這些基本的原則在實(shí)現(xiàn)方法上也有個(gè)共同層次，就是使用中間接口層，以此來(lái)達(dá)到類對(duì)象的低偶合，也就是抽象偶合！
4、派生類的退化函數(shù)：派生類的某些函數(shù)退化（變得沒(méi)有用處），Base的使用者不知道不能調(diào)用f，會(huì)導(dǎo)致替換違規(guī)。在派生類中存在退化函數(shù)并不總是表示違反了LSP，但是當(dāng)存在這種情況時(shí)，應(yīng)該引起注意。
5、從派生類拋出異常：如果在派生類的方法中添加了其基類不會(huì)拋出的異常。如果基類的使用者不期望這些異常，那么把他們添加到派生類的方法中就可以能會(huì)導(dǎo)致不可替換性。