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.DirectoryServerSystem.Configuration.ConfigurationElementSystem.Drawing.BrushSystem.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.
fuente
Respuestas:
En Framework Design Guidelines p 174 se establece:
También: http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx
fuente
Además, si la clase abstracta tiene algunos miembros estáticos que se usarán, la 'Base' puede ponerse fea.
fuente
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)fuente
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.
fuente
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:
DataProvideryReflectiveDataProviderson ambosDataProviderKindInspirado en la biología, donde, por ejemplo, "canis lupus" pertenece a la familia "Canoidea", que se traduce aproximadamente como "perro-ish".
fuente
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.
fuente