Convenções de nomenclatura para classes abstratas

Lembro-me claramente de que, em certa época, a diretriz sugerida pela Microsoft era adicionar o sufixo "Base" a uma classe abstrata para evitar o fato de que era abstrata. Por isso, temos aulas como System.Web.Hosting.VirtualFileBase, System.Configuration.ConfigurationValidatorBase, System.Windows.Forms.ButtonBase, e, claro, System.Collections.CollectionBase.

Mas eu percebi que, ultimamente, muitas classes abstratas no Framework não parecem estar seguindo essa convenção. Por exemplo, as seguintes classes são todas abstratas, mas não seguem esta convenção:

• System.DirectoryServices.ActiveDirectory.DirectoryServer

• System.Configuration.ConfigurationElement

• System.Drawing.Brush

• System.Windows.Forms.CommonDialog

E isso é exatamente o que eu poderia perceber em alguns segundos. Então procurei o que a documentação oficial dizia, para ter certeza de que não estava louco. Encontrei os nomes de classes, estruturas e interfaces no MSDN em Design Guidelines for Developing Class Libraries . Estranhamente, não consigo encontrar nenhuma menção à diretriz para adicionar "Base" ao final do nome de uma classe abstrata. E as diretrizes não estão mais disponíveis para a versão 1.1 do Framework.

Então, estou perdendo o controle? Essa diretriz já existiu? Acabou de ser abandonado sem uma palavra? Tenho criado longos nomes de classe sozinho nos últimos dois anos para nada?

Alguém me jogue um osso aqui.

Atualizar Não estou louco. A diretriz existia. Krzysztof Cwalina reclama sobre isso em 2005.

Em Framework Design Guidelines p 174 afirma:

Evite nomear classes base com um sufixo "Base" se a classe se destinar ao uso em APIs públicas.

Além disso: http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx

Além disso, se a classe abstrata tiver alguns membros estáticos que serão usados, a 'Base' pode ficar feia.

Não me lembro de tal diretriz. Acredito que você deva usar um nome que faça sentido. Às vezes, a classe abstrata é projetada apenas para fornecer funcionalidade comum a algumas classes (como uma ferramenta), que eu acho que deveria ter o sufixo. No entanto, em alguns casos, você deseja usá-lo como a base de uma hierarquia de polimorfismo que não está completa. Nesses casos, sugiro nomear como uma classe normal.

Como você vê, você provavelmente não declarará um método que aceita um ButtonBase como parâmetro. Ele foi projetado para fornecer funcionalidade mínima para subclasses. No entanto, você pode tratar a ConfigurationElementcomo uma entidade que possui formas diferentes, mas não é completa por si mesma (e, portanto, é abstrata)

Às vezes, Base ainda é necessária, especialmente quando você fornece uma classe concreta e uma classe abstrata para alguém estender para criar uma implementação concreta.
por exemplo, Controller e ControllerBase (na verdade, Controller também é abstrato, mas fornece significativamente mais funcionalidade do que ControllerBase)

O sufixo básico é feio ao programar em uma interface, então acho que a diretriz da Microsoft de não usá-lo se aplica quando a classe abstrata é usada predominantemente como uma interface. Provavelmente o que eles querem dizer com API pública.

A questão é que há casos em que não há alternativa melhor do que usar o sufixo Base.

Eu entendo a tendência de evitar um sufixo-base, mas também entendo a necessidade de algum sufixo. Agora, um comentário deste artigo sugere o uso de "Tipo" como um sufixo como segunda opção para não usar nenhum. Acredito que isso seja confuso, mas a ideia de que "tal palavra não comprometida tenderia a indicar que é uma classe não comprometida" permaneceu comigo.

Como alternativa: eu prefiro usar "Tipo" como sufixo para declarar o objeto como "pertencente a uma raça ou família especificada" ( Wikcionário: -tipo ).

Exemplo: DataProvidere ReflectiveDataProvidersão ambosDataProviderKind

Inspirado na Biologia onde, por exemplo, "canis lupus" pertence à família "Canoidea", que se traduz grosso modo como "dog-ish".

A Microsoft declara, em:

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

"✓ CONSIDERE terminar o nome das classes derivadas com o nome da classe base. Isso é muito legível e explica a relação claramente. Alguns exemplos disso no código são: ArgumentOutOfRangeException, que é um tipo de Exception, e SerializableAttribute, que é um tipo de Atributo. No entanto, é importante usar um julgamento razoável ao aplicar esta diretriz; por exemplo, a classe Button é um tipo de evento Control, embora Control não apareça em seu nome. "

De modo geral, isso exclui implicitamente o uso de "Base" no nome.