분류에만 인터페이스를 사용하는 것은 나쁜 습관입니까?

예를 들면 다음과 같습니다.

내가 수업을 말한다 A, B, C. 나는 두 개의 인터페이스를 가지고, 그들에게 전화 할 수 있습니다 IAnimal와 IDog. IDog에서 상속 IAnimal합니다. A하고 B있는 IDog반면, S C아니지만, 그것은이다 IAnimal.

중요한 부분은 IDog추가 기능 을 제공하지 않는다는 것입니다. 단지 허용하는 데 사용됩니다 A하고 B있지만 C, 특정 방법에 인수로 전달 될 수 있습니다.

이것은 나쁜 습관입니까?

마커 인터페이스라는 동일한 인터페이스에서 상속 된 다른 인터페이스와 멤버가 없거나 정확히 동일한 멤버가있는 인터페이스이며이를 마커로 사용하고 있습니다.

사용하는 언어가 지원하는 경우 나쁜 습관은 아니지만 인터페이스를 속성 (주석)으로 대체 할 수 있습니다.

오차드 프로젝트 에서 "마커 인터페이스"패턴을 많이 사용했기 때문에 이것이 나쁜 습관이 아니라고 자신있게 말할 수 있습니다.

다음은 오차드 프로젝트의 샘플 입니다.

public interface ISingletonDependency : IDependency {}

/// <summary>
/// Base interface for services that may *only* be instantiated in a unit of work.
/// This interface is used to guarantee they are not accidentally referenced by a singleton dependency.
/// </summary>
public interface IUnitOfWorkDependency : IDependency {}

/// <summary>
/// Base interface for services that are instantiated per usage.
/// </summary>
public interface ITransientDependency : IDependency {}

마커 인터페이스를 참조하십시오 .

예, 거의 모든 언어에서 나쁜 습관입니다.

데이터를 인코딩 할 유형이 없습니다. 데이터가 이동해야하는 위치로 이동하고 작동해야하는 것처럼 작동 함을 증명하는 데 도움이됩니다. 하위 유형을 지정하는 유일한 이유는 다형성 동작이 변경되는 경우입니다 (항상 그런 것은 아님).

타이핑이 없기 때문에 IDog가 할 수있는 것은 내포되어 있습니다. 한 프로그래머는 한 가지를 생각하고 다른 프로그래머는 다른 것을 생각하고 사물을 분해합니다. 또는 더 세밀한 제어가 필요할수록 그 수치가 증가합니다.

[편집 : 설명]

내 말은 당신이하고있는 것입니다 몇 가지 인터페이스를 기반으로 논리를. 왜 어떤 방법은 개나 다른 동물에게만 작용할 수 있습니까? 차이를 제공하는 실제 구성원이 없기 때문에 이러한 차이는 묵시적 계약입니다. 시스템에 실제 데이터 가 없습니다 . 유일한 차이점은 인터페이스 (따라서 '타이핑 없음'주석)와 그 의미 는 프로그래머마다 다릅니다. [/편집하다]

어떤 언어는 그렇게 나쁘지는 않지만 특성화에 중점을 두는 경향이있는 특성 메커니즘을 제공합니다. 나는 그들에 대한 경험이 거의 없으므로 모범 사례와 이야기 할 수 없습니다. C ++ / Java / C #에서는 좋지 않습니다.

나는 C #을 잘 알고 있기 때문에 일반적으로 OO 프로그래밍에 대해서는 이것을 말할 수 없지만 C # 예제로서 클래스를 분류 해야하는 경우 명백한 옵션은 인터페이스, 열거 속성 또는 사용자 정의 속성입니다. 일반적으로 다른 사람들의 생각에 상관없이 인터페이스를 선택합니다.

if(animal is IDog)
{
}
if(animal.Type == AnimalType.Dog)
{
}
if(animal.GetType().GetCustomAttributes(typeof(DogAttribute), false).Any())
{
}


var dogs1 = animals.OfType<IDog>();
var dogs2 = animals.Where(a => a.Type == AnimalType.Dog);
var dogs3 = animals.Where(a => a.GetType().GetCustomAttributes(typeof(DogAttribute), false).Any());


var dogsFromDb1 = session.Query<IDog>();
var dogsFromDb2 = session.Query<Animal>().Where(a => a.Type == AnimalType.Dog);
var dogsFromDb3 = session.Query<Animal>().Where(a => a.GetType().GetCustomAttributes(typeof(DogAttribute),false).Any());


public void DoSomething(IDog dog)
{
}
public void DoSomething(Animal animal)
{
    if(animal.Type != AnimalType.Dog)
    {
        throw new ArgumentException("This method should be used for dogs only.");
    }
}
public void DoSomething(Animal animal)
{
    if(!animal.GetType().GetCustomAttributes(typeof(DogAttribute), false).Any())
    {
        throw new ArgumentException("This method should be used for dogs only.");
    }
}

후자의 인터페이스의 모든 구현이 전자의 일부 구현이 유용하지 않은 작업 을 유용하게 수행 할 수있을 것으로 예상되는 경우, 새 멤버를 추가하지 않고 다른 인터페이스를 상속하는 인터페이스를 갖는 것은 아무런 문제 가 없습니다. 실제로 IMHO가 .net Framework와 같은 것들에서 더 많이 사용되어야하는 좋은 패턴입니다. 특히 더 파생 된 인터페이스에 의해 암시 된 제약 조건을 클래스가 자연스럽게 충족시키는 구현자는 더 파생 된 인터페이스를 구현함으로써 간단히 나타낼 수 있기 때문에 멤버 구현 코드 또는 선언을 변경할 필요가 없습니다.

예를 들어 인터페이스가 있다고 가정합니다.

IMaybeMutableFoo 인터페이스
  Bar Thing {get; set;} // 그리고 다른 속성들
  부울 IsMutable;
  IImmutableFoo AsImmutable ();
}
인터페이스 IImmutableFoo : IMaybeMutableFoo {};

구현은 IImmutableFoo.AsImmutable()스스로를 반환 할 것으로 예상됩니다. 변경 가능한 클래스 구현 IMaybeMutableFoo.AsImmutable()은 데이터의 스냅 샷을 포함하는 새로운 불변의 새로운 객체를 반환 할 것으로 예상됩니다. 에 보유 된 데이터의 스냅 샷을 저장하려는 루틴 IMaybeMutableFoo은 과부하를 제공 할 수 있습니다.

공공 무효 StoreData (IImmutableFoo ThingToStore)
{
  // ThingToStore가 불변 인 것으로 알려져 있기 때문에 참조를 저장하면 충분합니다.
}
공공 무효 StoreData (IMaybeMutableFoo ThingToStore)
{
  StoreData (ThingToStore.AsImmutable ()); //보다 구체적인 과부하를 호출
}

컴파일러가 저장할 것이라는 것을 모르는 경우을 IImmutableFoo호출 AsImmutable()합니다. 항목이 이미 변경 불가능한 경우 함수가 빠르게 리턴되어야하지만 인터페이스를 통한 함수 호출에는 여전히 시간이 걸립니다. 컴파일러가 항목이 이미임을 알고 있으면 IImmutableFoo불필요한 함수 호출을 건너 뛸 수 있습니다.