Réponse.

En Visual Basic, le niveau d'accès "protected" (Protected) est destiné à l'encapsulation — il permet aux membres d'une classe d'être accessibles uniquement au sein de la classe elle-même et de ses dérivés. Cela est important tant pour l'organisation de l'architecture OOP que pour limiter l'accès direct à l'implémentation interne d'un objet.

Historiquement, dans le classique VB6, une telle flexibilité n'existait presque pas, tandis qu'à partir de VB.NET, des modificateurs d'accès complets, conformes aux normes modernes de l'OOP, ont été ajoutés.

Problème

Une erreur dans l'organisation de l'accès peut entraîner une mauvaise utilisation des propriétés ou des méthodes de la classe et, potentiellement, à une violation de l'encapsulation. Par exemple, une méthode publique (Public) sera accessible à tous, y compris les composants externes, tandis que protégée limite l'accès aux dérivés.

Solution

Dans VB.NET, les modificateurs Protegé, Protected Friend et Private sont disponibles. Protected est visible uniquement à l'intérieur de la classe et de ses héritiers, Protected Friend — à l'intérieur de l'assemblage (assembly) et des héritiers, Private — uniquement au sein de la classe déclarante.

Exemple de code :

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() ' Accessible : Protected
    End Sub
    ' Sleep() inaccessible : Private
End Class

Caractéristiques clés :

Le modificateur Protected limite l'accès au membre de la classe uniquement à la classe elle-même et à ses héritiers
Protected Friend étend la portée de visibilité à tout l'assemblage et aux héritiers
Private ferme complètement l'élément à l'intérieur de la classe

Questions pièges.

Le modificateur Protected peut-il assurer la visibilité d'un membre de la classe à toutes les classes de l'assemblage ?

Non, uniquement à la classe elle-même et à ses héritiers. Protected Friend — pour la classe, ses héritiers et toutes les classes de l'assemblage.

Est-il possible de spécifier explicitement qu'une propriété est visible uniquement pour les classes dérivées en dehors de l'assemblage, mais pas dans l'assemblage ?

Non, il n'existe pas de tel niveau. Protected Friend divise la visibilité entre les héritiers et l'assemblage en même temps, mais il n'est pas possible de séparer ces domaines.

Si dans la classe de base une méthode est définie comme Protected, peut-elle être redéfinie comme Public dans la classe dérivée ?

Non, le niveau d'accès ne peut être que conservé ou élargi strictement vers le bas, mais pas réduit ; étendre l'accès viole les principes d'encapsulation. Dans .NET, le compilateur renverra une erreur si vous essayez de réduire l'accès.

Erreurs typiques et anti-patterns

Utilisation de Public pour des méthodes/champs qui ne doivent pas être accessibles de l'extérieur
Application erronée de Protected Friend au lieu de Protected et exportation accidentelle de logique sensible vers l'extérieur
Non-utilisation des modificateurs d'accès (par défaut, les éléments sont Public)

Exemple de la vie réelle

Cas négatif

Un développeur novice a déclaré des méthodes internes de logique métier comme Public. Après un certain temps, lors de la mise à jour du programme, de nombreux bugs sont apparus à cause d'un accès incontrôlé à ces méthodes par des composants tiers.

Avantages :

Facilité d'implémentation — pas besoin de penser à l'accès

Inconvénients :

La sécurité et l'encapsulation sont compromises
La logique se brise lors du refactoring ou de la mise à jour

Cas positif

Un programmeur expérimenté utilise Protected et Private, séparant les zones de responsabilité entre les classes parentes et dérivées. Grâce à cela, les mises à jour n'affectent pas les API externes, le nombre de bugs est réduit.