Risposta.

In Visual Basic, il livello di accesso "protected" (Protected) è destinato all'incapsulamento: consente ai membri della classe di essere accessibili solo all'interno della stessa classe e delle sue derivate. Questo è importante sia per l'organizzazione dell'architettura OOP che per limitare l'accesso diretto all'implementazione interna dell'oggetto.

Storicamente, nel classico VB6, tale flessibilità era quasi assente, mentre a partire da VB.NET sono stati aggiunti modificatori di accesso completi, conformi agli standard moderni di OOP.

Problema

Un errore nell'organizzazione dell'accesso può portare a un uso improprio delle proprietà o dei metodi della classe e, potenzialmente, a una violazione dell'incapsulamento. Ad esempio, un metodo pubblico (Public) sarà accessibile a tutti, comprese le componenti esterne, mentre protected limita l'accesso alle derivate.

Soluzione

In VB.NET sono disponibili i modificatori Protected, Protected Friend e Private. Protected è visibile solo all'interno della classe e delle sue successioni, Protected Friend è visibile all'interno dell'assembly e delle successioni, Private è visibile solo all'interno della classe dichiarata.

Esempio di codice:

Public Class Animal
    Protected Sub Eat()
        Console.WriteLine("Eating...")
    End Sub
    Private Sub Sleep()
        Console.WriteLine("Sleeping...")
    End Sub
End Class

Public Class Dog
    Inherits Animal
    Public Sub PerformEat()
        Eat() ' Accessibile: Protected
    End Sub
    ' Sleep() non è accessibile: Private
End Class

Caratteristiche chiave:

Il modificatore Protected limita l'accesso a un membro della classe solo alla classe stessa e alle sue derivate.
Protected Friend estende la visibilità a tutto l'assembly e alle derivate.
Private chiude completamente l'elemento all'interno della classe.

Domande insidiose.

Può il modificatore Protected garantire la visibilità di un membro della classe per tutte le classi nell'assembly?

No, solo per la propria classe e le sue derivate. Protected Friend è per la classe, le sue derivate e tutte le classi nell'assembly.

È possibile specificare esplicitamente che una proprietà è visibile solo per le classi figlie al di fuori dell'assembly, ma non all'interno dell'assembly?

No, non esiste tale livello. Protected Friend divide la visibilità tra derivate e assembly contemporaneamente, ma non è possibile separare queste aree.

Se in una classe base un metodo è definito come Protected, può essere sovrascritto come Public in una classe derivata?

No, il livello di accesso può solo essere mantenuto o ampliato rigorosamente verso il basso, ma non ristretti; l'ampliamento dell'accesso viola i principi di incapsulamento. In .NET, il compilatore genererà un errore se si tenta di restringere l'accesso.

Errori tipici e anti-pattern

Uso di Public per metodi/campi che non dovrebbero essere accessibili dall'esterno.
Applicazione errata di Protected Friend invece di Protected e esportazione accidentale di logica sensibile all'esterno.
Non utilizzare affatto i modificatori di accesso (per impostazione predefinita, gli elementi sono Public).

Caso dalla vita reale

Caso negativo

Un sviluppatore principiante ha dichiarato metodi interni della logica di business come Public. Dopo un po', durante l'aggiornamento del programma, sono comparsi molti bug a causa dell'accesso incontrollato a questi metodi da parte di componenti esterne.

Vantaggi:

Semplicità di implementazione — non è necessario pensare all'accesso.

Svantaggi:

Violazione della sicurezza e dell'incapsulamento.
Logica compromessa durante il refactoring o l'aggiornamento.

Caso positivo

Un programmatore esperto utilizza Protected e Private, separa le aree di responsabilità tra classi genitore e figlio. Questo significa che gli aggiornamenti non influiscono sulle API esterne, riducendo il numero di bug.