Odpowiedź.

W Visual Basic poziom dostępu "protected" (Protected) służy do enkapsulacji — pozwala na dostęp do członków klasy tylko w samej klasie i jej dziedziczących klasach. Jest to istotne zarówno dla organizacji architektury OOP, jak i dla ograniczenia bezpośredniego dostępu do wewnętrznej implementacji obiektu.

Historycznie w klasycznym VB6 nie było takiej elastyczności, a od momentu wprowadzenia VB.NET dodano pełnoprawne modyfikatory dostępu odpowiadające nowoczesnym standardom OOP.

Problem

Błąd w organizacji dostępu może prowadzić do niewłaściwego wykorzystania właściwości lub metod klasy i, potencjalnie, do naruszenia enkapsulacji. Na przykład, otwarta metoda (Public) będzie dostępna dla wszystkich, łącznie z zewnętrznymi komponentami, podczas gdy chroniona ogranicza dostęp do klas pochodnych.

Rozwiązanie

W VB.NET dostępne są modyfikatory Protected, Protected Friend i Private. Protected jest widoczny tylko wewnątrz klasy i jej dziedziców, Protected Friend — wewnątrz zestawu (assembly) oraz dziedziców, Private — tylko w obrębie klasy, która go zadeklarowała.

Przykład kodu:

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() ' Dostępne: Protected
    End Sub
    ' Sleep() niedostępne: Private
End Class

Kluczowe cechy:

Modyfikator Protected ogranicza dostęp do członka klasy tylko do samej klasy i jej dziedziców.
Protected Friend rozszerza zakres widoczności do całego zestawu i dziedziców.
Private całkowicie zamyka element wewnątrz klasy.

Pytania z pułapką.

Czy modyfikator Protected może zapewnić widoczność członka klasy dla wszystkich klas w zestawie?

Nie, tylko dla samej klasy i jej dziedziców. Protected Friend — dla klasy, jej dziedziców oraz wszystkich klas w zestawie.

Czy można wyraźnie wskazać, że właściwość jest widoczna tylko dla klas potomnych spoza zestawu, ale nie w zestawie?

Nie, taki poziom nie istnieje. Protected Friend dzieli widoczność pomiędzy dziedzicami a zestawem jednocześnie, ale nie można oddzielić tych obszarów.

Jeśli w klasie bazowej metoda jest zdefiniowana jako Protected, czy można ją nadpisać jako Public w klasie potomnej?

Nie, poziom dostępu można tylko utrzymać lub rozszerzyć, ale nie zawęzić; rozszerzenie dostępu narusza zasady enkapsulacji. W .NET kompilator zgłosi błąd przy próbie zawężenia dostępu.

Typowe błędy i antywzorce

Używanie Public dla metod/pól, które nie powinny być dostępne na zewnątrz.
Błędne zastosowanie Protected Friend zamiast Protected i przypadkowe eksportowanie wrażliwej logiki na zewnątrz.
Nie używanie modyfikatorów dostępu wcale (domyślnie elementy są Public).

Przykład z życia

Negatywny przypadek

Początkujący programista zadeklarował wewnętrzne metody logiki biznesowej jako Public. Po pewnym czasie, przy aktualizacji programu pojawiło się wiele błędów z powodu niekontrolowanego dostępu do tych metod zewnętrznymi komponentami.

Zalety:

Łatwość realizacji — nie ma potrzeby myśleć o dostępie.

Wady:

Narusza bezpieczeństwo i enkapsulację.
Łamie logikę podczas refaktoryzacji lub aktualizacji.

Pozytywny przypadek

Doświadczony programista używa Protected i Private, dzieli odpowiedzialności między klasy rodzicielskie i potomne. Dzięki temu aktualizacje nie wpływają na zewnętrzne API, zmniejsza się liczba błędów.