¿Por qué Microsoft usa métodos de extensión para las clases que crea; en lugar de simplemente agregar los métodos a las clases o crear clases secundarias?¿Por qué usa Microsoft los métodos de extensión para sus propias clases?
Existen varias razones por las que Microsoft hizo esto. Los dos más grandes son:
Los métodos de extensión se aplican a las interfaces, no solo a las clases. Si Microsoft hubiera agregado simplemente los métodos Linq directamente a IEnumerable, habría requerido que cada implementación concreta de esa interfaz implemente esos métodos también. Al convertirlos en métodos de extensión, escritos en términos del comportamiento IEnumerable <> existente, cada clase IEnumerable <> los obtiene automáticamente.
Para los Frameworks 3.0 y 3.5, el núcleo System.dll es la biblioteca 2.0. Todo lo nuevo en 3.0 ad 3.5 fue agregado a eso, en System.Core u otras bibliotecas relacionadas. La única forma de obtener, por ejemplo, un nuevo método en la clase List <> que existe en 3.5 pero no en 2.0 es hacer que un método de extensión esté disponible en una biblioteca 3.5.
también eric lippert [ ha blogueado sobre esto] (http://blogs.msdn.com/b/ericlippert/archive/2011/06/30/following-the-pattern.aspx) – bottlenecked
Mis dos centavos:
porque los métodos de extensión se añadieron sólo en versiones posteriores del marco .NET, que ya tenían .NET Framework 1, 1.1, 2.0 y más reciente a continuación, en algún momento se añaden los métodos de extensión de modo que los he usado para enriquecer el conjunto de características sobre las clases existentes.
¿Por qué este es un motivo? Echemos un vistazo a los métodos de extensión de Linq. Para utilizar los métodos de linq, debe usar .Net framework 3.5 o posterior, ¿verdad? No puede seguir utilizando .Net 1, 1.1 o 2.0 y utilizar los métodos linq de todos modos. Por lo tanto, debe pasar a .Net 3.5 e incluso si se implementó linq en clases (como List, etc.) aún podría funcionar perfectamente en el código del cliente como: mylist.Where(). Select() ... –
IgnoreRoute() en RouteCollection es un método de extensión, ya que está diseñado para su uso con el marco de MVC, en lugar de una aplicación de núcleo ASP.NET. Supongo que no querían contaminar la clase RouteCollection con métodos que las aplicaciones que no son MVC no necesitarían, al tiempo que permiten que las aplicaciones MVC hagan uso de la clase.
No estoy seguro de que este enfoque necesariamente tenga sentido (ya que, por ejemplo, podrían haber creado una clase para niños); por razones más generales, los métodos de extensión pueden ser utilizados, otros han respondido bien.
MVC es otro caso similar al .NET 2 -> 3 mejoras La mayoría de las clases base son idénticas a ASP.NET que no son MVC, pero MVC Framework quiere que esas mismas clases "funcionen mejor" con las características de MVC. Derivar una clase infantil funcionaría técnicamente, pero sería una especie de "filosóficamente incorrecto": en realidad, no hay dos clases de RouteCollection; hay una clase, y si "actualizas" a MVC Framework, se vuelve más inteligente. –
Este es un ejemplo del patrón Non-Virtual Interface (similar a Template Method). Este es un patrón utilizado en idiomas con herencia múltiple (implementación), y la forma de hacerlo en C# es usar métodos de extensión.
La idea básica es que solo tiene métodos no virtuales y puros virtuales (abstractos). El implementador de la interfaz (o el heredero de la clase/mixin, en idiomas con herencia múltiple), implementa un pequeño método o conjunto de métodos (en este caso, GetEnumerator), y a cambio obtiene una gran cantidad de métodos que dependen de eso un método abstracto (como Select, Where, Aggregate, etc.)
Como dijo Michael Edenfield en su respuesta, si queremos implementar este patrón y queremos que IEnumerable sea una interfaz, debemos usar los métodos de extensión. Y convertir IEnumerable en una clase abstracta sería malo porque se supone que es una interfaz básica de muy bajo costo que debería colocarse prácticamente en cualquier colección. Implementar IEnumerable no debería requerir replantear una jerarquía de clases, debería ser casi "gratis". ".
Creo que la razón principal es que es muy fácil extender dichos métodos. Por ejemplo, si utiliza los métodos de extensión Linq, puede escribir fácilmente su propio conjunto de métodos de extensión (quizás foreach o algún filtro específico) que funcionarán mejor con los métodos de microsoft: mylist.Where (...). MyFilter (...). Seleccionar(...)
Responder a esto en general sería muy difícil. Por favor, da algunos ejemplos específicos. –
Mencioné esto a continuación pero, el método 'IgnoreRoute()' para la colección 'RouteCollection' –