Dichiarare l'interfaccia nello stesso file della classe base, è una buona pratica?

Per essere intercambiabili e verificabili, normalmente i servizi con logica devono avere un'interfaccia, ad es

public class FooService: IFooService 
{ ... }

Dal punto di vista del design, sono d'accordo con questo, ma una delle cose che mi disturba con questo approccio è che per un servizio dovrai dichiarare due cose (la classe e l'interfaccia), e nel nostro team, normalmente due file (uno per la classe e uno per l'interfaccia). Un altro disagio è la difficoltà di navigazione perché l'uso di "Vai alla definizione" in IDE (VS2010) punterà all'interfaccia (poiché altre classi si riferiscono all'interfaccia), non alla classe effettiva.

Stavo pensando che scrivere IFooService nello stesso file di FooService ridurrà la stranezza di cui sopra. Dopotutto, IFooService e FooService sono molto correlati. È una buona pratica? C'è una buona ragione per cui IFooService deve trovarsi nel suo file?

Non deve essere nel suo file, ma il tuo team dovrebbe decidere su uno standard e attenersi ad esso.

Inoltre, hai ragione che "Vai alla definizione" ti porta all'interfaccia, ma se hai installato Resharper , è solo un clic per aprire un elenco di classi / interfacce derivate da tale interfaccia, quindi non è un grosso problema. Ecco perché mantengo l'interfaccia in un file separato.

Penso che dovresti tenerli file separati. Come hai detto, l'idea è di rimanere testabile e intercambiabile. Posizionando l'interfaccia nello stesso file dell'implementazione, si associa l'interfaccia con l'implementazione specifica. Se si decide di creare un oggetto simulato o un'altra implementazione, l'interfaccia non sarà logicamente separata da FooService.

Secondo SOLID, non solo dovresti creare l'interfaccia e non solo dovrebbe essere in un file diverso, ma dovrebbe essere in un assembly diverso.

Perché? Poiché qualsiasi modifica a un file di origine che viene compilata in un assembly richiede la ricompilazione dell'assembly e qualsiasi modifica a un assembly richiede la ricompilazione di qualsiasi assembly dipendente. Quindi, se il tuo obiettivo, basato su SOLID, è di poter sostituire un'implementazione A con un'implementazione B, mentre la classe C dipendente dall'interfaccia I non deve conoscere la differenza, devi assicurarti che l'assemblaggio con I in esso non cambia, proteggendo così gli usi.

"Ma è solo una ricompilazione" Ti sento protestare. Beh, potrebbe essere, ma nell'app per smartphone, che è più facile sulla larghezza di banda dei dati degli utenti; scaricando un binario che è cambiato o scaricando quel binario e altri cinque con codice che dipende da esso? Non tutti i programmi sono scritti per essere utilizzati dai computer desktop su una LAN. Anche in quel caso, dove la larghezza di banda e la memoria sono economiche, i rilasci di patch più piccoli possono avere valore perché sono banali da inviare all'intera LAN attraverso Active Directory o livelli di gestione del dominio simili; i tuoi utenti aspetteranno solo pochi secondi per essere applicato al successivo accesso invece di pochi minuti per la reinstallazione dell'intera cosa. Per non parlare del fatto che, minore è il numero di assiemi che devono essere ricompilati durante la costruzione di un progetto, più velocemente sarà costruito,

Ora, il disclaimer: questo non è sempre possibile o fattibile da fare. Il modo più semplice per farlo è creare un progetto centralizzato di "interfacce". Questo ha i suoi lati negativi; il codice diventa meno riutilizzabile perché è necessario fare riferimento al progetto di interfaccia E al progetto di implementazione in altre app riutilizzando il livello di persistenza o altri componenti chiave dell'app. Puoi ovviare a questo problema suddividendo le interfacce in assiemi più strettamente accoppiati, ma poi hai più progetti nella tua app che rendono una build completa molto dolorosa. La chiave è l'equilibrio e il mantenimento del design liberamente accoppiato; di solito puoi spostare i file in base alle necessità, quindi quando vedi che una classe avrà bisogno di molte modifiche o che nuove implementazioni di un'interfaccia saranno necessarie regolarmente (forse per interfacciarsi con le versioni di altri software supportate di recente,

Perché avere file separati è un disagio? Per me è molto più ordinato e pulito. È comune creare una sottocartella denominata "Interfacce" e attaccare lì i file IFooServer.cs, se si desidera visualizzare un numero inferiore di file in Esplora soluzioni.

