Devo usare la visibilità interna o pubblica per impostazione predefinita?

Question

Sono uno sviluppatore C # e .Net abbastanza nuovo. Di recente ho creato uno snap-in MMC usando C # e sono stato gratificato da quanto fosse facile da fare, soprattutto dopo aver sentito molte storie dell'orrore da alcuni altri sviluppatori nella mia organizzazione su quanto sia difficile fare in C ++.

Ho praticamente passato l'intero progetto ad un certo punto e ho reso ogni istanza del "pubblico" parola chiave in " internal " ;, ad eccezione di quanto richiesto dal runtime per eseguire lo snapin. Cosa ne pensi di questo, dovresti generalmente rendere le classi e i metodi pubblici o interni?

Answer 1

Credo nelle caselle nere ove possibile. Come programmatore, voglio una blackbox ben definita che posso facilmente inserire nei miei sistemi e farlo funzionare. Gli do i valori, chiamo i metodi appropriati e quindi riesco a recuperare i miei risultati.

A tal fine, dammi solo le funzionalità che la classe deve esporre per funzionare.

Prendi in considerazione un ascensore. Per farlo andare a un piano, premo un pulsante. Questa è l'interfaccia pubblica per la scatola nera che attiva tutte le funzioni necessarie per portare l'ascensore al piano desiderato.

Answer 2

Quello che hai fatto è esattamente quello che dovresti fare; dai alle tue classi la minima visibilità possibile. Cavolo, se vuoi davvero andare tutto in su, puoi fare tutto interno (al massimo) e usare InternalsVisibleTo attributo , in modo che tu possa separare la tua funzionalità ma ancora non esporre al mondo esterno sconosciuto.

L'unico motivo per rendere pubbliche le cose è che stai impacchettando il tuo progetto in diverse DLL e / o EXE e (per qualsiasi motivo) non ti interessa usare InternalsVisibleTo , oppure tu ' la creazione di una libreria per l'utilizzo da parte di terzi. Ma anche in una libreria per l'utilizzo da parte di terzi, dovresti provare a ridurre la "superficie". ove possibile; più classi hai a disposizione, più confusa sarà la tua biblioteca.

In C #, un buon modo per assicurarti di utilizzare la visibilità minima possibile è di lasciare i modificatori di visibilità fino a quando non ne hai bisogno. Tutto in C # viene impostato per impostazione predefinita sulla minima visibilità possibile: interno per le classi e privato per i membri della classe e classi interne.

Answer 3

Penso che dovresti sbagliare dal lato delle classi e dei membri interni. Puoi sempre aumentare la visibilità di un oggetto ma diminuirlo può causare problemi. Ciò è particolarmente vero se stai costruendo un framework per gli altri.

Devi stare attento però a non nascondere funzionalità utili ai tuoi utenti. Esistono molti metodi utili nel BCL .NET che non possono essere utilizzati senza ricorrere alla riflessione. Tuttavia nascondendo questi metodi si riduce la superficie di ciò che deve essere testato e mantenuto.

Answer 4

Preferisco evitare di contrassegnare le classi come public a meno che non voglia esplicitamente che il mio cliente le consumi, e sono pronto a sostenerle.

Invece di contrassegnare una classe come internal , lascio vuota l'accessibilità. In questo modo, public si distingue alla vista come qualcosa di notevole. (L'eccezione, ovviamente, sono le classi nidificate, che devono essere contrassegnate se devono essere visibili anche nello stesso assembly.)

Answer 5

La maggior parte delle classi dovrebbe essere interna , ma la maggior parte dei membri non privati ??dovrebbe essere public .

La domanda che dovresti porre su un membro è " se la classe fosse resa pubblica vorrei che il membro fosse esposto? " ;. La risposta è di solito " yes (quindi public ) " perché le lezioni senza membri accessibili non sono molto utili! I membri interni hanno un ruolo; sono "accessi backdoor" intesi solo per parenti stretti che vivono nella stessa assemblea.

Anche se la tua classe rimane interna, è bello vedere quali sono i membri della porta d'ingresso e quali quelli della porta di servizio. E se mai lo cambi in pubblico, non dovrai tornare indietro e pensare a quali sono quali.

Answer 6

Dovresti tendere ad esporre il meno possibile ad altre classi e riflettere attentamente su ciò che esponi e perché.

Answer 7

