c# 如何用組合替代繼承
如果問面向對象的三大特性是什么,多數人都能回答出來:封裝、繼承、多態(tài)。
繼承 作為三大特性之一,近來卻越來越不推薦使用,更有極端的語言,直接語法中就不支持繼承,例如 Go。這又是為什么呢?
為什么不推薦使用繼承?
假設我們要設計一個關于鳥的類。
我們將“鳥類”定義為一個抽象類 AbstractBird
。所有更細分的鳥,比如麻雀、鴿子、烏鴉等,都繼承這個抽象類。
大部分鳥都會飛,那我們可不可以在 AbstractBird
抽象類中,定義一個 Fly()
方法呢?
答案是否定的。盡管大部分鳥都會飛,但也有特例,比如鴕鳥就不會飛。鴕鳥繼承具有 Fly()
方法的父類,那鴕鳥就具有“飛”這樣的行為,這顯然不符合我們對現(xiàn)實世界中事物的認識。
解決方案一
在鴕鳥這個子類中重寫 Fly()
方法,讓它拋出異常。
public class AbstractBird { public virtual void Fly() { Console.WriteLine("I'm flying."); } } //鴕鳥 public class Ostrich : AbstractBird { public override void Fly() { throw new NotImplementedException("I can't fly."); } }
這種設計思路雖然可以解決問題,但不夠優(yōu)美。因為除了鴕鳥之外,不會飛的鳥還有很多,比如企鵝。對于這些不會飛的鳥來說,我們都需要重寫 Fly()
方法,拋出異常。
這違背了迪米特法則(也叫最少知識原則),暴露不該暴露的接口給外部,增加了類使用過程中被誤用的概率。
解決方案二
通過 AbstractBird
類派生出兩個更加細分的抽象類:會飛的鳥類 AbstractFlyableBird
和不會飛的鳥類 AbstractUnFlyableBird
,讓麻雀、烏鴉這些會飛的鳥都繼承 AbstractFlyableBird
,讓鴕鳥、企鵝這些不會飛的鳥,都繼承 AbstractUnFlyableBird
類。
此時,繼承關系變成了三層,還行得通。
如果要再添加一個游泳 Swim()
的方法,那情況就復雜了,要分為四中情況:
- 會飛會游泳
- 會飛不會游泳
- 不會飛會游泳
- 不會飛不會游泳
如果再有其他行為加入,抽象類的數量就會幾何級數增長。
我們要搞清楚某個類具有哪些方法、屬性,必須閱讀父類的代碼、父類的父類的代碼……一直追溯到最頂層父類的代碼。
使用組合
針對“會飛”這樣一個行為特性,我們可以定義一個 Flyable
接口,只讓會飛的鳥去實現(xiàn)這個接口。針對會游泳,定義一個 Swimable
接口,會叫定義一個 Tweetable
接口。
public interface Flyable { void Fly(); } public interface Swimable { void Swim(); } public interface Tweetable { void Tweet(); } //麻雀 public class Sparrow : Flyable, Tweetable { public void Fly() => Console.WriteLine("I am flying."); public void Tweet() => Console.WriteLine("!@#$%^&*……"); } //企鵝 public class Penguin : Swimable, Tweetable { public void Swim() => Console.WriteLine("I am swimming."); public void Tweet() => Console.WriteLine("!@#$%^&*……"); }
麻雀和企鵝都會叫,Tweet
實現(xiàn)了兩遍,這是壞味道。我們可以用組合來消除這個壞味道。
public interface Flyable { void Fly(); } public interface Swimable { void Swim(); } public interface Tweetable { void Tweet(); } public class FlyAbility : Flyable { public void Fly() => Console.WriteLine("I am flying."); } public class SwimAbility : Swimable { public void Swim() => Console.WriteLine("I am swimming."); } public class TweetAbility : Tweetable { public void Tweet() => Console.WriteLine("!@#$%^&*……"); } //麻雀 public class Sparrow : Flyable, Tweetable { FlyAbility flyAbility = new FlyAbility(); TweetAbility tweetAbility = new TweetAbility(); public void Fly() => flyAbility.Fly(); public void Tweet() => tweetAbility.Tweet(); } //企鵝 public class Penguin : Swimable, Tweetable { SwimAbility swimAbility = new SwimAbility(); TweetAbility tweetAbility = new TweetAbility(); public void Swim() => swimAbility.Swim(); public void Tweet() => tweetAbility.Tweet(); }
雖然現(xiàn)在主流的思想都是多用組合少用繼承,但是從上面的例子可以看出,繼承改寫成組合意味著要做更細粒度的類的拆分,要定義更多的類和接口。類和接口的增多也就或多或少地增加代碼的復雜程度和維護成本。所以,在實際的項目開發(fā)中,我們還是要根據具體的情況,來具體選擇該用繼承還是組合。
以上就是c# 如何用組合替代繼承的詳細內容,更多關于c# 組合替代繼承的資料請關注腳本之家其它相關文章!
相關文章
C#中的multipart/form-data提交文件和參數
這篇文章主要介紹了C#中的multipart/form-data提交文件和參數,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-06-06解析C#設計模式編程中外觀模式Facade Pattern的應用
這篇文章主要介紹了C#設計模式編程中外觀模式Facade Pattern的應用,外觀模式中分為門面(Facade)和子系統(tǒng)(subsystem)兩個角色來進行實現(xiàn),需要的朋友可以參考下2016-02-02深入多線程之:Reader與Write Locks(讀寫鎖)的使用詳解
本篇文章是對Reader與Write Locks(讀寫鎖)的使用進行了詳細的分析介紹,需要的朋友參考下2013-05-05