.net - sirve - metodos abstractos
Convenciones de nombres para clases abstractas (6)
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 abstracto. Por lo tanto, tenemos clases como System.Web.Hosting.VirtualFileBase , System.Configuration.ConfigurationValidatorBase , System.Windows.Forms.ButtonBase y, por supuesto, System.Collections.CollectionBase .
Pero me he dado cuenta de que, últimamente, muchas clases abstractas en el Framework no parecen estar siguiendo 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 exactamente lo que podría hacer en unos segundos. Así que fui a buscar lo que la documentación oficial tenía que decir, para asegurarme de que no estaba loco. Encontré los nombres de clases, estructuras e interfaces en MSDN en las Pautas de diseño para desarrollar bibliotecas de clases . Curiosamente, no puedo encontrar ninguna mención de la guía para agregar "Base" al final del nombre de una clase abstracta. Y las directrices ya no están disponibles para la versión 1.1 del Framework.
Entonces, ¿lo estoy perdiendo? ¿Alguna vez esta guía existió? ¿Ha sido abandonado sin una palabra? ¿He estado creando nombres de clase durante los últimos dos años por nada?
Alguien me arroja un hueso aquí.
Actualizacion No estoy loco La guía existió. Krzysztof Cwalina se queja de ello en 2005.
A veces, Base aún es necesario, especialmente cuando se proporciona tanto una clase concreta como una clase abstracta para que alguien la amplíe y cree una implementación concreta.
por ejemplo, Controller y ControllerBase (en realidad, Controller también es abstracto, pero proporciona significativamente más funcionalidades que ControllerBase)
El sufijo base es feo cuando se programa en una interfaz, por lo que creo que la guía de Microsoft para no usarlo se aplica cuando la clase abstracta se usa predominantemente como una interfaz. Probablemente lo que quieren decir con Public API.
El punto es que hay casos donde no hay mejor alternativa que usar el sufijo Base.
Además, si la clase abstracta tiene algunos miembros estáticos que se usarán, la ''Base'' puede ponerse fea.
En las Pautas de diseño del marco p 174 establece:
Evite nombrar las 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
Entiendo la inclinación de evitar un Base-Suffix, 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 podría indicar que es una clase no comprometida" me atrapó.
Como alternativa: preferiría usar "Tipo" como sufijo para indicar el objeto como "perteneciente o perteneciente a una raza o familia específica" ( Wiktionary: -kind ).
Ejemplo: DataProvider y ReflectiveDataProvider son ambos DataProviderKind
Inspirado por la biología, donde, por ejemplo, "canis lupus" pertenece a la familia "Canoidea", que muy aproximadamente se traduce como "perro-ish".
Microsoft declara, en:
"✓ CONSIDERAR terminar el nombre de las clases derivadas con el nombre de la clase base. Esto es muy legible y explica la relación con claridad. Algunos ejemplos de esto en el código son: ArgumentOutOfRangeException, que es un tipo de excepción, 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 de control, aunque Control no aparece en su nombre ".
En términos generales, esto descarta implícitamente el uso de "Base" en el nombre.
No recuerdo tal guía. Creo que deberías usar la nomenclatura que tenga sentido. A veces, la clase abstracta solo está diseñada para proporcionar funcionalidad común a algunas clases (como herramienta), que creo que debería tener el sufijo. Sin embargo, en algunos casos, desea utilizarlo como la base de una jerarquía de polimorfismo que no se completa por sí misma. En esos casos sugiero nombrar como una clase normal.
Como ve, probablemente no declarará un método que acepte un ButtonBase como parámetro. Está diseñado para proporcionar una funcionalidad mínima para subclases. Sin embargo, puede tratar un elemento de ConfigurationElement como una entidad que tiene formularios diferentes pero no está completo en sí mismo (y, por lo tanto, es abstracto)