ProgrammationDéveloppeur VB.NET / Développeur de bibliothèques

Comment implémenter, vérifier et limiter l'accès aux méthodes et aux champs privés (private) et protégés (protected) dans Visual Basic ? Quelles sont les particularités d'accès au sein d'une même classe, des classes dérivées et d'autres assemblies ?

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse.

Historique de la question

L'encapsulation est l'un des piliers de la programmation orientée objet, et elle est atteinte grâce à des modificateurs d'accès, tels que Private et Protected. Dans les versions classiques de Visual Basic, seuls les niveaux de visibilité les plus simples étaient supportés, mais avec la transition vers VB.NET, des mécanismes modernes, similaires à ceux de C#, ont fait leur apparition.

Problème

L'objectif principal est d'isoler les détails internes de l'implémentation du code externe, y compris des autres parties du programme. Les erreurs typiques sont liées à un niveau d'accès incorrect, à des tentatives d'accès à des champs et à des méthodes en dehors de la portée autorisée ou à une mauvaise compréhension du comportement des modificateurs Protected et de leur combinaison avec d'autres modificateurs.

Solution

Les modificateurs suivants sont supportés :

  • Private — accès uniquement à l'intérieur de la classe/module actuel
  • Protected — accès à l'intérieur de la classe actuelle et de tous les héritiers (même provenant d'autres assemblies)
  • Friend — accès à l'intérieur d'une même assembly
  • Protected Friend — accès au sein des héritiers ou à l'intérieur de l'assembly

Exemple de code :

Public Class BaseClass Private Sub PrivateMethod() Console.WriteLine("PrivateMethod") End Sub Protected Sub ProtectedMethod() Console.WriteLine("ProtectedMethod") End Sub Friend Sub FriendMethod() Console.WriteLine("FriendMethod") End Sub Protected Friend Sub ProtectedFriendMethod() Console.WriteLine("ProtectedFriendMethod") End Sub End Class Public Class DerivedClass Inherits BaseClass Public Sub AccessMethods() 'PrivateMethod() 'Erreur de compilation ProtectedMethod() 'Ok FriendMethod() 'Ok, si dans la même assembly ProtectedFriendMethod() 'Ok End Sub End Class

Caractéristiques clés :

  • Le modificateur Private limite la portée à celle de la classe
  • Protected fonctionne dans toutes les classes dérivées dans n'importe quelle assembly
  • Protected Friend combine les deux règles

Questions pièges.

Peut-on accéder à un champ private depuis une classe dérivée ?

Non, les membres privés sont toujours accessibles uniquement dans la classe où ils sont déclarés. Une classe dérivée n'a pas accès aux membres privés même par réflexion (à moins d'utiliser des méthodes non standard).

Quelle est la différence entre Protected et Protected Friend ?

Protected — accessible uniquement depuis la classe et ses descendants, même dans d'autres assemblies ; Protected Friend — accessible soit depuis des classes dérivées, soit depuis n'importe quel code à l'intérieur de la même assembly.

Peut-on appeler une méthode protégée d'une classe via une instance de la classe de base ?

Non, même si la méthode protégée est visible publiquement dans l'héritier, elle ne peut pas être appelée sur une instance de la classe de base depuis du code externe. Les méthodes protégées ne sont accessibles que dans le corps de la classe elle-même ou de l'héritier.

Erreurs typiques et anti-patterns

  • Ouvrir toutes les méthodes comme publiques ou amis pour aller vite
  • Utiliser des champs protégés là où des propriétés privées devraient être utilisées
  • Violations de l'encapsulation dues à un accès excessivement large

Exemple de la vie réelle

Cas négatif

Un développeur, pour simplifier les tests, rend des champs internes publics afin de les accéder directement depuis du code externe ou des tests unitaires. Avec le temps, d'autres appels commencent à utiliser ces champs, s'appuyant sur leur structure interne.

Avantages :

  • Test rapide
  • Moins de code pour accéder aux données

Inconvénients :

  • Faible encapsulation
  • Augmentation des bugs lors des changements de l'implémentation interne
  • Complexité à modifier la classe

Cas positif

Les modificateurs d'accès sont clairement appliqués, tous les champs sont par défaut privés, l'accès externe n'est possible que via des propriétés et des méthodes publiques. Pour les besoins des tests, des interfaces ou des classes amies dans la même assembly sont utilisées.

Avantages :

  • Protection des données internes
  • Possibilité de mettre à jour facilement l'implémentation sans risque pour les clients
  • Architecture flexible

Inconvénients :

  • Parfois, un code supplémentaire est nécessaire (get/set)
  • Nécessité d'organiser l'accès pour les tests via friend/internal