이미 추상 클래스가 있다면 인터페이스를 정의하는 것이 합리적입니까?

기본 / 공유 기능이있는 클래스가 있습니다. 나는 그것을 위해 사용 abstract class한다 :

public interface ITypeNameMapper
{
    string Map(TypeDefinition typeDefinition);
}

public abstract class TypeNameMapper : ITypeNameMapper
{
    public virtual string Map(TypeDefinition typeDefinition)
    {
        if (typeDefinition is ClassDefinition classDefinition)
        {
            return Map(classDefinition);
        }
        ...

        throw new ArgumentOutOfRangeException(nameof(typeDefinition));
    }

    protected abstract string Map(ClassDefinition classDefinition);
}

보시다시피 인터페이스도 있습니다 ITypeNameMapper. 이미 추상 클래스가 TypeNameMapper있거나 abstract class충분 하다면이 인터페이스를 정의하는 것이 합리적 입니까?

TypeDefinition 이 최소한의 예에서도 추상입니다.

예, C # 은 인터페이스를 제외하고 다중 상속을 허용하지 않기 때문 입니다.

따라서 TypeNameMapper 및 SomethingelseMapper 인 클래스가 있으면 다음을 수행 할 수 있습니다.

class MultiFunctionalClass : ITypeNameMapper, ISomethingelseMapper 
{
    private TypeNameMapper map1
    private SomethingelseMapper map2

    public string Map(TypeDefinition typeDefinition) { return map1.Map(typeDefintion);}

    public string Map(OtherDef otherDef) { return map2.Map(orderDef); }
}

인터페이스와 추상 클래스는 다른 용도로 사용됩니다.

• 인터페이스 는 API를 정의하고 구현이 아닌 클라이언트에 속합니다.
• 클래스가 구현을 공유하는 경우 추상 클래스의 이점을 얻을 수 있습니다 .

귀하의 예에서 interface ITypeNameMapper고객의 요구를 정의하고 abstract class TypeNameMapper가치를 추가하지 않습니다.

인터페이스의 전체 개념은 공유 API가있는 클래스 제품군을 지원하기 위해 작성되었습니다.

이것은 인터페이스를 사용하면 사양 구현이 둘 이상 (또는있을 것으로 예상 됨)을 의미한다고 명시 적으로 말하고 있습니다.

DI 프레임 워크는 많은 구현이있을지라도 인터페이스가 필요하다는 점에서 물을 흐릿하게 만들었습니다. 그것이 무엇입니까.

대답은 질문 자체에 있습니다. 추상 클래스가있는 경우 공통 API를 사용하여 둘 이상의 파생 클래스 작성을 준비하고 있습니다. 따라서 인터페이스 사용이 명확하게 표시됩니다.

우리가이 질문에 명시 적으로 대답하고 싶다면 저자는 "이미 추상 클래스 TypeNameMapper를 가지고 있거나 추상 클래스만으로 충분하다면이 인터페이스를 정의하는 것이 합리적입니까?"라고 말합니다.

대답은 예, 아니오입니다-예, 이미 추상 기본 클래스를 가지고 있더라도 (클라이언트 코드에서 추상 기본 클래스를 참조하면 안 됨) 인터페이스를 작성해야합니다. 인터페이스가없는 추상 기본 클래스

빌드하려는 API에 대해 충분히 생각하지 않았다는 것은 분명합니다. 먼저 API를 제시 한 다음 원하는 경우 부분 구현을 제공하십시오. 추상 기본 클래스가 코드에서 유형 검사를 수행한다는 사실이 그것이 올바른 추상화가 아니라는 것을 알려주기에 충분합니다.

OOD의 대부분의 경우와 마찬가지로 그루브에 있고 객체 모델을 잘 수행하면 코드는 다음에 무엇이 올 것인지 알려줍니다. 인터페이스로 시작하여 필요한 클래스에서 해당 인터페이스를 구현하십시오. 비슷한 코드를 작성하고 있다면 추상 기본 클래스로 추출하십시오. 중요한 인터페이스, 추상 기본 클래스는 단지 도우미이며 둘 이상이있을 수 있습니다.

나머지 응용 프로그램을 모르면 대답하기가 매우 어렵습니다.

어떤 종류의 DI 모델을 사용하고 있고 가능한 한 확장 가능하도록 코드를 설계했다고 가정하면 ( TypeNameMapper쉽게 새 항목을 추가 할 수 있음) 예라고 대답합니다.

이유 :

• 기본 클래스가 구현하므로 interface자식 구현에서 걱정할 필요가 없으므로 효과적으로 무료로 얻을 수 있습니다.
• 대부분의 IoC 프레임 워크 및 Mocking 라이브러리는을 기대 interface합니다. 그들 중 많은 사람들이 추상 클래스로 작업하는 동안 항상 주어진 것은 아니며 가능한 한 도서관 사용자의 다른 99 %와 같은 경로를 따르는 것을 믿는 사람입니다.

반대 이유 :

• 엄밀히 말하면 (당신이 지적했듯이) 당신은 정말로 할 필요가 없습니다.
• class/가 interface변경 되면 약간의 추가 오버 헤드가 있습니다.

고려한 모든 것은 interface. 이에 대한 이유는 무시할 만하지 만 조롱과 IoC에서 초록을 사용할 수는 있지만 인터페이스를 사용하는 것이 훨씬 쉽습니다. 궁극적으로, 나는 다른 방향으로 간 동료의 코드를 비판하지 않을 것입니다.