Perché non prefixiamo Enums, Abstract classes e Structs?

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

Lo stesso problema non si applica agli altri costrutti che nominate. Enum e structs 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, dato che devi fornire una seconda classe concreta per ottenere qualcosa, quindi potrebbero aver acquisito una convenzione che inizia con "A", ma per qualche ragione, non hanno fatto t Se mi è permesso speculare, penso che "io" sia una lettera particolarmente ristretta potrebbe aver avuto qualcosa a che fare con quello.)

Penso che non sia usato molto perché:

• il più delle volte non importa molto se si tratta di un enum, o 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 astratta o struct, devo anche rinominarlo
• per le persone che non conoscono la convenzione è puro rumore
• le persone potrebbero semplicemente respingere l'intera idea perché gli è stato insegnato a non usare la notazione ungherese. Ci sono state e sono ancora persone che dicono che non dovresti usare la notazione Hungarion, senza fare la distinzione tra Apps ungherese e Systems 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 (scorri fino al paragrafo "I'm Hungary")

in short : In general the added value doesn't add up to the cost.

Da quell'ultimo punto elenco e qualche interpretazione che potresti concludere. I sistemi ungheresi (tipo di prefisso) sono negativi e non dovrebbero essere utilizzati. Le app ungheresi (tipo di prefisso) lo utilizzano.

Riportando la tua domanda penso che la tua notazione proposta sia una forma di app ungherese e se ritieni che il valore aggiunto aumenti i costi e lo implementi coerentemente nel tuo codice base, va bene. Ma dal momento che devi considerarlo in base al progetto, non dovrebbe essere una regola generale.

Immagino che le persone abbiano notato che ha fatto il mater per le interfacce più spesso ed è per questo che è diventata una regola generale per le interfacce.

Solo un pensiero (si spera):

Esiste una tendenza evidente verso la "codifica per interfacce" piuttosto che le classi concrete. "Al giorno d'oggi" 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 .. Sì, la convenzione del nome dell'interfaccia doveva terminare il nome con "Model" ... quindi avere una specie di strumento "DataTransferObject / DTO" l'interfaccia come:

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 mantenere la ferita ferita, ma posso vedere come potrebbe essere d'aiuto pensare termini di programmazione all'interfaccia.