一、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);
    }
}
//下面是它的子類貓類：
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 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();
    }
}
 

通過上面的程式碼，我們可以看到雖然客戶端的依賴是對抽象的依賴，但依然這個設計的擴充套件性不好，執行期繫結沒有實現。 是什麼原因呢？其實就是因為不滿足里氏替換原則，子類如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
}
 

我們首先想到的是把這些動作分離出來，就可能寫出如下的程式碼：

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 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();
}

看，上面的客戶端程式碼再也沒有出現過typeof這樣的語句，擴充套件性良好，也有了執行期內繫結的優點。

三、LSP優點：

1、保證系統或子系統有良好的擴充套件性。只有子類能夠完全替換父類，才能保證系統或子系統在執行期內識別子類就可以了，因而使得系統或子系統有了良好的擴充套件性。 2、實現執行期內繫結，即保證了面向物件多型性的順利進行。這節省了大量的程式碼重複或冗餘。避免了類似instanceof這樣的語句，或者getClass()這樣的語句，這些語句是面向物件所忌諱的。 3、有利於實現契約式程式設計。契約式程式設計有利於系統的分析和設計，指我們在分析和設計的時候，定義好系統的介面，然後再編碼的時候實現這些介面即可。在父類裡定義好子類需要實現的功能，而子類只要實現這些功能即可。

四、使用LSP注意點：

1、此原則和OCP的作用有點類似，其實這些面向物件的基本原則就2條：1：面向介面程式設計，而不是面向實現；2：用組合而不主張用繼承

2、LSP是保證OCP的重要原則 3、這些基本的原則在實現方法上也有個共同層次，就是使用中間介面層，以此來達到類物件的低偶合，也就是抽象偶合！

4、派生類的退化函式：派生類的某些函式退化（變得沒有用處），Base的使用者不知道不能呼叫f，會導致替換違規。在派生類中存在退化函式並不總是表示違反了LSP，但是當存在這種情況時，應該引起注意。  5、從派生類丟擲異常：如果在派生類的方法中添加了其基類不會丟擲的異常。如果基類的使用者不期望這些異常，那麼把他們新增到派生類的方法中就可以能會導致不可替換性。