web-dev-qa-db-fra.com

Une propriété doit-elle avoir le même nom que son type?

J'ai parfois vu du code écrit comme ceci:

public class B1
{
}

public class B2
{
    private B1 b1;

    public B1 B1
    {
        get { return b1; }
        set { b1 = value; }
    }
}

c'est-à-dire que la classe B2 a une propriété nommée "B1", qui est également de type "B1".

Mon instinct me dit que ce n'est pas une bonne idée, mais y a-t-il des raisons techniques pour lesquelles vous devriez éviter de donner à une propriété le même nom que sa classe?

(J'utilise .net 2.0, au cas où cela compte).

c#.netnaming-conventions
65
Moe Sisko

C'est bon. L'exemple canonique ici est

public Background {
    public Color Color { get; set; }
}

Il y a de rares problèmes (cas d'angle) qui surviennent ici, mais pas assez pour justifier d'éviter cet appareil. Franchement, je trouve cet appareil assez utile. Je n'apprécierais pas ne pas pouvoir faire ce qui suit:

class Ticker { ... }


public StockQuote {
    public Ticker Ticker { get; set; }
}

Je ne veux pas avoir à dire Ticker StockTicker ou Ticker ThisTicker etc.

61
jason

Microsoft Naming Guideline for Members indique:

Pensez à donner à une propriété le même nom que son type.

Lorsque vous avez une propriété fortement typée sur une énumération, le nom de la propriété peut être le même que le nom de l'énumération. Par exemple, si vous disposez d'une énumération nommée CacheLevel, une propriété qui renvoie l'une de ses valeurs peut également être nommée CacheLevel.

Bien que j'admette, il y a une petite ambiguïté, qu'ils recommandent cela pour les énumérations ou pour les propriétés en général.

16
Dan Diplo

Je ne peux penser qu'à un seul inconvénient. Si vous vouliez faire quelque chose comme ça:

public class B1
{
        public static void MyFunc(){ ; }
}

public class B2
{
        private B1 b1;

        public B1 B1
        {
                get { return b1; }
                set { b1 = value; }
        }

        public void Foo(){
                B1.MyFunc();
        }
}

Vous devez plutôt utiliser:

MyNamespace.B1.MyFunc();

Un bon exemple de cela est une utilisation courante dans la programmation Winforms, où la classe System.Windows.Forms.Cursor chevauche la propriété System.Windows.Forms.Form.Cursor, de sorte que vos événements de formulaire doivent accéder aux membres statiques à l'aide de l'espace de noms complet .

11
MiffTheFox

Aujourd'hui même, Eric a blogué sur le problème de la "Couleur Couleur".

http://blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx

Personnellement, je l'éviterais si possible.

9
SolutionYogi

Un autre problème est avec les types internes.

Je rencontre celui-ci tout le temps:

public class Car {
    public enum Make {
        Chevy,
        Ford
    };

    // No good, need to pull Make out of the class or create
    // a name that isn't exactly what you want
    public Make Make {
        get; set;
    }
}
3
Chris

Il n'y a pas de problème technique spécifique. Cela pourrait endommager ou améliorer la lisibilité. En fait, certaines bibliothèques Microsoft ont ce type de propriétés (en particulier, avec les propriétés enum, cela a généralement du sens).

3
Mehrdad Afshari

Ce modèle courant est l'une des raisons pour lesquelles j'utilise toujours this lorsque je me réfère à un membre d'instance dans une classe. par exemple. toujours

this.SomeMethod(this.SomeProperty);

et jamais

SomeMethod(SomeProperty);

Dans la plupart des cas, il n'y a pas d'ambiguïté réelle, mais je trouve que cela aide à clarifier les choses. De plus, vous savez maintenant où la propriété/méthode est définie.

1
Annabelle

Cela peut évidemment être un peu déroutant lorsque le nom d'une propriété et son type sont les mêmes, mais à part cela, ce n'est pas vraiment un problème.

Si le nom a du sens, il est généralement préférable de laisser le nom et le type identiques. Si vous pouvez penser à un meilleur nom, vous devriez bien sûr l'utiliser, mais vous ne devriez pas essayer de créer un nom à tout prix juste pour éviter cette situation.

1
Guffa

Je donne aux choses le même nom que leur type, sauf pour le cas: mes méthodes et propriétés sont "lowerCase"; et je n'aurais donc pas le problème que MiffTheFox a.

public class B1
{
    public static void myFunc(){ ; }
}

public class B2
{
    private B1 m_b1;

    public B1 b1
    {
        get { return m_b1; }
        set { m_b1 = value; }
    }

    public void Foo()
    {
        B1.myFunc(); //this is Ok, no need to use namespace
    }
}

Donc pour moi, m_b1 correspond aux données des membres, b1 est une propriété (ou une variable ou un paramètre local), et B1 est le nom de la classe.

0
ChrisW