Convenciones de nomenclatura para clases abstractas

101

Recuerdo claramente que, en un momento, la directriz impulsada por Microsoft era agregar el sufijo "Base" a una clase abstracta para obviar el hecho de que era abstracta. Por lo tanto, tenemos clases como System.Web.Hosting.VirtualFileBase, System.Configuration.ConfigurationValidatorBase, System.Windows.Forms.ButtonBase, y, por supuesto, System.Collections.CollectionBase.

Pero he notado que, últimamente, muchas clases abstractas del Framework no parecen seguir esta convención. Por ejemplo, las siguientes clases son todas abstractas pero no siguen esta convención:

System.DirectoryServices.ActiveDirectory.DirectoryServer
System.Configuration.ConfigurationElement
System.Drawing.Brush
System.Windows.Forms.CommonDialog

Y eso es justo lo que pude conseguir en unos segundos. Así que busqué lo que decía la documentación oficial para asegurarme de que no estaba loco. Encontré los nombres de clases, estructuras e interfaces en MSDN en Design Guidelines for Developing Class Libraries . Curiosamente, no puedo encontrar ninguna mención de la directriz para agregar "Base" al final del nombre de una clase abstracta. Y las pautas ya no están disponibles para la versión 1.1 del Framework.

Entonces, ¿lo estoy perdiendo? ¿Alguna vez existió esta directriz? ¿Ha sido abandonado sin una palabra? ¿He estado creando nombres de clases largos yo solo durante los últimos dos años por nada?

Que alguien me tire un hueso aquí.

Actualización no estoy loco. La directriz existía. Krzysztof Cwalina se queja de ello en 2005.

.net naming-conventions abstract-class

— Mike Hofer
fuente

Si lee ese artículo, Krzysztof simplemente se queja de recibir "un conjunto de recomendaciones", no necesariamente que esas recomendaciones fueran oficiales de Microsoft. Recuerdo haber leído las pautas de la EM y haber visto recomendaciones en contra de esto.

— John Rudy

1

Lo leí, aunque es la primera vez que recuerdo haber visto ese artículo en particular. De hecho, es un alivio. En realidad, nunca me gustó la recomendación. Me ahorrará muchos gruñidos de ahora en adelante. :)

— Mike Hofer

68

En Framework Design Guidelines p 174 se establece:

Evite nombrar clases base con un sufijo "Base" si la clase está pensada para su uso en API públicas.

También: http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx

— Iain Holder
fuente

19

Además, si la clase abstracta tiene algunos miembros estáticos que se usarán, la 'Base' puede ponerse fea.

— Joel Coehoorn
fuente

14

No recuerdo tal pauta. Creo que deberías usar el nombre que tenga sentido. A veces, la clase abstracta solo está diseñada para proporcionar una funcionalidad común a algunas clases (como herramienta), que creo que deberían tener el sufijo. Sin embargo, en algunos casos, desea utilizarlo como la base de una jerarquía de polimorfismo que no está completa en sí misma. En esos casos sugiero nombrar como una clase normal.

Como puede ver, probablemente no declarará un método que acepte un ButtonBase como parámetro. Está diseñado para proporcionar una funcionalidad mínima para las subclases. Sin embargo, puede tratar a ConfigurationElementcomo una entidad que tiene diferentes formas pero no está completa en sí misma (y por lo tanto es abstracta)

— Mehrdad Afshari
fuente

11

A veces, Base sigue siendo necesaria, especialmente cuando proporciona tanto una clase concreta como una clase abstracta para que alguien la extienda para crear una implementación concreta.
por ejemplo, Controller y ControllerBase (en realidad, Controller también es abstracto, pero proporciona una funcionalidad significativamente mayor que ControllerBase)

El sufijo base es feo cuando se programa contra una interfaz, así que creo que la guía de Microsoft de no usarlo se aplica cuando la clase abstracta se usa predominantemente como una interfaz. Probablemente lo que quieren decir con API pública.

El punto es que hay casos en los que no hay mejor alternativa que usar el sufijo Base.

— James
fuente

4

Estoy de acuerdo. Estoy trabajando en un sistema de feeds que analiza el contenido de diferentes fuentes. Usamos en la API pública una interfaz llamada IFeedParser , e internamente usamos una clase abstracta base que contiene una funcionalidad común llamada BaseFeedParser

— Rui Jarimba

1

Entiendo la inclinación a evitar un sufijo base, pero también entiendo la necesidad de algún sufijo. Ahora, un comentario de este artículo. sugiere usar "Tipo" como sufijo como segunda opción para no usar ninguno. Creo que esto es confuso, pero la idea de que "una palabra tan poco comprometida tendería a indicar que es una clase no comprometida" se me quedó grabada.

Como alternativa: preferiría usar "Kind" como sufijo para indicar que el objeto "pertenece a una raza o familia específica" ( Wikcionario: -kind ).

Ejemplo: DataProvidery ReflectiveDataProviderson ambosDataProviderKind

Inspirado en la biología, donde, por ejemplo, "canis lupus" pertenece a la familia "Canoidea", que se traduce aproximadamente como "perro-ish".

— Kooooons
fuente

1

Microsoft declara, en:

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces

"✓ CONSIDERE terminar el nombre de las clases derivadas con el nombre de la clase base. Esto es muy legible y explica la relación claramente. Algunos ejemplos de esto en el código son: ArgumentOutOfRangeException, que es una especie de Exception, y SerializableAttribute, que es un tipo de atributo. Sin embargo, es importante usar un juicio razonable al aplicar esta guía; por ejemplo, la clase Button es un tipo de evento Control, aunque Control no aparece en su nombre ".

En términos generales, esto descarta implícitamente el uso de "Base" en el nombre.

— Sam Jazz
fuente