Seguo questa regola ma alcuni dei miei colleghi non sono d'accordo con essa e sostengono che se una classe è più piccola può essere lasciata nello stesso file con altre classi.
Un altro argomento che sento sempre è "Anche Microsoft non lo fa, quindi perché dovremmo?"
Qual è il consenso generale su questo? Ci sono casi in cui questo dovrebbe essere evitato?
Risposte:
Una classe per file ti dà anche una migliore idea di cosa sta cambiando ogni check in senza guardare le differenze del file.
Lo odio quando la gente pensa in assoluto e dice che non dovresti mai fare questo o quello con qualcosa di soggettivo e schizzinoso come questo, come se tutti dovessimo conformarci a qualcuno stupida idea di giusto e sbagliato. In conclusione: avere più di una classe per file va benissimo se ha senso. Per senso intendo cose come:
Un ottimo esempio del motivo per cui potrei desiderare più classi per file:
Supponiamo di avere alcune dozzine di classi di eccezioni personalizzate, ognuna è una linea 4, potrei avere un file separato per ognuna o potrei raggruppare le eccezioni e avere un file per gruppo. Per me quello che sembra l'approccio più razionale / pragmatico è raggrupparli e avere solo alcuni file, perché è più efficiente tempo / codice saggio (non devo fare clic con il tasto destro del mouse -> Aggiungi classe, rinominare, 50 volte) , mantiene la soluzione meno ingombra e con prestazioni migliori.
static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
return (rule.Overhead(useCase)
< My.PersonalThresholds.ConformismVsPracticality);
}A volte raggruppo più di una classe all'interno di un file se sono strettamente accoppiati e almeno uno di essi è molto piccolo.
La "best practice" generale consiste nell'avere un file per classe.
Oltre agli argomenti ipotetici e concentrandosi invece su Windows .NET con Visual Studio IDE e progetti software in crescita, ha senso in questo contesto avere una classe per file.
In generale, per riferimento visivo nulla batte una classe per file. Veramente.
Non so se Microsoft faccia o non faccia lo stesso, tuttavia hanno creato la partialparola chiave per dividere una classe su più file (questo è ancora più grave). Viene spesso utilizzato per suddividere il codice designer generato automaticamente dal codice personalizzato in stessa classe (ma a volte viene utilizzato per consentire a sviluppatori diversi di lavorare contemporaneamente sulla classe tramite file diversi). Quindi Microsoft vede i vantaggi di più file e tutti hanno in mente più pensieri sull'organizzazione dei file con .NET.
Per le classi nidificate non hai altra scelta che utilizzare un file o almeno le prime parti delle classi in esse contenute. Un file è necessario e va bene in questo caso:
class BicycleWheel {
class WheelSpoke {
}
}Altrimenti perché dovresti tenere più classi in un file? L'argomento "perché sono piccoli" o associati tra loro non contiene molta acqua perché alla fine le tue classi saranno associate ad altre classi.In definitiva, non è possibile dedurre facilmente l'organizzazione in-file degli oggetti in base al loro utilizzo, specialmente quando il software continua a crescere.
Inoltre, se usi le cartelle per gli spazi dei nomi, non avrai mai uno scontro di nomi di file di classe. È anche conveniente individuare una classe per nome file sul file system quando non si trova all'interno di un ambiente di sviluppo come Visual Studio (ad es. Se si desidera modificare rapidamente una classe con Blocco note o qualcosa di rapido / leggero ).
Così tanti buoni motivi ...
partialparola chiave che ho citato.
partial msdn.microsoft.com/en-us/library/wa80x488(VS.80).aspx Ho cercato questo per curiosità.
Nella stragrande maggioranza dei casi, seguo la regola di una classe per file. L'unica eccezione che faccio regolarmente è la definizione di un enum che è strettamente accoppiato a una classe specifica. In questo caso, includerò spesso la definizione dell'enum nel file di quella classe.
Anch'io credo che ci dovrebbe essere un tipo incluso in un singolo file.
C'è un'eccezione a questa regola che deve essere menzionata: avere due classi che differiscono solo per un argomento generico come:
RelayCommand e
RelayCommand<T>1.cs for Foo <T> `e Foo 2.cs for Foo <T, T1>`.
Foo<T>e Foo<U>all'interno dello stesso spazio dei nomi. Ma se gli spazi dei nomi differiscono, di solito si trovano in cartelle diverse. Quindi per Foo<T>e Foo<U>dovrebbe essere Foo 1.cs and for Foo <U, T> `Foo`2.cs. Ma comunque una classe per file.
Davvero, questo si riduce alle preferenze personali. Tutti diranno "una classe per file", ma tutti abbiamo i nostri motivi per evitarlo in determinate circostanze. Avevo un grande progetto con circa 300 enumerazioni diverse. Non avrò mai 300 file separati, uno per ogni classe, quando solo alcuni degli enumeratori erano tristati.
Anche per le persone che non riescono a trovare determinate classi se non sono tutte presenti nei file che prendono il nome da quello che sono, c'è un motivo per cui non usi Trova cercando nell'intera soluzione? L'uso di Trova mi fa risparmiare tempo prezioso scorrendo Esplora soluzioni.
Non importa quanto sia leggero il contenuto, penso che una classe / interfaccia / ecc. Per file sia essenziale.
Se sto lavorando a una grande soluzione in Visual Studio, voglio essere in grado di vedere i file e non dover scavare dentro per vedere. Anche con strumenti di navigazione come ReSharper, voglio un mapping 1: 1.
Se trovi molti file sorgente con poco o nessun contenuto (magari estendendo una classe ma senza aggiungere nulla ad essa), forse dovresti ripensare il tuo progetto.
Trovo che raggruppare una classe con la sua classe di fabbrica standard nello stesso file sia molto utile.
Normalmente avrei una classe per file ma normalmente dovresti usare la tua discrezione per vedere se il file potrebbe contenere classi correlate, ad esempio raggruppando le tue eccezioni che possono essere riutilizzate da te e da altri sviluppatori. In questo caso, l'utente deve includere solo un file anziché più file.
Quindi il punto è: la discrezione dovrebbe essere usata !!!
In soluzioni più grandi penso che sia molto utile avere una classe per file e che il file abbia lo stesso nome della classe. Rende molto più facile individuare il codice in cui devi lavorare.
Lo strumento StyleCop per C # ha regole standard che richiedono non più di una classe di livello superiore in uno spazio dei nomi (più qualsiasi numero di interfacce, delegati ed enumerazioni nello spazio dei nomi).
Nel caso di due o più classi in cui la seconda e le successive sono utilizzate solo dalla prima, quelle potrebbero e dovrebbero essere classi interne, visibili solo alla classe consumatrice.
namespaceblocco, giusto?
Qualche volta una classe per file, ma ...
Quando più classi sono strettamente correlate, più di una classe nello stesso file di origine è, IMHO, MIGLIORE che dedicare un breve file di origine a ciascuna classe. La fonte è più leggibile e compatta (e usando #region la stessa fonte può essere più strutturata di prima).
Considera anche che a volte è NECESSARIO spargere la stessa classe su file diversi (usando il parziale ), dato che avere un file sorgente di oltre 20000 linee non è utile nemmeno con la RAM che ho a disposizione (ma questa è un'altra domanda).
A volte lascerò una classe piccola con una classe più grande, ma solo se sono strettamente legati come un oggetto e la sua classe di raccolta o fabbrica.
C'è un problema con questo però. Alla fine la piccola classe cresce al punto in cui dovrebbe trovarsi nel suo file, se lo sposti nel nuovo file perdi un facile accesso alla cronologia delle revisioni.
vale a dire.
very tightly relatedclasse e lo lascerei a condizione che occupi solo una piccola quantità di spazio sullo schermo e non venga utilizzato per lo stesso scopo da qualsiasi altra classe.
È davvero un problema? :)
Classi davvero piccole, proprio come le enumerazioni, possono essere unite ad altre. C'è una regola da seguire: mettere insieme solo le classi che hanno qualcosa in comune.
Come digressione: in uno dei miei progetti ho un file che contiene 150 classi. Il file ha 10000 righe di codice. Ma è generato automaticamente, quindi è pienamente accettabile :)
Uno dei motivi per mettere più classi correlate in un file è che il povero bastardo che usa la tua API non deve passare mezza giornata a scrivere la dichiarazione di importazione bollettino e il povero bastardo che deve mantenere il codice non deve spendere metà un giorno scorrendo il bollettino della dichiarazione di importazione. La mia regola empirica è che più classi appartengano allo stesso file se si usasse quasi sempre un grande sottoinsieme di esse contemporaneamente anziché solo una alla volta.
Lo faccio, ma solo quando le classi sono correlate in modo figlio-genitore e le classi figlio vengono utilizzate SOLO dal genitore.
Di solito resto con una classe per file. Ma farò eccezioni per gruppi di costrutti simili utilizzati a livello di progetto. Per esempio:
EventArgssottoclassi, poiché di solito sono solo 5-10 righe di codice ciascuna, ma in genere vengono utilizzate da diverse classi diverse. In alternativa, potrei mettere le EventArgsclassi nello stesso file della classe che dichiara gli eventi.enums usati in tutto il progetto. (Se ce n'è uno enumusato solo da una classe, di solito ce la farò private.)Un altro voto per una classe per file con il nome del file uguale alla classe. Per me, aiuta con la manutenibilità a lungo termine. Posso facilmente consultare il repository e vedere quali classi fanno parte di una soluzione senza dover aprire il progetto o alcun file.
Lo seguo il 99% delle volte. È buono seguire gli standard, ma credo anche che la flessibilità abbia il suo posto. A volte sembra solo una sciocca perdita di tempo per spezzare le cose. In quei tempi, mi dimentico e scrivo solo il mio codice.
Le risposte finora sembrano ruotare attorno alle eccezioni delle persone alla regola, quindi ecco la mia: mantengo le classi e le classi "buddy" dei loro metadati quando uso il pacchetto DataAnnotations in .NET3.5 SP1. Altrimenti, sono sempre in file separati. Sai, la maggior parte delle volte. Tranne quando non lo sono.
One case could be:quando le tue classi formano congiuntamente una module / unitche serve alcune classi principali come helper classes, altre sagge no .
dai un'occhiata al codice sorgente del progetto ASP.NET MVC 2.0 . Segue rigorosamente questa regola
Mi piace l'idea di creare classi più piccole e assicurarmi che la classe stia facendo solo ciò che dovrebbe fare. Se hai più classi che stanno contribuendo a risolvere un singolo problema, non c'è nulla di male nel metterle insieme nello stesso file.
Non seguirei le pratiche della SM in quanto non sono le MIGLIORI PRATICHE!
Un altro punto che non ho visto menzionare da nessuno è che quando sviluppi usando la regola di una classe per file puoi facilmente vedere cosa sta usando quella specifica classe.
Ad esempio: potresti avere due classi in cui una classe usa Linq e l'altra no.
Se queste classi fossero nello stesso file non saresti in grado di dire senza guardare attraverso il codice quale classe usa cosa. Quando è una classe per file, tutto ciò che devi fare è guardare la parte superiore del file per vedere esattamente cosa viene usato in quella classe. Aiuta se stai mai migrando verso una nuova libreria, ecc.
Un altro motivo per una classe per file che non è stato menzionato finora nelle risposte postate è che una classe per file semplifica la comprensione dell'impatto di un PR durante una revisione del codice. Riduce anche i conflitti di unione.
Quando qualcuno pubblica un PR per un feedback posso guardare l'elenco dei file modificati e vedere immediatamente qualsiasi sovrapposizione con ciò su cui potrei lavorare. A seconda della sovrapposizione, potrei voler esaminare il loro codice più profondamente o dargli un OK perché sono abbastanza sicuro che non influenzerà le mie modifiche.
Quando due persone lavorano in un file multi-classe ed entrambi aggiungono una dipendenza, è probabile che si verifichi un conflitto di unione nel using blocco in alto. La separazione delle classi in file separa le dipendenze in modo da poter vedere cosa sta usando ogni classe e non si verificano conflitti come questo.
Ci sono eccezioni a questa regola (interfaccia + implementazione, enum, ...) ma è un punto di partenza migliore rispetto al contrario che in genere consente agli sviluppatori junior di raggruppare tutti i tipi di classi non correlate nello stesso file.
Una classe per file è una chiara regola non ambigua non soggetta a interpretazione.
Le classi correlate in un file sono soggette a preferenze e interpretazioni personali (come puoi vedere da tutte le altre risposte qui su quando è OK usare) e quindi è una regola scadente.
Il avanti e indietro è stato molto interessante e apparentemente inconcludente, anche se la mia impressione generale è che una mappatura 1-1 tra classi e file sia l'opinione della maggioranza, anche se con alcune eccezioni da persona a persona.
Sono curioso di sapere se una qualsiasi delle tue risposte varia a seconda che tu stia: (1) sviluppando un'app di Windows Form, un'app Web, una libreria o altro; o (2) utilizzando Visual Studio o no. Usando VS, sembrerebbe che la regola di una classe per file implichi anche una classe per progetto VS poiché il consenso in altri thread sembra essere che le soluzioni / i progetti VS debbano essere rispecchiati nella struttura e nella denominazione dei file / directory. In effetti, la mia impressione è che il consenso sia quello di avere il nome del progetto = nome dell'assemblaggio = nome dello spazio dei nomi (nidificato), il quale verrebbe quindi rispecchiato nella struttura e nella denominazione dei file / directory. Se queste sono le giuste linee guida (o regole), allora tutti questi meccanismi organizzativi apparentemente ortogonali sarebbero comunque mantenuti sincronizzati.
Sì, per motivi di leggibilità dovremmo avere un file per classe !. Sono appena entrato in un progetto. Vedo molte classi in un unico file. rende così difficile per un nuovo ragazzo capirlo. non dovremmo pensare alla manutenibilità? quando sviluppiamo un software? molte volte lo sviluppo continuerà da altri sviluppatori. Abbiamo spazi dei nomi per organizzare le nostre cose, non abbiamo bisogno di file per farlo !.
Un elemento di codice per file, sì.
Tutto il resto è una negligenza - e, francamente, un segno di vittima RAD.
Non appena si avvia il corretto sviluppo del software (IoC, schemi di progettazione, DDD, TDD, ecc ...) e si lascia il parco giochi "omg consente di farlo, non ho idea di come, ma vengo pagato", si vedrà che questa regola conta davvero, davvero.