C#中完成多繼續的辦法。本站提示廣大學習愛好者：（C#中完成多繼續的辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是C#中完成多繼續的辦法正文
近日看到了一個貼子，就是在C#說話中，若何完成多繼續的成績。信任浏覽c#不多的人（像我如許的菜鳥），一看就認為很好笑，c#確定是不克不及完成多繼續的啊。都曉得在c++中由於完成多繼續會有許多的歧義成績，所以在c#中就把多繼續給撤消了，而用接口來完成！然則想一想，假如是初學者確定不會不會問如許的成績。確定是個高手，然後就開端上彀查材料！然後發明真的可以完成！
說起多繼續，起首年夜家可以想一想這個成績：你曉得在C#中怎樣完成多繼續嗎？
主流的謎底不過2種。
謎底一：用接口啊，一個類可以繼續自多個接口的。
謎底二：C#不支撐多繼續，C++才支撐多繼續，多繼續會讓代碼變得很亂，是以微軟在設計C#的時刻廢棄了多繼續。
可以或許曉得謎底二的人明顯懂的更多，我也在很長一段時光內信任C#不支撐多繼續，直到2013年5月的一個項目中，我有時的發明本身的代碼就完整完成了真正意義的多繼續。
先說說甚麼是真正意義的多繼續。真實的多繼續應當是像C++那樣的，而不是說像在C#外面一個類繼續了多個接口就叫多繼續。在C#中，假如一個類完成了多個接口，那末要為每一個接口寫完成，假如接口被多個類繼續，那末就會有反復的代碼，這明顯是沒法接收的。
但是C++那樣的多繼續也確確切實給編碼帶來了很年夜的費事，我也信任微軟真的是由於認識到了多繼續的不公道的地方才在C#中拋棄了這個特征。而我在C#中完成的多繼續，第一是真實的多繼續，第二代碼寫的很公道。
請看案例
假設你有一個類叫山君，還有一個類叫蒼蠅。如今你想新創一個超等山君類，一種可以飛的山君。在C++中，你可以界說一種超等山君類，讓其繼續自山君和蒼蠅，如許這類山君便可以飛了。但是，成績湧現了，這類超等山君因為同時也繼續自蒼蠅，而蒼蠅上面有個辦法叫吃，參數類型是屎。吃屎的這個辦法明顯跟我們的超等山君太不搭了。
固然這個例子有些誇大，然則許多C++法式員真的就是如許在設計代碼。因為子類繼續了多個父類，而多個父類確定有些成員跟這個子類不搭調，因而子類的挪用者就很難熬痛苦了。好比下面這個例子，當挪用者拿到超等山君的一個實例時，發明超等山君上面怎樣會有個吃屎的辦法呢！！！真的是要笑逝世人了。
C++要如許許可多繼續就必定會形成這個成績。C#法式員就相對不會寫出如許幽默的代碼。關於C#法式員，確定是要把這個飛的辦法提成接口的，然後讓蒼蠅類和超等山君類都繼續自這個接口。如許，蒼蠅會飛，超等山君也會飛。是否是完善處理這個成績？
成績看上去處理了，然則，假設我跟你說蒼蠅飛的辦法跟超等山君飛的辦法須要如出一轍：起首張開雙翅，身材前傾，拍打雙翅，騰飛，持續拍打。我們確定不克不及把統一份代碼copy一份吧，那是屬於入門級法式員干的事，我們如今曾經沒資歷干那事了。那怎樣辦呢？簡略疾速的做法是應用靜態辦法，好比FlyHelper.Fly(...)。
靜態辦法處理了代碼重用的成績，但寫起來一直認為哪裡纰謬勁。我的超等山君類和蒼蠅都明明繼續了飛了啊，為何還要如許挪用一句靜態辦法。假如今後哪天我想讓我的豬也能飛起來，那豈不是還要來挪用這個靜態辦法。
究竟如何能力在C#中完成像C++那樣優雅的繼續呢？
謎底揭曉
謎底其實很簡略，那就是給IFly接口寫擴大辦法。
起首請看這個空接口的界說，及其擴大辦法（留意泛型限制）：
namespace Interface
{
//飛的接口
public interface IFly
{
}
//擴大辦法
public static class ExtendFly
{
public static void StartFly<T>(this T example) where T : IFly
{
Console.WriteLine("預備");
Console.WriteLine("張開雙翅");
Console.WriteLine("騰飛");
Console.WriteLine("我飛，我飛，我飛飛飛");
}
}
}
再看山君和蒼蠅的完成：
namespace Interface
{
//蒼蠅類完成飛的接口
public class flies : IFly
{
public void fly()
{
//挪用接口中飛的辦法
this.StartFly();
}
}
}
namespace Interface
{
//山君類
public class Tiger
{
public void introduce()
{
Console.WriteLine("I am a tiger");
}
}
}
再看超等山君的完成：
namespace Interface
{
//超等山君類，繼續了山君類，並完成了飛的辦法
public class SuperTiger : Tiger, IFly
{
public override void introduce()
{
Console.WriteLine("年夜家好，我是超等山君哦！");
}
public void TigerFly()
{
//挪用接口中飛的辦法
this.StartFly();
}
}
}
怎樣樣，你看明確了嗎？這個完成是否是很簡略呢？利益是否是年夜年夜的有呢？
當今後哪天老板讓你完成一個會飛的超等豬的話，你只須要讓你的超等豬繼續“I飛”接口就好了。當哪天老板又不想要這個超等豬飛的話，你也只須要將這個接口繼續刪失落罷了。假如你正在開辟一個植物王國法式，你可以將飛的功效注入就任何一種植物身上。想一想是否是都認為很爽。
總結
最初，再讓我們回想一下之前用C++寫的超等山君吃屎的失常例子。這現實上不是C++的錯，而是法式員用錯了多繼續。固然在語法上C++沒無限制法式員怎樣去寫多繼續，然則從下面的例子剖析來看，我們很容得出如許一個結論：
當須要寫多繼續的時刻，被繼續的父類只能是一個功效，而不該是一個完全的類。
假如依照這個思緒，那末明天的這個例子在C++中便可以如許寫，起首提一個Flyable的類出來，然後讓超等山君和蒼蠅都繼續這個Flyable。
在C#中，固然完成多繼續的代碼略微繞了個彎，然則多繼續帶來的利益長短常顯著的：對分歧的類完成注入式的功效，讓你的代碼更相符面向對象的思惟。
