2010-04-23 15 views
21

Normalmente llamo a mis interfaces C# como IThing. Estoy creando una clase de método de extensión para IThing, pero no sé cómo nombrarla. Por un lado, llamarlo ThingExtensions parece implicar que es una clase de extensión para alguna clase Thing en lugar de la interfaz IThing. También hace que la clase de extensión se ordene desde la interfaz que extiende, cuando se visualizan los archivos alfabéticamente. Por otro lado, nombrarlo IThingExtensions hace que parezca una interfaz en sí misma, en lugar de una clase de extensión para una interfaz. ¿Qué sugieres?Convención de nomenclatura de C# para métodos de extensión para la interfaz

Editar: no es una clase que implementa ThingIThing, en respuesta a algunos de los comentarios.

+0

se tienen que migrar a [programadores] (http://programmers.stackexchange.com), porque no se trata de un problema de codificación, sino que más bien se refiere a la práctica del desarrollo (cómo métodos de extensión de nombre). –

+0

Vine aquí en busca de una respuesta ganadora clara y en realidad no me sorprendió no encontrar una ... Me vi obligado a votar tanto su pregunta como ** las respuestas de ** Reed y Jared. –

Respuesta

20

Definitivamente prefiero el nombre ThingExtensions sobre IThingExtensions. La razón es que para la mayoría de los programadores un prefijo I en un tipo implica que es una interfaz. Este es un patrón muy común y parte de las Pautas de diseño de .Net.

Al agregar un prefijo I para el caso del método de extensión, se eliminan las suposiciones y las pautas establecidas.

También hay prioridad para esto en the Base Class Library. La mayoría de los métodos de extensión disponibles para IEnumerable están contenidos en el tipo Enumerable.

+3

Me imagino que hay una clase llamada 'Thing' que implementa' IThing', por lo tanto, sería confuso si se llamara 'ThingExtensions' pero funcionara en' IThing''s. Pero, @Sarah Vessels no especifica esto ... –

+1

BCL = Bibliotecas de clase base –

+0

@klausbyskov: en realidad no hay una clase 'Thing' que implemente' IThing'. Actualizaré mi pregunta. –

0

Preferiría ponerlo en una carpeta (y espacio de nombres) llamada Extensions y nombrarla IThingExtensions.

3

mayoría de los programadores que saben poner todos sus métodos de extensión para una aplicación en una clase estática llamada ExtensionMethods (o algo así), independientemente de la clase de las extensiones modifican, y luego ponen esta clase en su principal espacio de nombres de programa.

Su razón de ser es que si coloca el método de extensión en el mismo espacio de nombres que la clase que modifica, puede confundir el método con los métodos que forman parte de la clase real, lo que sugiere que el método de extensión es parte de la funcionalidad original cuando no lo es

Su acuerdo no es universal en esto, por supuesto. Vea aquí: How do you manage the namespaces of your extension methods?

13

Yo, personalmente, usaría IThingExtensions.

Desde el punto de vista de la usabilidad, el usuario final nunca ve esta clase, solo incluye su espacio de nombres. Si el espacio de nombres es el mismo que IThing, entonces no importa, ya lo tendrán.

Dicho esto, creo que el hecho de que estas extensiones sean para cualquier IThing hace que IThingExtensions sea el más claro. Si tiene una clase Thing, llamar a este ThingExtensions puede parecer ambiguo (¿está ampliando la interfaz o la implementación en sí?).

Dicho esto, el marco utiliza un enfoque muy diferente. El enfoque del marco es usar una clase llamada Thing para extender IThing. Por ejemplo, vea Enumerable (extensión IEnumerable) y Queryable (extensión IQueryable). Esta también sería una muy buena opción.

+1

Sigo el enfoque del marco en mis proyectos. Aún no ha tenido ningún efecto secundario desagradable. –

+0

@Programación: Funciona muy bien, siempre que no tenga una implementación predeterminada para 'IThing' que se llame' Thing' ... –

+1

Todavía no me gusta este enfoque porque infringe las pautas de diseño para el nombre de tipo. En particular, solo los nombres de tipo de prefijo con una I si es realmente una interfaz. http://msdn.microsoft.com/en-us/library/ms229040.aspx – JaredPar

0

No conozco ninguna convención estándar para esto. Yo usaría ThingExtensions o ThingInterfaceExtensions. Me mantendría alejado de IThingExtensions como también sugirió.

0

que he tomado un enfoque ligeramente diferente, y en lugar de sufijo con Extension invertido la estrategia de nombres para prefijo la clase que contiene los métodos de extensión con Extend; Mi razonamiento es el siguiente:

  • Como se señaló en Reed Copsey's answer, muy (muy ) rara vez se hará referencia a código de cliente de la clase que contiene directamente como el punto de métodos de extensión es emular los métodos de referencia. No verán las clases, por lo que su elección de convención de nomenclatura de clase debería tener un impacto insignificante.
  • Las clases deben ser static, por lo que nunca las creará. Por lo tanto, nunca se termina con la rareza semántica de new ExtendThing() en lo que se refiere a nombres.
  • Todas sus clases Extend* se agrupan visualmente con la clasificación de archivos alfa.
  • Y con respecto a su pregunta específicamente, no hay ninguna interfaz que nombra confusión de prefijo; puede tener ExtendThingyExtendIThing y (IMO) su intención y objetivo es claro.

namespace MyCompany.Extensions 
{ 
    public static class ExtendObject { } 

    public static class ExtendDateTime { } 

    public static class ExtendIEnumerable { } 
} 
Cuestiones relacionadas