ProgrammationDéveloppeur VB.NET Middle/Lead

Expliquez comment fonctionne le modificateur d'accès Friend en Visual Basic, donnez un exemple de son utilisation et indiquez les situations dans lesquelles Friend est préférable à d'autres modificateurs.

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse.

Le modificateur Friend en Visual Basic définit qu'un membre de la classe (méthode, propriété, variable) est accessible à l'intérieur d'un même assembly, mais pas à l'extérieur de cet assembly. C'est l'équivalent de internal en C#. Ce niveau d'accès est utile pour garantir la "cachabilité" de l'implémentation interne du code tout en gardant des API publiques ouvertes.

Exemple d'utilisation :

' À l'intérieur d'un même projet/assembly Friend Class InternalHelper Friend Sub Log(message As String) Console.WriteLine(message) End Sub End Class

L'appel des méthodes de la classe InternalHelper ne sera possible que dans le cadre de l'assembly actuel.

Quand appliquer Friend :

  • Pour des classes/méthodes qui doivent être accessibles à d'autres parties de l'application, mais pas aux modules/bibliothèques externes.
  • Pour la mise en œuvre de modèles d'accès (par exemple, le test de composants internes).

Question piège.

Quelle est la différence entre le modificateur d'accès Friend et Protected ? Un méthode déclarée comme Friend peut-elle être visible dans une classe héritée d'un autre assembly ?

Réponse :

  • Friend — accessible uniquement à l'intérieur de son assembly (indépendamment de l'héritage).
  • Protected — accessible uniquement dans les classes héritées (indépendamment de l'assembly).
  • Une méthode avec un niveau Friend sera inaccessible aux classes héritées situées en dehors de l'assembly actuel. Si un accès est nécessaire à la fois en héritage et dans l'assembly — utiliser Protected Friend.
Protected Friend Sub MyMethod() ' Accessible à l'intérieur de l'assembly et pour les héritiers en dehors de l'assembly End Sub

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet.


Histoire

Dans un grand projet, toute la logique des classes de support avait été déclarée comme Public, ce qui les ouvrait aux intégrateurs externes. Le passage à Friend a éliminé le risque d'utilisation des méthodes internes en dehors du module et a simplifié l'entretien de l'architecture.


Histoire

En raison d'une erreur d'accès (utilisation de Protected au lieu de Friend), les méthodes auxiliaires étaient inaccessibles pour les tests unitaires, situés dans le même projet, mais en dehors de la hiérarchie des classes. Corrigé en Friend pour faciliter le test approprié.


Histoire

Un développeur a essayé d'utiliser Friend pour exposer des méthodes à un plug-in chargé depuis un autre assembly. En conséquence, les plug-ins n'avaient pas accès aux méthodes nécessaires. La solution consiste à implémenter des interfaces avec des méthodes Public, Friend à n'utiliser que pour des besoins internes.