Antwort.

In Visual Basic ist der Zugriffslevel "protected" (Protected) für die Kapselung vorgesehen — er erlaubt den Mitgliedern einer Klasse, nur innerhalb der Klasse selbst und ihrer abgeleiteten Klassen zugänglich zu sein. Dies ist wichtig sowohl für die Organisation der OOP-Architektur als auch zur Begrenzung des direkten Zugriffs auf die interne Implementierung des Objekts.

Historisch gesehen gab es in klassischem VB6 eine solche Flexibilität kaum, doch seit VB.NET wurden vollständige Zugriffsmodifizierer eingeführt, die den modernen OOP-Standards entsprechen.

Problem

Ein Fehler bei der Organisation des Zugriffs kann zu einer unsachgemäßen Nutzung von Eigenschaften oder Methoden der Klasse und potenziell zu einer Verletzung der Kapselung führen. Zum Beispiel ist eine öffentliche Methode (Public) für alle zugänglich, einschließlich externer Komponenten, während der geschützte Zugriffslevel den Zugang für abgeleitete Klassen einschränkt.

Lösung

In VB.NET stehen die Modifizierer Protected, Protected Friend und Private zur Verfügung. Protected ist nur innerhalb der Klasse und ihrer Nachfolger sichtbar, Protected Friend — innerhalb der Assembly und der Nachfolger, Private — nur innerhalb der deklarierenden Klasse.

Beispielcode:

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() ' Verfügbar: Protected
    End Sub
    ' Sleep() nicht verfügbar: Private
End Class

Wesentliche Merkmale:

Der Modifizierer Protected beschränkt den Zugriff auf das Mitglied der Klasse nur auf die Klasse selbst und ihre Nachfolger
Protected Friend erweitert den Sichtbarkeitsbereich auf die gesamte Assembly und deren Nachfolger
Private schließt das Element vollständig innerhalb der Klasse aus

Täuschende Fragen.

Kann der Modifizierer Protected die Sichtbarkeit eines Klassenmitglieds für alle Klassen in der Assembly gewährleisten?

Nein, nur für die Klasse selbst und deren Erben. Protected Friend — für die Klasse, ihre Erben und alle Klassen in der Assembly.

Kann man ausdrücklich angeben, dass eine Eigenschaft nur für abgeleitete Klassen außerhalb der Assembly sichtbar ist, aber nicht innerhalb der Assembly?

Nein, ein solcher Zugriffslevel existiert nicht. Protected Friend teilt die Sichtbarkeit gleichzeitig zwischen Erben und der Assembly, aber diese Bereiche können nicht getrennt werden.

Wenn in der Basisklasse eine Methode als Protected definiert ist, kann sie dann in der abgeleiteten Klasse als Public überschrieben werden?

Nein, der Zugriffslevel kann nur beibehalten oder streng nach unten erweitert werden, aber nicht eingeschränkt; eine Erweiterung des Zugriffs verletzt die Prinzipien der Kapselung. Der .NET-Compiler gibt einen Fehler aus, wenn man versucht, den Zugriff einzuschränken.

Typische Fehler und Anti-Muster

Verwendung von Public für Methoden/Felder, die nicht extern zugänglich sein sollten
Falsche Anwendung von Protected Friend anstelle von Protected und versehentliche Veröffentlichung sensibler Logik nach außen
Überhaupt keine Verwendung von Zugriffsmodifizierern (Standardmäßig sind Elemente Public)

Beispiel aus dem Leben

Negativer Fall

Ein unerfahrener Entwickler deklarierte interne Methoden der Geschäftslogik als Public. Nach einiger Zeit traten beim Upgrade des Programms viele Fehler auf, verursacht durch unkontrollierten Zugriff auf diese Methoden durch externe Komponenten.

Vorteile:

Einfache Implementierung — man muss sich keine Gedanken über den Zugriff machen

Nachteile:

Sicherheits- und Kapselungsprobleme
Die Logik bricht bei Refaktorisierung oder Aktualisierung

Positiver Fall

Ein erfahrener Programmierer verwendet Protected und Private und teilt die Verantwortungsbereiche zwischen übergeordneten und abgeleiteten Klassen. Dadurch beeinflussen Updates nicht die externen APIs, und die Anzahl der Fehler wird reduziert.