Réponse.

L'apparition des méthodes d'extension est liée à la nécessité d'ajouter de nouvelles fonctions aux types de données déjà existants (en particulier ceux des bibliothèques et externes), sans modifier le code source de ces types. Cela est particulièrement pertinent dans les applications modernes .NET, où des commodités supplémentaires sont nécessaires, mais où l'accès à la modification des classes de base n'est pas possible.

Le problème résidait dans l'impossibilité d'étendre les types sans créer des héritiers ou des enveloppes, ce qui compliquait l'architecture et entraînait un héritage « faux ».

La solution est les méthodes d'extension. En Visual Basic, elles sont déclarées comme des modules avec des méthodes statiques marquées par l'attribut <Extension>. Le premier paramètre de la méthode indique toujours le type extensible, ce qui permet d'appeler la méthode comme un membre ordinaire de l'objet.

Exemple de code :

Imports System.Runtime.CompilerServices

Module StringExtensions
    <Extension>
    Public Function ToTitleCase(ByVal str As String) As String
        If String.IsNullOrEmpty(str) Then Return str
        Return Char.ToUpper(str(0)) & str.Substring(1).ToLower()
    End Function
End Module

' Utilisation :
Dim s As String = "visual basic"
Console.WriteLine(s.ToTitleCase()) ' Visual basic

Caractéristiques clés :

Les méthodes d'extension sont visibles et accessibles comme des méthodes d'instance des classes.
Elles ne violent pas le principe de l'encapsulation des types cibles.
Elles ne conviennent que pour des méthodes statiques dans des modules.

Questions pièges.

Peut-on accéder à une méthode d'extension par le nom de la classe, plutôt que par une instance ?

Oui, la méthode d'extension peut être appelée par le nom de la classe d'extension comme une méthode statique, simplement en spécifiant explicitement le premier paramètre (this/Me).

Exemple de code :

StringExtensions.ToTitleCase("test string")

Peut-on redéfinir le comportement des méthodes système via les méthodes d'extension ?

Non, les méthodes d'extension ne redéfinissent pas les méthodes d'instance existantes. En cas de conflit de noms, la méthode d'origine du type sera appelée.

Les méthodes d'extension peuvent-elles avoir un nombre variable d'arguments (ParamArray), par exemple, pour des chaînes ?

Oui, on peut utiliser ParamArray dans les méthodes d'extension, tout comme dans des méthodes statiques ordinaires.

Erreurs standard et anti-modèles

Ils oublient d'importer le module d'extension via Imports, ce qui rend les méthodes invisibles.
Ils n'utilisent pas de vérifications sur null/empty pour les chaînes.
Ils donnent des noms de méthodes trop généraux ou conflictuels, ce qui peut créer de la confusion.

Exemple de la vie réelle

Cas négatif

Dans un grand projet, pour chaque type, des méthodes d'extension propres sont créées avec des noms en conflit et une logique différente, sans style uniforme.

Avantages :

Flexibilité, ne dérange pas la fonctionnalité principale de la classe.

Inconvénients :

Incohérence, augmentation de la complexité du support, collisions de noms fréquentes.

Cas positif

Dans le module, seules des extensions universelles et bien documentées pour les opérations standards sur les types sont rassemblées. Le nom de chaque méthode indique clairement sa destination.