Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Méthodes d’extensions: attention aux surprises 1/2

J’ai eu une drôle de surprise l’autre jour. Pour simplifier voici le code suivant:

Une petite API:

using System;
using System.Data.SqlClient;

namespace ConsoleApplication32
{
    static class DBUtil
    {
        public static SqlConnection OpenConnection()
        {
            var ret = new SqlConnection("Mon serveur DB");
            ret.Open();
            return ret;
        }
    }
}

Une extension:

  
using System;

namespace System.Data.SqlClient
{
    private static class Extentions
    {
        public static void DoSomething(this SqlConnection cnx)
        {
           // mon super code

        }
    }
}

Et le code:

  
using System;

namespace ConsoleApplication32
{
    class Program
    {
        static void Main(string[] args)
        {
            var cnx = DBUtil.OpenConnection();
        }
    }
}

Avec cela théoriquement, je m’attendais à voir apparaître ma méthode d’extension dans la liste fournie par Intellisense. En fait non!

image

En regardant de plus près la réponse est simple: la méthode d’extension est déclarée dans un certain espace de nom: “System.Data.SqlClient” mais qui n’est pas utilisée dans mon code. En effet, je n’ai pas eu besoin de l’utiliser car je n’ai pas eu à déclarer le type grâce au mot clé var: je laisse le compilateur le soin de compléter. Comme l’espace de nom n’est pas renseigné, Intellisense ne vas pas chercher les extensions donc ma méthode n’apparaît pas. Une fois l’espace de nom renseigné, tout revient “à la normale”:

image

Dans le prochain billet, nous allons voir que cela peut aussi se produire sans “var”!

Publié mardi 29 septembre 2009 09:00 par Miiitch
Classé sous :
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

# re: Méthodes d’extensions: attention aux surprises 1/2

Hum,

personnellement ce comportement ne me surprend pas... :op

L'unique pré-requis pour utiliser une méthode d'extension, c'est d'ajouter un "using" sur le namespace contenant la méthode d'extension (que ce soit ou non le même que celui du type sur lequel s'applique la méthode).

Du coup utiliser "var" ou "System.Data.SqlClient.DBUtil" ne suffit pas à permettre la détection de la méthode d'extension...

En mettant la méthode d'extension dans un autre namespace (disons "MyNamespace"), on conserve bien le même comportement : pour que ça marche, il suffira alors de mettre le using sur "MyNamespace" (et du coup pas besoin de mettre le using sur "System.Data.SqlClient.DBUtil")

mardi 29 septembre 2009 10:32 by Troborg

# re: Méthodes d’extensions: attention aux surprises 1/2

Attention avec les namespaces des methodes d'extension, je pense qu'il vaut mieux eviter d'utiliser System.* pour 2 raisons :

Il se peut que Microsoft decide d'ajouter le meme nom de methode dans une version ultérieure (bug assuré).

Si une deuxième assembly possède la meme methode d'extension avec le meme namespace (bug assuré).

mardi 29 septembre 2009 20:50 by mchouteau

# re: Méthodes d’extensions: attention aux surprises 1/2

Je dirais que ca dépend aussi de la façon dont la méthode va être utilisée. Pour une extension d'une interface ca me dérange pas si la méthode est cohérente avec la fonction de l'interface. De toute façon si une méthode est ajoutée, on aura des surprises dans tous les cas!

J'essaie de le limiter aux interfaces par contre. Je trouve que sur une classe c'est trop ambigüe: soit on peut changer la classe et dans ce cas l'extension ne sert à rien, soit on on ne peut pas changer la classe et l'extension devrait se limiter à ajouter un comportement qui n'est pas forcément en rapport à la classe d'origine. Par exemple, ca m'est arrivé d'ajouter des methodes d'extensions "ToXls()" par exemple pour pouvoir exporter sous Excel des controles winforms. Cela m'a permit m'avoir un comportement unique d'export pour tous les contrôles de l'application (je n'avais pas la possibilité d'étendre autrement les contrôles).

La Framework Design Guideline 2nd edition possède un chapitre entier sur ce thème.

mardi 29 septembre 2009 22:06 by Miiitch
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01