속성의 이름이 유형과 같아야합니까?

속성의 이름이 유형과 같아야합니까?

---

나는 때때로 다음과 같이 작성된 코드를 보았다.

public class B1
{
}

public class B2
{
    private B1 b1;

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

즉, B2 클래스에는 "B1"유형의 "B1"이라는 속성이 있습니다.

내 직감은 이것이 좋은 생각이 아니라고 말하지만 속성에 클래스와 같은 이름을 지정하지 않아야하는 기술적 이유가 있습니까?

(중요한 경우를 대비하여 .net 2.0을 사용하고 있습니다).

---

괜찮아. 여기의 표준 예는

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

여기에 드물게 발생하는 문제 (코너 케이스)가 있지만이 기기를 피할 수는 없습니다. 솔직히이 장치는 매우 유용합니다. 나는 다음을 할 수없는 것을 좋아하지 않을 것이다.

class Ticker { ... }


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

나는 말을하고 싶지 않아요 Ticker StockTicker또는 Ticker ThisTicker등

---

회원에 대한 가이드 라인을 명명 마이크로 소프트 상태 :

속성에 유형과 동일한 이름을 지정하는 것이 좋습니다.

열거 형에 강력하게 입력 된 속성이있는 경우 속성의 이름은 열거 형의 이름과 같을 수 있습니다. 예를 들어라는 열거 형이있는 경우 CacheLevel해당 값 중 하나를 반환하는 속성의 이름도으로 지정할 수 있습니다 CacheLevel.

나는 그들이 Enums 또는 일반적으로 속성에 대해 이것을 권장하는지 여부에 약간의 모호함이 있음을 인정합니다.

---

한 가지 단점 만 생각할 수 있습니다. 다음과 같이하고 싶다면 :

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

대신 다음을 사용해야합니다.

MyNamespace.B1.MyFunc();

이에 대한 좋은 예로는 Winforms 프로그래밍에서 System.Windows.Forms.Cursor 클래스가 System.Windows.Forms.Form.Cursor 속성과 겹치므로 양식 이벤트가 전체 네임 스페이스를 사용하여 정적 멤버에 액세스해야하는 일반적인 사용이 있습니다. .

---

바로 오늘 Eric은 '색상 색상'문제에 대해 블로그에 올렸습니다.

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

Personally, I would avoid it if possible.

---

There's no specific technical problem with it. It might harm or improve readability. In fact, some Microsoft libraries have these kind of properties (specifically, with enum properties, this usually makes sense).

---

Another gotcha is with inner types.

I run into this one all the time:

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

---

It can obviously be a bit confusing when the name of a property and it's type are the same, but other than that it's not really a problem.

If the name makes sense, it's usually better to let the name and the type be the same. If you can think of a better name, you should of course use that, but you should not try to make up a name at any cost just to avoid this situation.

---

This common pattern is one of the reasons why I always use this when referring to an instance member within a class. e.g. always

this.SomeMethod(this.SomeProperty);

and never

SomeMethod(SomeProperty);

In most cases, there isn't any actual ambiguity, but I find it helps clarify things. Plus you now know where the property/method is defined.

---

I give things the same name as their type, except for case: my methods and properties are "lowerCase"; and I therefore wouldn't have the problem that MiffTheFox has.

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

So for me, m_b1 is member data, b1 is a property (or a local variable or parameter), and B1 is the name of the class.

참고URL : https://stackoverflow.com/questions/1095644/should-a-property-have-the-same-name-as-its-type