I nomi delle interfacce dovrebbero iniziare con un prefisso "I"?

Ho letto " Clean Code " di Robert Martin per diventare un programmatore migliore. Sebbene finora nulla di tutto ciò sia stato davvero rivoluzionario, mi ha fatto riflettere diversamente sul modo in cui progetto applicazioni e scrivo codice.

C'è una parte del libro che non solo non sono d'accordo, ma non ha senso per me, in particolare per quanto riguarda le convenzioni di denominazione delle interfacce. Ecco il testo, preso direttamente dal libro. Ho audace l'aspetto di questo che trovo confuso e vorrei chiarimenti.

Preferisco lasciare le interfacce disadorno. L'I precedente, così comune nelle mazzette di oggi, è una distrazione nella migliore delle ipotesi e troppe informazioni nella peggiore. Non voglio che i miei utenti sappiano che sto consegnando loro un'interfaccia .

Forse è perché sono solo uno studente, o forse perché non ho mai fatto alcuna programmazione professionale o di gruppo, ma vorrei che l'utente sapesse che si tratta di un'interfaccia. C'è una grande differenza tra l'implementazione di un'interfaccia e l'estensione di una classe.

Quindi, la mia domanda si riduce a "Perché dovremmo nascondere il fatto che una parte del codice si aspetta un'interfaccia?"

modificare

In risposta a una risposta:

Se il tuo tipo è un'interfaccia o una classe è la tua attività, non l'attività di qualcuno che utilizza il tuo codice. Quindi non dovresti perdere i dettagli del tuo codice in questo codice di terze parti.

Perché non dovrei "trapelare" i dettagli se un determinato tipo è un'interfaccia o una classe in codice di terze parti? Non è importante per lo sviluppatore di terze parti che utilizza il mio codice sapere se implementeranno un'interfaccia o estenderanno una classe? Le differenze non sono così importanti come le sto immaginando di essere nella mia mente?

Se ti fermi a pensarci, vedrai che un'interfaccia non è davvero semanticamente molto diversa da una classe astratta:

• Entrambi hanno metodi e / o proprietà (comportamento);
• Nessuno dei due dovrebbe avere campi non privati ​​(dati);
• Nessuno dei due può essere istanziato direttamente;
• Derivare da uno significa implementare tutti i metodi astratti che ha, a meno che anche il tipo derivato non sia astratto.

In effetti, le distinzioni più importanti tra classi e interfacce sono:

• Le interfacce non possono avere dati privati;
• I membri dell'interfaccia non possono avere modificatori di accesso (tutti i membri sono "pubblici");
• Una classe può implementare più interfacce (invece di essere generalmente in grado di ereditare da una sola classe di base).

Poiché le uniche distinzioni particolarmente significative tra classi e interfacce ruotano attorno a (a) dati privati ​​e (b) gerarchia di tipi - nessuno dei quali fa la minima differenza per un chiamante - non è generalmente necessario sapere se un tipo è un'interfaccia o una classe. Non hai certamente bisogno dell'indicazione visiva .

Tuttavia, ci sono alcuni casi angolari di cui tenere conto. In particolare, se stai usando la riflessione, l'intercettazione, i proxy / mixin dinamici, la tessitura bytecode, la generazione di codice o qualsiasi cosa che coinvolga direttamente il sistema di battitura o il codice dell'ambiente stesso, allora è molto utile e talvolta necessario sapere subito pipistrello se hai a che fare con un'interfaccia o una classe. Chiaramente non vuoi che il tuo codice fallisca misteriosamente perché hai provato ad aggiungere una classe, piuttosto che un'interfaccia, come un mixin.

Per un tipico codice di logica aziendale semplice e vaniglia, tuttavia, non è necessario pubblicizzare le distinzioni tra classi astratte e interfacce perché non entreranno mai in gioco.

Detto questo, tendo a anteporre comunque le mie interfacce C # Iperché quella è la convenzione .NET utilizzata e sostenuta da Microsoft. E quando sto spiegando le convenzioni di codifica a un nuovo sviluppatore, è molto meno seccante usare le regole di Microsoft piuttosto che spiegare perché abbiamo le nostre regole "speciali".