Il motivo per cui l'interfaccia è definita nel proprio file è per lo stesso motivo per cui le classi sono generalmente definite nel proprio file: la gestione del progetto è più semplice quando la struttura logica e la struttura dei file sono identiche, quindi si sa sempre quale file è definito in una determinata classe Questo può semplificarti la vita durante il debug (le tracce dello stack delle eccezioni in genere forniscono i file e i numeri di riga) o quando unisci il codice sorgente in un repository di controllo del codice sorgente.

Spesso è buona norma lasciare che i file di codice contengano solo una singola classe o una singola interfaccia. Ma queste pratiche di codifica sono un mezzo per raggiungere un fine: strutturare meglio il tuo codice facilitando il lavoro. Se tu e il tuo team trovate più facile lavorare con se le classi sono tenute insieme alle loro interfacce, lo fate sicuramente.

Personalmente preferisco avere l'interfaccia e la classe nello stesso file quando esiste solo una classe che implementa l'interfaccia, come nel tuo caso.

Per quanto riguarda i problemi che hai con la navigazione, posso consigliare vivamente ReSharper . Contiene alcune scorciatoie molto utili per passare direttamente al metodo che implementa un metodo di interfaccia specifico.

Ci sono molte volte in cui vuoi che la tua interfaccia non sia solo in un file separato dalla classe, ma anche in un assieme separato .

Ad esempio, un'interfaccia del contratto di servizio WCF può essere condivisa sia dal client che dal servizio se si ha il controllo su entrambe le estremità del filo. Spostando l'interfaccia nel proprio assembly, avrà un minor numero di dipendenze di assembly. Questo rende molto più semplice il consumo da parte del cliente, allentando l'accoppiamento con la sua implementazione.

Raramente, se mai, ha senso avere un'unica implementazione di un'interfaccia ¹ . Se si inserisce un'interfaccia pubblica e una classe pubblica che implementa tale interfaccia nello stesso file, è probabile che non sia necessaria un'interfaccia.

Quando la classe che co-localizzi con l'interfaccia è astratta e sai che tutte le implementazioni della tua interfaccia dovrebbero ereditare quella classe astratta, localizzare i due nello stesso file ha senso. Dovresti comunque esaminare attentamente la tua decisione di utilizzare un'interfaccia: chiediti se una classe astratta da sola andrebbe bene e lascia cadere l'interfaccia se la risposta è affermativa.

In generale, tuttavia, è necessario attenersi alla strategia "una classe / interfaccia pubblica corrisponde a un file": è facile da seguire e rende più semplice la navigazione dell'albero dei sorgenti.

Le interfacce appartengono ai loro clienti e non alle loro implementazioni, come definito in Principi, pratiche e schemi agili di Robert C. Martin. Pertanto, combinare interfaccia e implementazione nello stesso posto è contro il suo principio.

Il codice client dipende dall'interfaccia. Ciò consente la possibilità di compilare e distribuire il codice client e l'interfaccia senza l'implementazione. Quindi puoi avere implementazioni diverse che funzionano come plugin per il codice client.

AGGIORNAMENTO: Questo non è un principio solo agile qui. The Gang of Four in Design Patterns, già nel '94, sta già parlando di client che aderiscono alle interfacce e programmano le interfacce. La loro visione è simile.

Personalmente non mi piace l'io davanti a un'interfaccia. Come utente di questo tipo non voglio vedere che questa è un'interfaccia o no. Il tipo è la cosa interessante. In termini di dipendenze FooService è UNA possibile implementazione di IFooService. L'interfaccia dovrebbe trovarsi vicino al luogo in cui viene utilizzata. D'altra parte l'implementazione dovrebbe essere in un luogo in cui può essere facilmente modificata senza influenzare il client. Quindi, preferirei due file - normalmente.

La codifica per le interfacce può essere negativa, in effetti viene trattata come un anti-modello per determinati contesti e non è una legge. Di solito un buon esempio di codifica per interfacce anti-pattern è quando hai un'interfaccia che ha solo un'implementazione nella tua applicazione. Un altro sarebbe se il file di interfaccia diventa così fastidioso che devi nascondere la sua dichiarazione nel file della classe implementata.

Mettere una classe e un'interfaccia nello stesso file non pone limiti al modo in cui entrambi possono essere usati. Un'interfaccia può ancora essere usata per simulazioni ecc. Allo stesso modo, anche se si trova nello stesso file di una classe che la implementa. La domanda potrebbe essere percepita come una questione di convenienza organizzativa, nel qual caso direi di fare qualunque cosa ti semplifichi la vita!

Naturalmente, si potrebbe sostenere che avere i due nello stesso file potrebbe indurre gli incauti a considerarli accoppiati più programmaticamente di quanto non siano realmente, il che è un rischio.

Personalmente, se mi imbattessi in una base di codice che utilizzava una convenzione sull'altra, non mi preoccuperei troppo.