Uma propriedade deve ter o mesmo nome que seu tipo?

Eu vi algumas vezes código escrito assim:

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

ou seja, a class B2 tem uma propriedade denominada “B1”, que também é do tipo “B1”.

Meu instinto me diz que isso não é uma boa idéia, mas há alguma razão técnica pela qual você deve evitar dar a propriedade o mesmo nome de sua class?

(Estou usando o .net 2.0, caso isso seja importante).

Está bem. O exemplo canônico aqui é

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

Existem problemas raros (casos de canto) que surgem aqui, mas não o suficiente para justificar evitar este dispositivo. Francamente, acho este dispositivo bastante útil. Eu não gostaria de não poder fazer o seguinte:

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

Eu não quero ter que dizer Ticker StockTicker ou Ticker ThisTicker etc.

O Microsoft Naming Guideline para membros estado:

Considere dar uma propriedade com o mesmo nome do seu tipo.

Quando você tem uma propriedade que é fortemente digitada em uma enumeração, o nome da propriedade pode ser o mesmo que o nome da enumeração. Por exemplo, se você tiver uma enumeração chamada CacheLevel , uma propriedade que retorne um de seus valores também poderá ser denominada CacheLevel .

Embora eu admito que há uma pequena ambigüidade se eles estão apenas recomendando isso para Enums ou para propriedades em geral.

Eu só consigo pensar em uma desvantagem. Se você quisesse fazer algo assim:

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

Em vez disso, você teria que usar:

 MyNamespace.B1.MyFunc(); 

Um bom exemplo disso é o uso comum na programação Winforms, em que a class System.Windows.Forms.Cursor se sobrepõe à propriedade System.Windows.Forms.Form.Cursor, portanto, os events de formulário precisam acessar membros estáticos usando o namespace completo .

Ainda hoje, Eric escreveu sobre o problema “Color Colour”.

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

Pessoalmente, eu iria evitá-lo, se possível.

Não há nenhum problema técnico específico com isso. Pode prejudicar ou melhorar a legibilidade. Na verdade, algumas bibliotecas da Microsoft têm esse tipo de propriedade (especificamente, com propriedades enum , isso geralmente faz sentido).

Outra pegadinha é com tipos internos.

Eu me deparo com isso o tempo todo:

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

Obviamente pode ser um pouco confuso quando o nome de uma propriedade e seu tipo são os mesmos, mas além disso, não é realmente um problema.

Se o nome fizer sentido, geralmente é melhor deixar que o nome e o tipo sejam os mesmos. Se você puder pensar em um nome melhor, você deve obviamente usar isso, mas você não deve tentar criar um nome a qualquer custo apenas para evitar essa situação.

Esse padrão comum é uma das razões pelas quais eu sempre uso this ao me referir a um membro de instância dentro de uma class. por exemplo, sempre

 this.SomeMethod(this.SomeProperty); 

e nunca

 SomeMethod(SomeProperty); 

Na maioria dos casos, não há qualquer ambiguidade real, mas acho que ajuda a esclarecer as coisas. Além disso, agora você sabe onde a propriedade / método está definida.

Eu dou as coisas o mesmo nome do seu tipo, exceto no caso: meus methods e propriedades são “lowerCase”; e eu, portanto, não teria o problema que MiffTheFox tem.

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

Então, para mim, m_b1 é dado de membro, b1 é uma propriedade (ou uma variável ou parâmetro local) e B1 é o nome da class.