定義：

1：如果對每一個類型為 T1的對象 o1，都有類型為 T2 的對象o2，使得以 T1定義的所有程序 P 在所有的對象 o1 都代換成 o2 時，程序 P 的行為沒有發(fā)生變化，那么類型 T2 是類型 T1 的子型。

2：所有引用基類的地方必須能透明地使用其子類的對象。

問題由來：

有一功能P1，由類A完成?，F(xiàn)需要將功能P1進行擴展，擴展后的功能為P，其中P由原有功能P1與新功能P2組成。

新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會導致原有功能P1發(fā)生故障。

解決方案：

當使用繼承時，遵循里氏替換原則。類B繼承類A時，除添加新的方法完成新增功能P2外，盡量不要重寫父類A的方法，也盡量不要重載父類A的方法。

繼承包含這樣一層含義：

父類中凡是已經(jīng)實現(xiàn)好的方法（相對于抽象方法而言），實際上是在設定一系列的規(guī)范和契約，雖然它不強制要求所有的子類必須遵從這些契約，但是如果子類對這些非抽象方法任意修改，就會對整個繼承體系造成破壞。而里氏替換原則就是表達了這一層含義。

繼承作為面向對象三大特性之一，在給程序設計帶來巨大便利的同時，也帶來了弊端。比如使用繼承會給程序帶來侵入性，程序的可移植性降低，增加了對象間的耦合性，如果一個類被其他的類所繼承，則當這個類需要修改時，必須考慮到所有的子類，并且父類修改后，所有涉及到子類的功能都有可能會產(chǎn)生故障

舉例說明繼承的風險，我們需要完成一個兩數(shù)相減的功能，由類A來負責:

class Program
    {
        static void Main(string[] args)
        {
            B b = new B();
            Console.WriteLine("100+20={0}",b.plus(100, 20));
            Console.WriteLine("100-20={0}",b.reduce(100, 20));
            Console.ReadKey();
        }
    }
    
    public class A
    {
        public int plus(int a, int b)
        {
            return a + b;
        }

        public int reduce(int a, int b)
        {
            return a - b;
        }
    }

    public class B : A
    {
        public new int reduce(int a, int b)
        {
            return a - b + 100;
        }
    }

后來, 我們增加了一個新功能, 要求相減在加上100, 由B類完成該功能。

我們發(fā)現(xiàn)原本運行正常的相減功能發(fā)生了錯誤。原因就是類B在給方法起名時無意中重寫了父類的方法，造成所有運行相減功能的代碼全部調用了類B重寫后的方法，

造成原本運行正常的功能出現(xiàn)了錯誤。在本例中，引用基類A完成的功能，換成子類B之后，發(fā)生了異常。

在實際編程中，我們常常會通過重寫父類的方法來完成新的功能，這樣寫起來雖然簡單，但是整個繼承體系的可復用性會比較差，特別是運用多態(tài)比較頻繁時，

程序運行出錯的幾率非常大。如果非要重寫父類的方法，比較通用的做法是：原來的父類和子類都繼承一個更通俗的基類，原有的繼承關系去掉，采用依賴、聚合，組合等關系代替。

PS: 通俗的來講就是：子類可以擴展父類的功能，但不能改變父類原有的功能。

• 子類可以實現(xiàn)父類的抽象方法，但不能覆蓋父類的非抽象方法。
• 子類中可以增加自己特有的方法。
• 當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入?yún)?shù)更寬松。
• 當子類的方法實現(xiàn)父類的抽象方法時，方法的后置條件（即方法的返回值）要比父類更嚴格。

 到此這篇關于C#實現(xiàn)六大設計原則之里氏替換原則的文章就介紹到這了。希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論