2010-03-03 16 views
21

Questo è un extension per questo question chiesto un'ora fa.ignora l'interno protetto con protetto!

Non è possibile modificare access modifiers quando si sostituisce un virtual method nella classe derived. Considerare Control classe nel namespace System.Web.UI

public class Control : IComponent, IDisposable,... 
{ 
    protected internal virtual void CreateChildControls() 
    { } 
    . 
    . 
} 

Ora considerare questo

public class someClass : System.Web.UI.Control 
    { 
     // This should not compile but it does 
     protected override void CreateChildControls() 
     { } 

     // This should compile but it does not 
     protected internal override void CreateChildControls() 
     { } 
    } 

qualsiasi organismo può spiegare questo? Grazie

risposta

43

Non è possibile modificare i modificatori di accesso quando si esegue l'override di un metodo virtuale nella classe derivata.

Questa affermazione è falsa. È possibile e deve modificare i modificatori di accesso quando in esattamente la situazione che descrivi. In altre situazioni non è necessario modificare i modificatori di accesso.

vi rimando alla sezione 10.6.4 della specifica, in cui si afferma:

una dichiarazione di esclusione non può cambiare l'accessibilità del metodo virtuale . Tuttavia, se il metodo di base override è protetta interna ed è dichiarata montaggio diverso rispetto al complesso contenente il metodo sostituzione allora il metodo di sostituzione dichiarato accessibilità deve essere protetto.

Il ragionamento è semplice.

Tu, Asad, hai un conto bancario, BankAccount.

Hai una casa. Affitta una stanza in casa al tuo migliore amico Charlie.

Charlie ha un figlio, David, che vive in un appartamento.

Hai un figlio, Elroy, che vive in un condominio.

Elroy ha un figlio, tuo nipote, Frank, che vive in una Yurta.

Elroy ha un migliore amico Greg che vive nel condominio con lui.

Concedi l'accesso al tuo conto bancario a te stesso, a tutti coloro che vivono in House e ai tuoi discendenti. Quindi le persone che possono accedere al conto in banca sono Asad, Charlie, Elroy e Frank.

David non ha accesso perché non è né tu né il tuo discendente, né vive in House. Che sia figlio del tuo coinquilino è irrilevante; non ha accesso al tuo BankAccount.

Greg non ha accesso al tuo conto bancario. Lui non è il tuo discendente. Lui non vive in casa. Il fatto che viva con il tuo discendente non gli garantisce gli stessi diritti del tuo discendente.

Ora arriviamo al nocciolo della questione. Elroy non può estendere l'accesso a BankAccount a Greg. Tu possiedi quel BankAccount e hai detto "me stesso, i miei discendenti e i miei coinquilini". I tuoi figli non hanno il diritto di estendere l'accessibilità di BankAccount oltre a quanto inizialmente impostato.

Quando Elroy descrive l'accesso che ha a BankAccount, gli è permesso solo dire "Concedo l'accesso a questo a me stesso e ai miei discendenti", perché è quello che hai già permesso. Non può dire "Concedo l'accesso a BankAccount a me stesso, ai miei discendenti e agli altri residenti di Condo".

Giusto per essere chiari:

  • io ei miei discendenti ottenere l'accesso = accesso protetto
  • io ed i miei compagni di casa ottengo accesso = accesso interno
  • io ei miei discendenti ed i miei compagni di casa accedi = protetta accesso interno
  • controllo = Asad
  • CreateChildControls = BankAccount
  • Casa = System.web.dll
  • Charlie = qualsiasi tipo in System.web.dll
  • David = tipo derivato di Charlie in assemblea Apartment.DLL
  • Elroy = someClass
  • Condo = 'assembly contenente SomeClass
  • Greg = qualche altra classe in Condo.DLL
  • Frank = tipo derivato di someClass in Yurt.DLL
  • Yurt = qualche altro gruppo
+0

Quindi, in questa situazione, cosa succede quando un coinquilino di un genitore cerca di accedere a quello che pensa sia il conto bancario del genitore, ma in realtà è un conto bancario di un bambino? IE: Qualcosa in System.Web.DLL prova a chiamare Control.CreateChildControls() (attraverso l'accessibilità interna), ma non ha accesso a someClass.CreateChildControls()? – Tanzelax

+1

Buona analogia ... eccetto che non concederei l'accesso al mio conto bancario a tutti coloro che vivono nella mia casa;) –

+5

@Eric, interessante analogia. Un pensiero - forse cambiando da * "chi può accedere al mio conto in banca" * a * "chi può guidare la mia auto" * può far risuonare l'analogia meglio con le persone. – LBushkin

5

Perché, mentre la terminologia è diversa, ignorandola come protected mantiene la visibilità del membro lo stesso. Se è stato autorizzato a sostituirlo come protected internal, verrà improvvisamente esposto il membro a un altro tipo nell'assembly.

+0

Downvot e cura di spiegare? –

2

Mezzi interni protetti protetti O interni. Quindi, se eseguendo l'override all'esterno dell'assembly originale, fosse consentito contrassegnarlo come protetto internamente, si consentirebbe ad altre classi nello stesso assembly di overrider di chiamare questo metodo. Ciò significherebbe effettivamente che l'incapsulamento interno del genitore originario sarebbe stato violato.