C'è qualche motivo per utilizzare Internal anziché Private? Ti rendi conto che Internal ha un ambito di livello assembly. In altre parole, le classi / i membri interni sono accessibili a tutte le classi in un assembly multi-class.

Come hanno già detto alcune altre risposte, in generale cerca il massimo livello di incapsulamento possibile (cioè privato) a meno che tu non abbia effettivamente bisogno di interni / protetti / pubblici.

Answer 8

Ho riscontrato un problema utilizzando le classi interne il più possibile. Non puoi avere metodi, proprietà, campi, ecc. Di quel tipo (o tipo di parametro o tipo restituito) più visibili di quelli interni. Questo porta ad avere costruttori interni e proprietà. Questo non dovrebbe essere un problema, ma in realtà, quando si utilizza Visual Studio e il designer xaml, ci sono problemi. Errori positivi rilevati dal progettista a causa del fatto che i metodi non sono pubblici, le proprietà del controllo utente non sono visibili al progettista. Non so se altri siano già caduti su tali problemi ...

Answer 9

Dovresti provare a renderli solo il più visibili possibile, ma come affermato da Mike sopra, questo causa problemi con UserControls e l'utilizzo di VS Designer con quei controlli su form o altri UserControls.

Quindi, come regola generale, mantieni tutte le classi e i controlli utente che non stai aggiungendo usando il Designer solo come visibili come devono essere. Se stai creando un UserControl che desideri utilizzare in Designer (anche se si trova all'interno dello stesso assembly) dovrai assicurarti che la classe UserControl, il suo costruttore predefinito e tutte le proprietà e gli eventi siano resi pubblici per il designer lavorare con esso.

Di recente ho avuto un problema a causa del quale il progettista continuava a rimuovere la linea this.myControl = new MyControl () dal metodo InitializeComponent () perché UserControl MyControl era contrassegnato come interno insieme al suo costruttore.

Penso che sia davvero un bug perché anche se sono contrassegnati come interni, vengono comunque visualizzati nella Casella degli strumenti per essere aggiunti in Designer, o Microsoft deve mostrare solo i controlli pubblici con i costruttori pubblici o devono farlo funzionare con anche controlli interni.

Answer 10

Dipende da quanto controllo hai sul codice che lo consuma. Nel mio sviluppo Java, rendo tutte le mie cose pubbliche per impostazione predefinita perché i getter sono fastidiosi. Tuttavia, ho anche il lusso di poter cambiare qualsiasi cosa nella mia base di codice ogni volta che voglio. In passato, quando dovevo rilasciare codice per i consumatori, ho sempre usato variabili e getter privati.

Answer 11

Non scegliere un " default " scegli ciò che meglio si adatta alle esigenze di visibilità per quella particolare classe. Quando scegli una nuova classe in Visual Studio, il modello viene creato come:

class Class1
{
}

Che è privato (poiché non viene specificato alcun ambito). Spetta a te specificare l'ambito per la classe (o lasciare come privato). Dovrebbe esserci un motivo per esporre la classe.

Answer 12

Mi piace esporre le cose il meno possibile. Privato, protetto, interno, pubblico: dai a classi, variabili, proprietà e funzioni il minor grado di visibilità di cui hanno bisogno affinché tutto funzioni ancora.

Aumenterò la visibilità di qualcosa su quella catena verso il pubblico solo quando c'è una buona ragione per

Answer 13

Finora non sono completamente d'accordo con le risposte. Ritengo che internal sia un'idea orribile, che impedisce a un altro assembly di ereditare i tipi o addirittura di utilizzare i tipi interni in caso di necessità di una soluzione alternativa.

Oggi, ho dovuto usare la riflessione per raggiungere gli interni di una System.Data.DataTable (devo costruire un lampo databile veloce, senza tutti i suoi controlli), e ho dovuto usare la riflessione, poiché non un solo tipo era disponibile per me; erano tutti contrassegnati come interni.

Answer 14

per impostazione predefinita, la classe viene creata come interna in c #:  mezzi interni: l'accesso è limitato all'assemblea corrente.

vedi http://msdn.microsoft.com/en-us/library/0b0thckt.aspx

Articolo valido l'ambito delle impostazioni predefinite è interno: http: //www.c-sharpcorner. com / UploadFile / 84c85b / default-scope-of-aC-Sharp-class /