爲什麼Microsoft爲自己的類使用擴展方法？

爲什麼Microsoft使用它創建的類的擴展方法;而不是僅僅將方法添加到類中，或者創建子類？爲什麼Microsoft爲自己的類使用擴展方法？

來源

2011-08-05 Josh Russo

回答這個問題通常會很困難。請舉一些具體的例子。 –

我在下面提到過，但'RouteCollection'集合的'IgnoreRoute（）'方法 –

微軟這樣做有很多原因。最大的兩個是：

擴展方法適用於接口，而不僅僅是類。如果微軟簡單地將Linq方法直接添加到IEnumerable中，它將需要該接口的每個具體實現來實現這些方法。通過使它們成爲擴展方法，根據現有的IEnumerable編寫的行爲，每個IEnumerable類都會自動獲取它們。
對於3.0和3.5框架，核心System.dll是2.0庫。 3.0版本中新增的所有內容都添加到了System.Core或其他相關庫中。例如，在3.5中存在但不在2.0中的列表<>類中獲取新方法的唯一方法是在3.5庫中使用擴展方法。

來源

2011-08-05 14:18:03

也eric lippert [已經對此進行了博客]（http://blogs.msdn.com/b/ericlippert/archive/2011/06/30/following-the-pattern.aspx） – bottlenecked

-1

我的兩分錢：

因爲只有在.NET框架的後續版本中加入擴展方法，他們已經有.NET框架1，1.1，2.0和更新，然後在某個時候，他們添加的擴展方法，使他們已經使用它們來豐富現有類的功能集。

來源

2011-08-05 14:15:46

爲什麼這是一個原因？讓我們看看Linq擴展方法。爲了使用linq方法，你應該使用.Net framework 3.5或更高版本，對嗎？你不能繼續使用.Net 1,1.1或2.0，並且無論如何都要使用linq方法。所以你必須移動到.net 3.5，即使linq被實現在類（如列表等），它仍然可以完美地在客戶端代碼中工作，如：mylist.Where（）。Select（）... –

IgnoreRoute()上RouteCollection是一個擴展方法，因爲它旨在與MVC框架，而不是一個核心的ASP.NET應用程序中使用。我的猜測是他們不想用非MVC應用程序不需要的方法污染RouteCollection類，同時仍然允許MVC應用程序使用該類。

我不確定這種方法必然有意義（因爲，例如，他們可能剛剛創建了一個子類）。由於可能會使用擴展方法的更普遍的原因，其他人已經很好地回答了。

來源

2011-08-05 14:22:21 dlev

MVC是另一種類似於.NET 2 - > 3的情況增強。大多數基類與非MVC ASP.NET相同，但MVC框架希望這些相同的類能夠更好地利用MVC功能。派生一個子類會在技術上起作用，但是在邏輯上是「不正確的」 - 實際上並不是兩個RouteCollection類;有一個類，如果你升級到MVC框架，它會變得更聰明。 –

這是Non-Virtual Interface模式的示例（類似於Template Method）。這是一種用於具有多個（實現）繼承的語言中的模式，在C＃中執行此操作的方式是使用擴展方法。

其基本思想是你只有非虛擬和純虛擬（抽象）方法。接口的實現者（或類/繼承者的繼承者，具有多重繼承的語言）實現了一個小方法或一組方法（在本例中爲GetEnumerator），並返回一組依賴於一個抽象方法（如Select，Where，Aggregate等）

正如Michael Edenfield在他的回答中所說的，如果我們想要實現這種模式，並且我們希望IEnumerable成爲一個接口，我們需要使用擴展方法。並且將IEnumerable變成抽象類會很糟糕，因爲它應該是一個非常低成本的基本接口，應該放在幾乎任何集合上 - 實現IEnumerable不應該需要重新考慮類層次結構，它應該是「免費的」。

來源

2012-05-23 18:23:32 lvilnis

我認爲主要原因是擴展這種方法非常容易。例如，如果您使用Linq擴展方法，您可以輕鬆地編寫自己的一組擴展方法（可能是foreach或某些特定的篩選器），這些方法將與Microsoft方法一起工作：mylist.Where（...）。MyFilter（...）。選擇（...）

來源

2016-01-29 07:41:15

爲什麼Microsoft爲自己的類使用擴展方法？

回答

相關問題