2010-04-09 6 views
15

좋아요, C#에서는 속성 오버로드가 지원되지 않습니다. 대부분의 참조에서는 single-method-different-returntype 문제를 인용하여 설명합니다. 그러나 세터는 어떨까요? 직접 문자열이나 객체로 값을 지정하고 싶지만 문자열로만 반환하십시오. 이처럼C#의 오버로드 속성 C#

: 왜 이런 일이

public string FieldIdList 
    { 
     get { return fieldIdList.ToString(); } 
     set { fieldIdList = new FieldIdList(value); } 
    } 

    public FieldIdList FieldIdList 
    { 
     set { fieldIdList = value; } 
    } 
    private FieldIdList fieldIdList; 

을 허용하지 않을까요? 나는 또한 "속성"이 단순히 컴파일시 getter/setter 함수를 생성한다는 것을 보았습니다. 내 자신을 만들 수 있을까요? 뭔가 같은 :

public void set_FieldIdList(FieldIdList value) 
    { 
     fieldIdList = value; 
    } 

그것은 똑같이 할 것이다. 생각?

+1

나는 똑같은 문제에 물 렸는데, 나는이 언어의 한계 때문에 실망했다. 이상하게도 속성은 내가 C++에서 놓친 시원한 C# 언어 기능이며, 거기에는 그다지 부족함이 있습니다. – paercebal

답변

7

속성은 사실 한 쌍의 get/set 메서드 중 하나 (두 개 중 하나는 생략 할 수 있음)이지만 속성 자체에 추가 메타 데이터가있어 두 개의 메서드 대신 첫 번째 속성으로 만듭니다.

성격 서명은 setter 만있는 경우에도 반환 유형이 다른 경우에만 유효하기 때문에 유효하지 않습니다. 필요한 경우 속성을 사용하지 마십시오. 어쨌든 set-only 속성은 좋지 않습니다.

+0

그래서 컴파일러는 한 쌍의 메소드에 대한 서명을 생성합니다. 그러면 추가 오버로드가 방지됩니다. 이것은 단지 속성을 편리하게 만들거나 거기에 더 있습니까? 추가 데이터가 있으면 어떤 속성이됩니까? –

+0

정확히는 아닙니다. 같은 이름을 가진 다른 유형의 변수 두 개를 가질 수 없듯이 다른 유형과 이름을 가진 두 개의 속성을 가질 수 없습니다. 문제는 동일합니다. 컴파일러는 어느 상황에서 어떤 변수 나 속성을 사용할 지 알 수 없습니다. 따라서 get/set 메서드가 충돌을 발생시키지 않도록 접근자를 선택하더라도 컴파일러에서 동일한 속성 이름을 여러 번 사용할 수 없도록합니다 (여러 인덱서 속성이있을 수 있습니다. 왜냐하면이 경우 동일한 이름을 사용하더라도 서명이 다르기 때문입니다. – Lucero

+3

@Lucero : 그리고 속성의 형식이 get 메서드의 반환 형식에 의해 부과 된 경우? 이 경우, 필요한 변환을 처리하는 set 메소드의 본문 인 많은 유형의 setter를 가질 수 있습니다.컴파일러에는 혼란이 없으며, 질문 메서드의 문제를 해결하기 위해 무엇이든 받아들이는'object' 속성을 사용해야하는 대신에 메서드 오버로드 규칙에 따라 set 메서드가 선택되므로 강력한 형식을 얻습니다. (그리고 광산처럼)입니다. – paercebal

1

하나의 접근법 (좋은 디자인 선택인지 아닌지에 대해 논할 수도 있음)은 다른 형식으로 데이터에 액세스하는 두 번째 속성을 추가하는 것입니다.

그러나 문자열을 구문 분석 할 때 중요한 작업을 수행 할 때 속성을 사용하지 않는 것이 좋지만 문자열 형식으로 데이터를 가져 오거나 설정할 수있는 메서드를 추가하는 것이 좋습니다 .

ToString() 및 TryParse() 인터페이스를 제공하는 fieldIdList가 필요합니다. 문자열로 사용해야하는 경우 myObject.FieldIdList.ToString() 등을 호출하면됩니다. 이렇게하면 모든 것을 깔끔하게 캡슐화하고 FieldIdLists를 다른 클래스의 멤버로 액세스 할 때만이 아니라 코드의 모든 위치에서 문자열 형식으로 변환하거나 문자열 형식으로 변환 할 수 있으므로 클라이언트 코드를 명확하고 이해하기 쉽습니다.

+1

'string' 과부하는 일반적인 경우가 아니라 한 예입니다. 질문자는 A 유형과 B 유형에 관계없이 속성의 set 메소드에 과부하를 제공하려고합니다. 속성의 실제 기본 유형에 대한 '전환'이 '중요한 작업'이 아니라고 가정 해 보겠습니다. 그런 다음 속성을 사용하면 C# IMHO에서 자연스럽고 좋은 솔루션이됩니다. – paercebal

+0

@paercebal : 베스트 프랙티스로서, 프로퍼티는 부작용없이 사소한 구현을 가져야한다. 프로그래머는 속성을 단순한 멤버 변수처럼 취급 할 수 있어야한다. (즉, 설정이 빠르고 효율적이라고 가정한다. 무손실 및 이벤트 또는 예외를 발생시키지 않음). 다른 경우에는 방법으로 구현하는 것이 더 나은 방법입니다. 속성의 오버로드는 속성 *이 단순한 구현이 아니며 일부 수준의 복잡성이 숨겨 짐을 의미합니다. 이것은 항상 * 나쁘지는 않지만 자주 발생합니다. –

+0

필자는 "가장 실용적인"변명을 이해하고 있지만 컴파일러에 의해 강요되는 것은 쓸데없고 과잉이라고 생각하기 때문에 : 1. 나쁜 프로그래머는 컴파일러 제한이 얼마나되는지 상관없이 나쁜 속성을 항상 씁니다. 프로그래머가 옳은 일을하지 못하게합니다. . . '3.' 나는 자산이 과부하 될 수는 없지만 여전히 (가상으로 만듦으로써) 재정의 될 수 있다는 사실을 재미있게 모순되는 단 한 건가요? – paercebal

0

문자열이나 객체로 속성을 설정할 수 있도록하려면 기본 클래스이므로 object를 속성의 유형으로 사용하면됩니다. 문자열을 허용하는 속성에 문자열을 전달할 수 있습니다 객체). 이것은 특히 좋은 디자인 결정으로 보이지는 않지만 할 수 있습니다. 아마도 당신은 당신이 달성하고자하는 것을 더 설명 할 필요가 있습니까?

+3

질문자는 분명했습니다. ** set 메소드에 대한 메소드 오버로드를 제공하고 싶습니다. ** 다중 오버로드 된 SetField (필드 필드) 및 SetField (문자열 필드) 메소드를 작성하는 것만 큼 합법적입니다. – paercebal

+0

@DanDiplo OP를 사용하려면 String과 사용자 정의 FieldIdList의 두 가지 유형 만 허용하기 때문에 객체 사용은 실제로 도움이되지 않습니다. – Marcel