none
Methode d'extension: bon et mauvais usage RRS feed

  • Discussion générale

  • Bonsoir,

    Je cite: http://msdn.microsoft.com/fr-fr/library/bb383977.aspx

    "Les méthodes d'extension vous permettent d'ajouter des méthodes à des types existants sans créer un type dérivé, recompiler ou modifier le type d'origine."

    Donc en règle générale on doit pouvoir se passer de ces méthodes. Et il me semble preferable de cantoner ce que font ces methodes a des traitements légers (calculs, formatage de chaines, recup de donnée en memoire, ...)

    J'ai pour ma part vu dans du code une utilisation qui me semble mauvaise :

    une liste d'objet (List<monObjet> mesObjets) avec une methode d'extension qui réalise un traitement bdd : mesObjets.MAJBdd(); avec de plus une signature de methode avec 5 ou 6 parametres...

    Vos avis sur ce cas précis et plus généralement sur le bon et mauvais usage des methodes d'extension ?

    PS: dans le cas que je cite, il me semble preferable d'avoir une classe d'instance (plutot que la methode d'extension statique) dédiée au traitement des types monObjet qui fera parmis d'autres traitements possible la mise a jour bdd d'un ensemble de type monObjet. Au dela de l'utilisation de la methode d'extension il y a un probleme de conception et de decoupage OO.

     

     

     


    Sinn'
    mercredi 5 janvier 2011 21:21

Toutes les réponses

  • Bonjour,

    Une méthode d'extension n'est autre qu'une méthode statique, c'est juste l'appel qui diffère. Par exemple, soit la méthode d'extension suivante :

    public static class MesExtensions
    {
      public static void Afficher(this int nombre)
      {
        Console.WriteLine(nombre);
      }
    }
    

    Il est possible d'appeler cette méthode suivant ces 2 façons :

    int i = 10;
    
    i.Afficher();
    MesExtensions.Afficher(i);
    

    Contrairement aux idées reçu, les méthodes d'extensions ne rajoute pas de méthodes à une classe et ne peuvent accéder aux membres non publiques.
    Les méthodes d'extensions sont conçues pour rajouter des fonctionnalités manquantes à une classe déjà codée ou à des interfaces.

    Pour moi :
    De manière générale, une méthode d'extensions "spécifique" ne doit pas être ajoutée à une classe trop "générale". Par exemple, ajouter une méthode MAJBdd(), RefreshBDD(),...etc à une List<T> est une grosse erreur ! En effet, les méthodes précédentes sont spécifiques à votre application (en particulier à une partie de votre application) alors que la classe List<T> est "générale" (et forcement utilisée dans toute votre application).
    Par contre, ajoutez une méthode d'extension InsertFromOtherList(List<T>) à List<T> à tout son sens. En effet, la méthode travaille est "générale" et peut-être réutilisée dans toute l'application.

    Est-ce que cela éclaire votre lanterne ?

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte .NET/Consultant/Formateur chez Winwise
    Blog : http://gilles.tourreau.fr
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5
    mercredi 5 janvier 2011 21:55
    Modérateur
  • Merci pour cette rapide synthese qui fera office de rappel general sur les methode d'extension.

    Cela confirme surtout ce que je pensais sur le code que j'ai vu (qui n'est pas de moi!), meme si dans l'absolu rien n'empeche de faire cela !

    J'essaie de remettre dans le droit chemin un jeune padawan un peu têtu !

     

    D'autres avis (Gilles et Alex semblent etre les seuls hyperactifs de ce forum ! Merci a vous 2 en tout cas)

     


    Sinn'
    mercredi 5 janvier 2011 22:15
  • Bonjour,

    Comme dit la doc "Les méthodes d'extension vous permettent d'ajouter des méthodes à des types existants sans créer un type dérivé, recompiler ou modifier le type d'origine."

    Je lis presque cela comme "quand vous ne disposez pas du code source (ce qui correspond aux cas 2 et 3) ET quand créer un type dérivé serait trop long voire ne permettrait pas de répondre au besoin (ce qui exclut le cas 1)"

    Si on a le code source je ne vois pas l'intérêt.

    Sur le plan du principe ce n'est plus ni moins qu'une modernisation du Helper.Extension(o) en o.Extension avec l'avantage de rendre le "helper" plus facilement découvrable via intellisense.

    Mon cas d'école serait par exemple d'"enrichir" un type du .NET Framework qui serait déjà lui-même retourné par d'autres classes du .NET Framework (ce qui entrave la solution consistant à créer un nouveau type).

     


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    jeudi 6 janvier 2011 18:33
    Modérateur