Perché non anteponiamo Enum, classi astratte e strutture?

La comunità C # ha usato in modo così diffuso il prefisso "I" per indicare un'interfaccia che persino i programmatori più inesperti sanno di usarlo.

Perché allora non facciamo prefisso enumerazioni, classi o strutture astratte (possibilmente rispettivamente con "E", "A" e "S")?

Ad esempio, se contrassegnassimo tutte le classi astratte con una "A", forniremmo preziose informazioni su quel tipo che, sebbene possa essere dedotto, non è immediatamente ovvio.

Si prega di notare che non sto sostenendo questo cambiamento, sto solo cercando di capire perché non facciamo le cose in questo modo.

Questa discussione risponde al motivo per cui utilizziamo il prefisso "I" ma non risponde al motivo per cui non utilizziamo altri prefissi.

Il punto della convenzione di denominazione per le interfacce è fornire una decisione rapida e senza cervello su come chiamare l'interfaccia implementata dalla tua classe. Se hai un Frobnicator, ma devi dichiarare un'interfaccia per il disaccoppiamento o per qualsiasi motivo, la decisione di chiamarlo non IFrobnicatorrichiede pensiero cosciente, e questo è buono.

Lo stesso problema non si applica agli altri costrutti nominati. Enumerazioni e strutture sono utili, ma non è necessario trovare un secondo nome breve, trasparente, ovviamente correlato oltre al nome stesso. Pertanto, non vi è alcuna pressione per schiaffeggiare una 'E' sul nome di un enum o di una struttura.

(Le classi astratte sono in qualche modo simili alle interfacce, dal momento che è necessario fornire una seconda classe concreta per fare qualsiasi cosa, quindi potrebbero aver acquisito una convenzione di partenza con 'A', ma per qualsiasi motivo non lo hanno fatto. Mi è permesso speculare, penso che "io" essendo una lettera particolarmente ristretta avrei potuto avere a che fare con quello.)

Penso che non sia molto usato perché:

• il più delle volte non importa molto se si tratta di un enum, di una classe astratta o di una struttura
• se lo fa probabilmente posso vederlo dall'uso e altrimenti scoprirlo abbastanza rapidamente
• se lo cambio come enum, classe o struttura astratta, devo anche rinominarlo
• per le persone che non conoscono la convenzione è puro rumore.
• la gente potrebbe semplicemente respingere l'intera idea perché gli è stato insegnato a non usare la notazione ungherese. Ci sono state e ci sono ancora persone che dicono che non dovresti usare la notazione Hungarion, senza fare la distinzione tra App ungherese e Sistemi ungherese. Una bella discussione può essere trovata in questa domanda SO . Non solo la prima risposta è interessante, ma ci sono ottime risposte e commenti. Da quella stessa domanda arriva questo articolo di Joel Spolsky (scorrere fino al paragrafo "Sono l'Ungheria")

in breve: in generale il valore aggiunto non si somma al costo.

Da quell'ultimo punto e qualche interpretazione potresti concludere. I sistemi ungheresi (tipo prefisso) non funzionano e non devono essere utilizzati. Usa ungherese (tipo prefisso) che utilizza.

Riprendendo la tua domanda, penso che la tua notazione proposta sia una forma di App ungherese e se ritieni che il valore aggiunto si sommi ai costi e lo implementi costantemente nella tua base di codice, va bene. Ma dal momento che è necessario considerarlo in base al progetto, non dovrebbe essere una regola generale.

Immagino che la gente abbia notato che ha funzionato più spesso per le interfacce ed è per questo che è diventata una regola generale per le interfacce.

Solo un pensiero (si spera applicabile):

Esiste una tendenza evidente verso la "codifica delle interfacce" piuttosto che le classi concrete. "Oggigiorno" sembra quasi più vantaggioso avere una convenzione di denominazione per le classi, come avviarle con una "C", piuttosto che avere la lettera "I" per l'interfaccia.

Ho appena terminato un progetto Java in cui tutte le interfacce erano in realtà chiamate Model. :

public interface SomethingModel{
}

public class Something implements SomethingModel{
    //lets not line up braces and make it hard to read
    //at least it saves one line
}

mentre in C #

public interface ISomething{}

public class SomethingModel : ISomething
{
   //i can read this
}

Ricablare il mio cervello per non farmi male, ma posso vedere come potrebbe essere utile pensarlo in termini di programmazione dell'interfaccia.