2009-06-26 7 views
8

Come regola generale, generalmente inserisco le classi in un file proprio. Lo studio visivo sembra incoraggiarlo, ma cosa è appropriato per quanto riguarda le interfacce?le interfacce appartengono ai propri file

ad es.

ho lezione Foo che implementa l'interfaccia Bar

public interface IBar 
{ 

} 

public class Foo : IBar 
{ 

} 

sembra naturale gruppo questi all'interno dello stesso file fino a quando un'altra classe implementa l'interfaccia, ma di dedicare un file da 2 linee di codice sembra eccessivo, ma corretta.

Cosa è appropriato?

risposta

26

Vorrei dividerli in 2 file. Ho trovato spesso le classi che iniziano a diventare ingestibili quando non sono nei loro file.

Immaginate di provare a trovare la classe Foo in un file denominato IBar.cs o viceversa.

+0

+ È decisamente più gestibile sia manualmente che tramite script. –

+1

Bene, se tutto ciò che sto facendo è estrarre un'interfaccia per la testabilità, allora un buon posto è nella classe. Quando c'è più di 1 implementazione, diventa più attraente separare i due. –

2

A seconda della situazione, ho diviso ciascuna interfaccia nel suo file o, in alternativa, ho un file Interfaces.cs, in cui raggruppo le interfacce in un determinato spazio dei nomi.

Non avrei mai inserito un'interfaccia nello stesso file .cs come classe che l'ha implementata.

3

Poiché lo scopo di un'interfaccia è definire un "contratto" per (potenzialmente) più classi di implementazione, direi che è più sensato inserire la definizione dell'interfaccia nel proprio file. cioè cosa succede se vuoi anche che Baz implementi Foo?

0

In termini di incapsulamento, ogni oggetto, una classe o un'interfaccia, dovrebbe essere nel proprio file. Anche se l'interfaccia contiene solo un metodo astratto, il fatto che si trovi in ​​un file diverso consente una migliore organizzazione e una migliore incapsulamento. È possibile memorizzare le diverse interfacce in una cartella, assegnargli uno spazio dei nomi appropriato e quindi una soluzione più pulita.

+2

Direi che l'incapsulamento è una proprietà del codice stesso, indipendentemente da dove è memorizzato nel file system. In genere è utile mettere le cose in file con nomi utili, ma questo non fa parte dell'IMO di incapsulamento. –

2

ho solo due situazioni in cui mi trovo mettendo più tipi di alto livello in un unico file:

  • Se si sta definendo più tipi di delegati. Ciascuna sarà una singola dichiarazione, quindi ha senso avere un file Delegates.cs.
  • A volte ha senso dichiarare che un intero gruppo di tipi parziali autogenerati implementa un gruppo di interfacce. Ancora una volta, questa è una linea per ogni tipo:

    // Actualy code is in the autogenerated file 
    public partial class Foo : ICommon {} 
    

Oltre a questo, io uso un file per ogni tipo di livello superiore, che va per interfacce, classi e enumerazioni.

1

Sì, avere un'interfaccia implica che si avrà più di una classe con gli stessi metodi e definizioni di proprietà. Avere in un unico file per ora è conveniente in quanto è facile modificarlo senza modificare i file. Con il passare del tempo, tu e altre classi lo userete, e se doveste fare un cambiamento in fondo alla strada dovrete cacciare e beccare il file giusto.

2

È consigliabile inserire l'interfaccia nel proprio file. Potresti anche considerare di inserire l'interfaccia nella propria libreria di classi.Se l'interfaccia verrà utilizzata da due classi diverse in due diverse librerie, è opportuno inserire l'interfaccia in una terza libreria, in modo da non dover includere alcuna implementazione specifica se si desidera aggiungere l'interfaccia a un nuovo progetto. Nella terza libreria potresti anche inserire classi che funzionano con classi che implementano l'interfaccia (public void Cook (IBar x), per esempio).

1

Io li inserisco sempre in file separati. Avere più di un tipo per file sta solo distraendo l'IMO. Potrei fare una cartella "Interfacce" per loro però. Inoltre penso che non dovresti modificarli tutte le volte che sono le tue implementazioni, comunque averli separati almeno lo promuove un po '.