2009-04-02 10 views
78
internal class Foo 
{ 
    public void Fee() 
    { 
    Debug.WriteLine("Fee"); 
    } 

    internal void Fi() 
    { 
    Debug.WriteLine("Fi"); 
    } 
} 

Penso che Fee() e Fi() siano ugualmente accessibili poiché l'intera classe è già interna. Sto trascurando qualcosa? C'è qualche motivo per scegliere pubblico o interno per i metodi in un caso come questo?metodi public vs. internal su una classe interna

+1

@EricLippert ha scritto la sua opinione oggi. http://ericlippert.com/2014/09/15/internal-or-public/#more-2353 – ScottS

risposta

94

La dichiarazione internal class Foo annullerà l'accessibilità del metodo public void Fee(), rendendolo effettivamente interno.

In questo caso, l'utilizzo interno e pubblico dei metodi avrà lo stesso effetto. L'unico motivo per cui sceglierei metodi pubblici rispetto a metodi interni in un caso come questo sarebbe quello di facilitare la transizione a una classe pubblica in una versione futura, se si sceglie di farlo.

+2

+1 I miei pensieri esattamente! – si618

2

In base allo msdn documentation la classe Foo non sarà accessibile al di fuori dell'assieme, quindi non fa alcuna differenza per contrassegnare i metodi come interni o pubblici; non fa nemmeno la differenza usando l'attributo InternalsVisibleTo

6

Sei corretto, sia Fee che Fi saranno ugualmente accessibili.

dalla descrizione CSharp lingua 3.0, sotto 3.5.2:

Il dominio di accessibilità di un nidificata membro M dichiarato in un tipo T all'interno di un programma P è definito come segue (osservando che M si può eventualmente essere un tipo):

• Se la dichiarata l'accessibilità di M è pubblico, il dominio accessibilità del M è il dominio accessibilità dei T.

Quindi, anche se Fee è dichiarato pubblico, sarà accessibile come Foo (ad es. interno).

25

In realtà, c'è una grande differenza se si utilizza la riflessione; in particolare, Silverlight può diventare molto turbato se si prova ad accedere ai metodi interni tramite reflection, anche se si avrebbe avuto accesso. Ho visto occasioni in cui ho dovuto rendere pubblico un metodo per far funzionare il codice su Silverlight, anche se funziona su .NET regolari.

Si potrebbe trovare lo stesso con parziale fiducia in .NET regolare.

+3

Questi sono i dettagli sporchi a cui sono sempre interessato. Sebbene, in generale, se qualcuno sta usando la riflessione per accedere ai membri nascosti nelle mie lezioni, non mi preoccupo se è difficile per loro. – ScottS

+1

@ScottS: a volte rifletti sui tuoi * propri * tipi, ad esempio dove normalmente avresti accesso al metodo interno, ma all'improvviso non lo fai. –

32

L'unica cosa che manca qui nella risposta è perché lo faresti?

Alcune librerie hanno molte classi che non sono destinate al consumatore della libreria da toccare ma devono ereditare interfacce contrassegnate come pubbliche. Ad esempio, ho una libreria con una classe che eredita l'interfaccia IComparer, ma è usata solo internamente e non voglio ingombrare l'aspetto pubblico della mia libreria. Se contrassegno la funzione di confronto implementata come interna, il compilatore si lamenta che non sto impiantando l'interfaccia IComparer.

Quindi, come posso implementare correttamente l'interfaccia e allo stesso tempo impedire che sia accessibile nell'aspetto pubblico della mia libreria? Segna la classe come interna ma la funzione implementata come pubblica.

0

Vorrei andare con solo metodi interni se una classe è interna. nel caso in cui cambi idea e rendi pubblica la classe, puoi semplicemente sostituire il testo e il gioco è fatto.

7

Farebbe la differenza quando si desidera che la classe interna implementa un'interfaccia. Il metodo che è un'implementazione di qualche interfaccia, dovrebbe essere Pubblico.

Problemi correlati