.net - programacion - Convención de nomenclatura de C#para métodos de extensión para interfaz

nomenclatura de nombres de variables en java

Question

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

Edición: no hay una clase Thing que implemente IThing , en respuesta a algunos de los comentarios.

Answer 1

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.

Agregar un prefijo I para el caso del método de extensión rompe las suposiciones y las pautas establecidas.

También hay prioridad para esto en la Biblioteca de clases base . La mayoría de los métodos de extensión disponibles para IEnumerable están contenidos en el tipo Enumerable .

Answer 2

He adoptado un enfoque ligeramente diferente, y en lugar de sufijo con Extension invirtió la estrategia de nomenclatura para prefijar la clase que contiene los métodos de extensión con Extend ; Mi razonamiento es el siguiente:

• Como se señaló en la respuesta de Reed Copsey , muy ( muy ) rara vez el código del cliente hará referencia a la clase contenedora directamente, ya que el mero punto de los 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 clases debería tener un impacto insignificante.
• Las clases deben ser static , y por lo tanto nunca las instanciará. Por lo tanto, nunca terminará con la rareza semántica de la new ExtendThing() en lo que respecta a la denominación.
• Todas sus clases Extend* se agrupan visualmente con ordenación de archivos alfa.
• Y con respecto a su pregunta específicamente, no hay ninguna confusión de prefijo de nombre de interfaz; puede tener ExtendThing y ExtendIThing y (IMO) su intención y objetivo son claros.

namespace MyCompany.Extensions
{
    public static class ExtendObject { }

    public static class ExtendDateTime { }

    public static class ExtendIEnumerable { }
}

Answer 3

La mayoría de los programadores que conozco ponen 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 que modifiquen las extensiones , y luego ponen esta clase en el espacio de nombres de su programa principal .

Su razonamiento 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 no es un acuerdo universal sobre esto, por supuesto. Vea aquí: ¿Cómo administra los espacios de nombres de sus métodos de extensión?

Answer 4

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

Answer 5

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

Answer 6

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 se IThing extensiones para cualquier IThing hace que IThingExtensions sea ​​lo más claro. Si tiene una clase Thing , llamar a esta ThingExtensions puede parecer ambiguo (¿está extendiendo 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 la IThing . Para ejemplos, vea Enumerable (extendiendo IEnumerable ) y Queryable (extendiendo IQueryable ). Esta también sería una muy buena opción.