In molti modi, la coerenza è più importante della convenzione. Finché sei coerente nei tuoi schemi di denominazione, non sarà difficile lavorare con loro. Il prefisso si interfaccia con un I, se vuoi, o lascia semplicemente il nome disadorno, non mi importa se scegli uno stile e ti attieni!

Il libro è pieno di cose buone, ma aggiungerei ancora "I" al nome dell'interfaccia.

Immagina di avere public interface ILogun'implementazione predefinita public class Log.

Ora, se decidi di farlo public interface Log, all'improvviso devi cambiare la classe Log in public class LogDefaulto qualcosa del genere. Sei passato dall'avere un personaggio in più a sette - sicuramente è uno spreco.

C'è spesso una linea sottile tra teoria e pratica. In teoria questa è davvero una buona idea, ma in pratica non è così buona.

Bene, non si tratta di implementare l'interfaccia o di estendere una classe. In questi casi, sai comunque cosa stai facendo.

Tuttavia, quando un codice di terze parti (un altro modulo dell'applicazione per esempio) manipola i tuoi dati, questo codice non dovrebbe interessarti se stai presentando un'interfaccia o una classe.

Questo è il punto centrale dell'astrazione. Stai presentando a questo codice di terze parti un oggetto di un determinato tipo. Questo dato tipo ha alcune funzioni membro che puoi chiamare. È abbastanza.

Se il tuo tipo è un'interfaccia o una classe è la tua attività, non l'attività di qualcuno che utilizza il tuo codice. Quindi non dovresti trasferire i dettagli del tuo codice a questo codice di terze parti.

A proposito, interfacce e classi sono tipi di riferimento alla fine. E questo è ciò che conta. Quindi questo è ciò che la tua convenzione di denominazione deve sottolineare.

La maggior parte delle risposte sembra supporre che il linguaggio di programmazione sia Java o C # in cui esiste un concetto (o parola chiave) per interfacce / classi astratte. In questi casi, in un IDE decente, è immediatamente visibile con quale tipo di classe uno si occupa e la scrittura public interface IMyClassè una duplicazione non necessaria. È come se non scrivessi public final FinalMyClass: immagina di inserire ogni parola chiave nel nome della classe.

Tuttavia, secondo me in C ++, la situazione è leggermente diversa in quanto si deve immergersi nel file di intestazione e vedere se la classe ha metodi virtuali per scoprire se si tratta di una classe astratta. In tal caso, posso vedere chiaramente un argomento per la scrittura class AbstractMyClass.

Quindi la mia risposta sarebbe: dipende dal linguaggio di programmazione.

Aggiornato 2016: 2 anni di esperienza in C ++ in seguito ora probabilmente prenderei in considerazione una cattiva pratica con prefisso ai nomi delle classi Abstract, anche se direi che probabilmente ci sono basi di codice che sono così complesse che potrebbe avere senso.

Segui i modi di dire della lingua che stai utilizzando.

Ogni lingua ha i suoi modi di dire e le sue linee guida di codifica. Ad esempio, in C #, è idiomatico il prefisso delle interfacce con I. In Go, non lo è.

Nel mio codice (Java), tendo ad avere questa convenzione nelle API che espongo ai chiamanti:

• La funzionalità è fornita attraverso le interfacce e mai dalle classi.
• Le parti non funzionali sono classi.

Per non funzionale, intendo cose come strutture di dati puri (come classi che fungono da ponti per la serializzazione XML o ORM), enumerazioni ed eccezioni, tutte che non possono essere interfacce (bene, è possibile per le classi di dati puri , ma è un sacco di lavoro per un guadagno molto piccolo in quanto non c'è nulla che quelle classi facciano tranne i dati di conservazione).

In termini di convenzioni di denominazione, le interfacce tendono a mappare su nomi di attori (ad es. FooBarWatcher) O aggettivi (ad es. FooBarWatchable) E sia le classi di dati puri che le enumerazioni si associano a nomi non attivi (ad es. FooBarStatus); l'IDE può guidare il consumatore API senza speciali convenzioni di denominazione. Eccezioni seguono solite convenzioni Java ( FooBarException, FooBarError, FooBarFault), naturalmente.

Metterò spesso anche le interfacce nel loro pacchetto o anche nella loro libreria, solo per assicurarmi di non essere tentato di infrangere le mie regole. (Questo mi aiuta anche a gestire la build quando sto derivando il codice da fonti esterne come i documenti WSDL.)