빈 인터페이스 코드 유전자가 있습니까?

빈 인터페이스 코드 유전자가 있습니까?

---

동일한 종류의 개체 (쿼리 결과)를 반환하는 함수가 속성이나 메서드는 공통되지 않습니다. 공통 유형을 갖기 위해 빈 인터페이스를 반환 유형으로 사용하고 두 가지에서 "구현"했습니다.

물론 그것은 옳지 않은 것입니다. 언젠가는 그런 클래스가 공통점을 공통점 논리를 빈 인터페이스로 옮길 수 있기를 바랍니다. 그러나 나는 두 가지 다른 방법을 가져야하고 조건부로 다음을 호출 해야하는지에 대해 만족하지 않을 것이라고 생각합니다. 더 나은 접근 방식이 될까요?

또한 .NET Framework는 태그 지정을 위해 빈 인터페이스를 사용하고 있습니다.

제 질문은 비어있는 인터페이스가 디자인 문제의 강력한 신호입니까 아니면 널리 사용됩니까?

편집 : 관심있는 사람들을 위해 나중에 기능적 언어의 차별적 조합이 내가 달성하려는 것에 대한 완벽한 솔루션이라는 것을 알게됩니다. C #은 아직 개념에 배치하지 않을 것입니다.

편집 : 나는 이 문제에 대해 더 긴 글을 쓰고 비용 을 절감 할 수 있도록 자세히 설명했습니다.

---

해당 사용 사례에 대한 디자인 패턴 (지금은 "마커 인터페이스"에 대해 많이 언급했습니다)이있는 것 같지만, 다만 관행의 사용은 최소한 대부분의 경우 코드 냄새의 표시라고 생각합니다.

@ V4Vendetta가 게시 한대로이를 대상으로 정적 분석 규칙이 있습니다. http://msdn.microsoft.com/en-us/library/ms182128(v=VS.100).aspx

디자인에 구현할 경우 예상되는 인터페이스가 포함 된 인터페이스를 사용하고있을 수 있습니다. 이 현상이 발생하는 경우에 수행하는 올바른 방법은 사용자 정의 속성을 사용하는 것입니다. 속성의 유무 또는 속성을 사용하여 대상 유형 속성을 속성을 사용합니다. 타임에 구매해야하는 경우 빈 인터페이스를 사용할 수 있습니다.

다음은 인용 된 MSDN 권장 사항입니다.

인터페이스를 제거 할 구성원을 추가하십시오. 빈 인터페이스를 사용하여 유형 집합에 레이블을 지정하는 경우 인터페이스를 사용자 지정 속성으로 바꿉니다.

이 또한 이미 게시 된 위키 백과 링크의 비평 섹션을 반영합니다.

마커 인터페이스의 주요 문제는 인터페이스가 클래스 구현을위한 계약을 정의하고 해당 계약이 모든 하위 클래스에 상속되는 것입니다. 이것은 당신이 마커를 "단일화"할 수 있음을 의미합니다. 주어진 예제에서 일련 화하지 않는 경우 하위 클래스를 만드는 경우 (아마도 일시적인 상태에 따라 달라짐) NotSerializableException을 명시 적으로 던져야합니다 (ObjectOutputStream에 따라).

---

당신의 함수는 "특정 경우에 따라 객체를 반환한다"고 말하지만, 얼마나 다른가요? 하나는 스트림 작성기, 다른 하나는 UI 클래스, 다른 하나는 데이터 수업 일 수 있습니까? 아니 ... 의심 스럽다!

사용할 수있는 방법 나 속성이 없을 수 있습니다. 이 경우 마커 인터페이스가 충분히 이해해라 고합니다.

---

마커 인터페이스 로 사용되지 않는 문서 예, 이것은 냄새 코드 냄새입니다.

인터페이스는 구현자가 준수하는 계약을 정의합니다. (마커 인터페이스와 권장) 리플렉션을 사용하지 않는 인터페이스가있는 경우 Object(이미 존재하는) 기본 유형으로 사용하는 것이 좋습니다.

---

자신의 질문에 답했습니다. "특정한 경우에 완전히 완전히 다른 객체를 반환하는 함수가 있습니다."... 완전히 다른 객체를 반환하는 함수를 원하는 이유는 무엇입니까? 이것이 유용한 이유를 알 수 없습니다. 좋은 이유가있을 수 있습니다.이 경우 공유 해주세요.

편집 : 설명을 고려할 때 실제로 마커 인터페이스를 사용합니다. "완전히 다르다"는 "같은 종류"와는 상당히 다르다. (공유 멤버가 될 것입니다.)

---

많은 사람들이 이미 말했듯이 빈 인터페이스는 "마커 인터페이스"로 유효한 용도로 사용됩니다.

가장 좋은 용도는 해당 저장소에서 처리하는 도메인의 아마도 하위 집합에 존재하는 표시하는 것입니다. 데이터를 검색하는 다른 데이터베이스가 있고 추가에 대한 저장소 구현이 가정합니다. 특정 저장소는 하나의 하위 집합 만 처리 할 수있는 다른 하위 집합의 개체 인스턴스를 제공합니다. 도메인 모델은 다음과 달라집니다.

//Every object in the domain has an identity-sourced Id field
public interface IDomainObject
{
   long Id{get;}
}

//No additional useful information other than this is an object from the user security DB
public interface ISecurityDomainObject:IDomainObject {}

//No additional useful information other than this is an object from the Northwind DB
public interface INorthwindDomainObject:IDomainObject {}


//No additional useful information other than this is an object from the Southwind DB
public interface ISouthwindDomainObject:IDomainObject {}

그런 다음 리포지토리를 ISecurityDomainObject, INorthwindDomainObject 및 ISouthwindDomainObject에 대해 일반화 할 수있는 타임에 코드가 보안 개체를 Northwind DB (또는 순열)로 전달하지 않는지 확인합니다. 이와 같은 상황에서 인터페이스는 구현 계약을 제공하지 않는 제공 클래스의 특성에 대한 귀중한 정보를 제공합니다.

참고 URL : https://stackoverflow.com/questions/7552677/are-empty-interfaces-code-smell