c# - programming - hungarian notation

¿Debería una propiedad tener el mismo nombre que su tipo?

Question

A veces he visto un código escrito así:

public class B1
{
}
public class B2
{
private B1 b1;
public B1 B1
{
get { return b1; }
set { b1 = value; }
}
}

es decir, la clase B2 tiene una propiedad llamada "B1", que también es de tipo "B1".

Mi instinto me dice que esto no es una buena idea, pero ¿existen razones técnicas por las que debería evitar darle a una propiedad el mismo nombre que su clase?

(Estoy usando .net 2.0, en caso de que eso importe).

Answer 1

Doy a las cosas el mismo nombre que su tipo, excepto en el caso: mis métodos y propiedades son "lowerCase"; y por lo tanto no tendría el problema que tiene MiffTheFox.

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
}
}

Entonces, para mí, m_b1 son datos de miembros, b1 es una propiedad (o una variable o parámetro local) y B1 es el nombre de la clase.

Answer 2

Está bien. El ejemplo canónico aquí es

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

Hay problemas raros (casos de esquina) que surgen aquí, pero no lo suficiente como para justificar evitar este dispositivo. Francamente, encuentro este dispositivo bastante útil. No me gustaría poder no hacer lo siguiente:

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

No quiero tener que decir Ticker StockTicker o Ticker ThisTicker etc.

Answer 3

Este patrón común es una de las razones por las que siempre lo uso al referirme a un miembro de instancia dentro de una clase. por ejemplo siempre

this.SomeMethod(this.SomeProperty);

y nunca

SomeMethod(SomeProperty);

En la mayoría de los casos, no hay ninguna ambigüedad real, pero me parece que ayuda a aclarar las cosas. Además, ahora sabe dónde se define la propiedad / método.

Answer 4

Hoy mismo, Eric escribió en su blog sobre el problema ''Color Color''.

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

Personalmente, lo evitaría si fuera posible.

Answer 5

La guía de nomenclatura de Microsoft para miembros establece:

Considere dar a una propiedad el mismo nombre que su tipo.

Cuando tiene una propiedad que está fuertemente tipada en una enumeración, el nombre de la propiedad puede ser el mismo que el de la enumeración. Por ejemplo, si tiene una enumeración llamada CacheLevel , una propiedad que devuelve uno de sus valores también se puede CacheLevel .

Aunque admito que hay un poco de ambigüedad si solo recomiendan esto para Enums o para propiedades en general.

Answer 6

No hay ningún problema técnico específico con eso. Podría dañar o mejorar la legibilidad. De hecho, algunas bibliotecas de Microsoft tienen este tipo de propiedades (específicamente, con propiedades de enum , esto generalmente tiene sentido).

Answer 7

Obviamente, puede ser un poco confuso cuando el nombre de una propiedad y su tipo son los mismos, pero aparte de eso no es realmente un problema.

Si el nombre tiene sentido, generalmente es mejor dejar que el nombre y el tipo sean los mismos. Si puede pensar en un nombre mejor, debería usarlo, por supuesto, pero no debe intentar inventar un nombre a toda costa solo para evitar esta situación.

Answer 8

Otro gotcha es con tipos internos.

Me encuentro con este todo el tiempo

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;
}
}

Answer 9

Sólo puedo pensar en un inconveniente. Si quisieras hacer algo como esto:

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();
}
}

Tendrías que usar en su lugar:

MyNamespace.B1.MyFunc();

Un buen ejemplo de esto es el uso común en la programación de Winforms, donde la clase System.Windows.Forms.Cursor se superpone con la propiedad System.Windows.Forms.Form.Cursor, por lo que los eventos de formulario tienen que acceder a miembros estáticos utilizando el espacio de nombres completo .