Convenzioni di denominazione per classi astratte

Ricordo distintamente che, un tempo, la linea guida spinta da Microsoft era quella di aggiungere il suffisso "Base" a una classe astratta per ovviare al fatto che fosse astratta. Quindi, abbiamo classi come System.Web.Hosting.VirtualFileBase, System.Configuration.ConfigurationValidatorBase, System.Windows.Forms.ButtonBase, e, naturalmente, System.Collections.CollectionBase.

Ma ho notato che, negli ultimi tempi, molte classi astratte nel Framework non sembrano seguire questa convenzione. Ad esempio, le seguenti classi sono tutte astratte ma non seguono questa convenzione:

• System.DirectoryServices.ActiveDirectory.DirectoryServer

• System.Configuration.ConfigurationElement

• System.Drawing.Brush

• System.Windows.Forms.CommonDialog

Ed è proprio quello che ho potuto tirare fuori in pochi secondi. Quindi sono andato a cercare cosa diceva la documentazione ufficiale, per assicurarmi di non essere pazzo. Ho trovato i nomi di classi, strutture e interfacce su MSDN in Linee guida di progettazione per lo sviluppo di librerie di classi . Stranamente, non riesco a trovare alcuna menzione della linea guida per aggiungere "Base" alla fine del nome di una classe astratta. E le linee guida non sono più disponibili per la versione 1.1 del Framework.

Quindi lo sto perdendo? Questa linea guida è mai esistita? È stato appena abbandonato senza una parola? Ho creato lunghi nomi di classi da solo negli ultimi due anni per niente?

Qualcuno mi ha lanciato un osso qui.

Aggiorna non sono pazzo. La linea guida esisteva. Krzysztof Cwalina se ne lamenta nel 2005.

In Framework Design Guidelines p 174 afferma:

Evita di denominare le classi di base con un suffisso "Base" se la classe è destinata all'uso in API pubbliche.

Inoltre: http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx

Inoltre, se la classe astratta ha alcuni membri statici che verranno utilizzati, la "Base" può diventare brutta.

Non ricordo una linea guida del genere. Credo che dovresti usare la denominazione che ha senso. A volte la classe astratta è progettata solo per fornire funzionalità comuni ad alcune classi (come strumento), che penso dovrebbero avere il suffisso. Tuttavia, in alcuni casi, vuoi usarlo come base di una gerarchia di polimorfismo che non è completa in sé. In questi casi suggerisco di denominare come una normale classe.

Come vedi, probabilmente non dichiarerai un metodo che accetta un ButtonBase come parametro. È progettato per fornire funzionalità minime per le sottoclassi. Tuttavia, potresti trattare a ConfigurationElementcome un'entità che ha forme diverse ma non è completa su se stessa (e quindi è astratta)

A volte Base è ancora necessario, specialmente quando fornisci sia una classe concreta che una classe astratta da estendere a qualcuno per creare un'implementazione concreta.
ad esempio Controller e ControllerBase (in realtà Controller è anche astratto, ma fornisce significativamente più funzionalità rispetto a ControllerBase)

Il suffisso di base è brutto quando si programma su un'interfaccia, quindi penso che le linee guida di Microsoft per non usarlo si applichino quando la classe astratta è usata prevalentemente come un'interfaccia. Probabilmente cosa intendono per API pubblica.

Il punto è che ci sono casi in cui non esiste alternativa migliore all'utilizzo del suffisso Base.

Comprendo l'inclinazione ad evitare un suffisso di base, ma capisco anche la necessità di un suffisso. Ora, un commento di questo articolo suggerisce di utilizzare "Tipo" come suffisso come seconda scelta per non utilizzarne alcuno. Credo che questo sia fonte di confusione, ma l'idea che "una parola così non impegnativa tenderebbe a indicare che è una classe non impegnata" mi è rimasta impressa.

Come alternativa: preferirei usare "Tipo" come suffisso per dichiarare l'oggetto come "di o appartenente a una razza o famiglia specifica" ( Wikizionario: -kind ).

Esempio: DataProvidere ReflectiveDataProvidersono entrambiDataProviderKind

Ispirato dalla biologia dove ad esempio "canis lupus" appartiene alla famiglia "Canoidea", che si traduce molto approssimativamente in "dog-ish".

Microsoft afferma, a:

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

"✓ CONSIDERARE di terminare il nome delle classi derivate con il nome della classe base. Questo è molto leggibile e spiega chiaramente la relazione. Alcuni esempi di questo nel codice sono: ArgumentOutOfRangeException, che è una sorta di Eccezione, e SerializableAttribute, che è un tipo di Attributo. Tuttavia, è importante usare un giudizio ragionevole nell'applicazione di questa linea guida; per esempio, la classe Button è una sorta di evento Control, sebbene Control non compaia nel suo nome. "

In generale, questo esclude implicitamente l'uso di "Base" nel nome.