제 사무실 동료가 오늘 인터페이스에 속성을 사용하는 것이 나쁜 습관이라고 말했습니다. 그는 내가 찾을 수없는 MSDN 기사 (들)에서 빨간색을 사용하고 있습니다. (나는 잘못된 키워드를 사용하여 Google에서 몇 번 시도해 보았습니다). 그는 또한 유일한 방법은 인터페이스에 있어야한다고 나에게 말했다. 이제는 분명히 .net에서 인터페이스에서 속성 서명을 만들고 컴파일 할 수 있기 때문에 엄격한 규칙이 아니라는 것을 알고 있습니다.인터페이스에 속성이 없어야합니까?
하지만 이것은 나쁜 관행/디자인/OOP가되는 것이 사실입니까? 그리고 왜?
올바른 문학 또는 웹 리소스를 지적해도 도움이 될 것입니다.
감사
나는이 음성을 여기에 추가 할뿐입니다. 나는이 권고를 결코 접하지 못했습니다. 속성은 효과적으로 get/set 메서드 쌍입니다.
다른 모든 디자인 결정과 마찬가지입니다. 그것이 진정으로 의미가있는 경우; 설계 상 시스템에 적합하다면 유지 보수 문제가 발생하지 않더라도 성능 문제가 발생하지 않으면 수행 할 수없는 이유가 없어야합니다.
나는이 주장을 만드는 사람을 발생하지 않으며, 나는 그것을 위해 어떤 좋은 이유를 할 적이 없다. .NET 프레임 워크는 속성이있는 인터페이스로 가득합니다.
인터페이스는 구현할 클래스에 대한 계약이므로 속성이 그러한 계약에서 제외되어야하는 이유는 없습니다. 또한 속성은 .NET에 고유합니다.
예 : ICollection<T>은 Count 및 IsReadOnly입니다.
이처럼 본 적이 없지만 속성을 지원하지 않는 많은 플랫폼이 있으므로 모든 플랫폼에서 메소드를 지원하므로 플랫폼 간 인터페이스 정의에서 속성을 사용하지 않는 것에 대한 이야기가있었습니다.
전제를 뒷받침 할만한 문서가 없다고 생각할 수 있습니다. 또한 나는 그 반대 인 BCL에서 많은 예제를 생각할 수 있습니다. 거의 모든 컬렉션 인터페이스를 살펴보고 속성을 볼 수 있습니다.
사실상 속성은 두 가지 기능으로 설정됩니다. 하나는 값을 가져오고 하나는 값을 설정하는 것입니다. 속성이 C#의 첫 번째 클래스 "기능"이지만 이는 여전히 사실입니다.
왜 인터페이스에서 속성을 사용할 수 없습니까?
인터페이스의 일부로 등록 정보를 갖지 않을 이유가 없습니다. 데이터 멤버에 대한 액세스를 구현하려면 어떻게해야합니까? 속성 대신 메서드 및 메서드 가져 오기. 그것은 평범하고 못생긴 것이기에 1990 년대입니다.
"코드 냄새"라는 용어가 널리 알려져 있습니다. 필자는 "프로그래머의 냄새"개념을 도입 할 것을 제안합니다. 누군가가 규칙을 고집하지만 이유를 설명 할 수 없다면 그것은 냄새입니다. 동료가 인터페이스의 속성이 나쁜 이유를 설명 할 수 있어야합니다. 그가 할 수 없다면 - 그가 언급 한 기사가 옳다고해도 그는 틀릴 것입니다.
이 기사에서는 특정 종류의 인터페이스에 대해 이야기했을 것입니다. COM 및 상호 운용성과 관련이있을 수 있습니다. 아니면 그냥 잘못했을 수도 있습니다. 규칙을 이해하고 설명 할 수있는 것은 규칙 사용의 중요한 부분입니다.
속성과 메서드에서 볼 수있는 유일한 단점은 get 메서드, set 메서드가있는 인터페이스 및 두 메서드를 결합한 인터페이스 (최대 허용 가능한 시나리오 공분산과 반 차별성이있는 유연성), 속성은 잘 결합되지 않습니다. 읽기 - 쓰기 속성이 단순히 읽기 속성 및 쓰기 속성과 동일한 것으로 간주되지 않는 이유는 확실하지 않지만 그렇지 않습니다. 인터페이스가 읽기 전용 속성과 동일한 이름의 쓰기 전용 속성을 지원하는 경우 결합 된 인터페이스를 통해 속성에 액세스하려는 시도는 모호한 주장을 토대로 실패합니다.
클래스 계약의 일부로 사용 된 변수를 사용하여 상태를 저장하는 데 사용되는 구현의 변수 공간을 오염시키는 것은 좋지 않은 디자인입니다.
여기서 뭐라했는지 설명 할 수 있니? 나는 그것이 3 년이라는 것을 알고 있지만, 나는이 문제에 관심이있다. 그리고 나는 속성을 사용하는 것에 대한 이슈를 보지 않는다. 그러나 나는 논쟁이 적절하게 결정되기를 바랄 것이다. – Carl
내가 생각할 수있는 유일한 방법은 다른 시스템이나 응용 프로그램 도메인에서 호스팅되는 서비스 (예 : WCF, WebServices, Remoting)에 대한 인터페이스를 정의 할 때 인터페이스에 대한 속성이 나쁜 이유입니다.
원인 속성은 네트워크 및 serialization 작업으로 인해 서비스에 적합하지 않은 (즉, 가져 오기 및 설정 값) 빠른 것을 의미합니다. 서비스 인터페이스에서 값을 가져 오거나 설정하는 방법은 작업을 완료하는 데 약간의 시간이 걸릴 수 있음을 나타냅니다.
IEnumerator은 인터페이스 멤버로 속성이 필요한 시나리오의 완벽한 예입니다. 구현 자에게 그렇게하도록 강제하지 않는다면 어떻게 Current 요소를 저장할 것인가?
"크로스 플랫폼 인터페이스"는 무엇을 의미합니까? –
BCL "공용 인터페이스 foo"의미의 인터페이스가 아닙니다. 오히려 인터페이스 사양. 좋은 예가 W3C의 Document Object Model 사양입니다. –