C #에서 확장 메서드가있는 인터페이스 대신 추상 클래스를 사용하는 경우

"Abstract class"와 "interface"는 비슷한 개념으로, 인터페이스가 두 가지 중 더 추상적 인 개념입니다. 차별화 요소 중 하나는 추상 클래스가 필요할 때 파생 클래스에 대한 메소드 구현을 제공한다는 것입니다. 그러나 C #에서는 최근에 확장 메서드가 도입되어이 차별화 요소가 줄어들어 인터페이스 메서드에 대한 구현을 제공 할 수 있습니다. 또 다른 차별화 요소는 클래스가 하나의 추상 클래스 만 상속 할 수 있다는 것입니다 (즉, 다중 상속이 없음). 그러나 여러 인터페이스를 구현할 수 있습니다. 따라서 인터페이스의 제약이 적고 유연합니다. 따라서 C #에서 확장 메서드가있는 인터페이스 대신 언제 추상 클래스를 사용해야합니까?

인터페이스 + 확장 메소드 모델의 주목할만한 예는 LINQ이며, 여기서는 IEnumerable여러 가지 확장 메소드를 통해 구현 되는 모든 유형에 대해 조회 기능이 제공됩니다 .

구현할 클래스의 일부가 필요할 때 내가 사용한 가장 좋은 예는 템플릿 메소드 패턴입니다.

public abstract class SomethingDoer
{
    public void Do()
    {
        this.DoThis();
        this.DoThat();
    }

    protected abstract void DoThis();
    protected abstract void DoThat();
}

따라서 Do ()가 호출 될 때 수행 될 단계를 정의 할 수 있습니다. 파생 클래스는 추상 메소드를 구현해야하지만 Do () 메소드는 구현하지 않아야합니다.

확장 법은 반드시 방정식의 "클래스의 일부 여야 함"부분을 만족하지는 않습니다. 또한 iirc, 확장 메소드는 범위 외의 공개 메소드가 될 수 없습니다.

편집하다

이 질문은 내가 원래 신용했던 것보다 더 흥미 롭습니다. 추가 조사를 통해 Jon Skeet 은 인터페이스 + 확장 방법을 사용하여 SO와 같은 질문 에 대답 했습니다. 또한 잠재적 단점 은 이런 방식으로 설계된 객체 계층에 대해 반사를 사용하는 것입니다.

개인적으로, 나는 현재 일반적인 관행을 바꾸는 것의 이점을 보는 데 어려움을 겪고 있지만, 그렇게 할 때 단점이 거의 없습니다.

유틸리티 클래스를 통해이 방법으로 여러 언어로 프로그래밍 할 수 있습니다. 확장 기능은 구문 설탕을 제공하여 메소드가 클래스에 속하는 것처럼 보이게합니다.

그것은 모든 관하여 무엇을 당신이 모델에 원하는 :

추상 클래스는 상속에 의해 작동합니다 . 다만 특별한 기본 클래스 인, 그들은 어떤 모델 이다-A -relationship.

예를 들어, 개 는 동물이므로

class Dog : Animal { ... }

실제로 일반적인 모든 동물을 만드는 것은 이치에 맞지 않기 때문에 (이것은 어떤 모양입니까?)이 Animal기본 클래스를 abstract만들지 만 여전히 기본 클래스입니다. 그리고 Dog수업은 Animal.

반면에 인터페이스 는 다른 이야기입니다. 상속을 사용하지 않지만 다형성 ( 상속으로 구현할 수도 있음)을 제공합니다. 그들은 is-a 관계를 모델링하지 않지만 더 많은 관계를 지원 합니다.

예를 들어 다른 것과 비교할 수IComparable 있는 물체를 예로 들어 보자 .

클래스의 기능은 구현하는 인터페이스에 의존하지 않으며 인터페이스는 기능에 액세스하는 일반적인 방법을 제공합니다. 우리는 여전히 수 Dispose의 Graphics또는 FileStream그들을 구현하지 않고 IDisposable. 인터페이스는 관한 함께 방법.

원칙적으로 클래스의 동작을 변경하지 않고도 확장과 마찬가지로 인터페이스를 추가하고 제거하여 액세스를 강화할 수 있습니다. 객체가 무의미 해 지므로 기본 클래스를 빼앗을 수는 없습니다!

방금 몇 년 동안 추상 클래스를 사용하지 않았다는 것을 깨달았습니다.

추상 클래스는 인터페이스와 구현 사이에서 다소 이상한 짐승입니다. 내 거미줄을 괴롭히는 추상 수업이 있습니다. 필자는 인터페이스 뒤의 구현을 어떤 식 으로든 "노출"해서는 안된다고 주장한다.

인터페이스를 구현하는 클래스간에 공통적 인 동작이 필요하더라도 추상 클래스가 아닌 독립적 인 도우미 클래스를 사용합니다.

나는 인터페이스를 갈 것이다.

IMHO, 나는 여기에 개념이 혼합되어 있다고 생각합니다.

클래스는 특정 종류의 상속을 사용하지만 인터페이스는 다른 종류의 상속을 사용합니다.

두 종류의 상속은 중요하고 유용하며 각각 장단점이 있습니다.

처음부터 시작합시다.

인터페이스가있는 이야기는 C ++로 오래 시작되었습니다. 1980 년대 중반, C ++이 개발되었을 때, 다른 종류의 인터페이스라는 아이디어는 아직 실현되지 않았습니다 (시간이 come 것입니다).

C ++에는 클래스가 사용하는 상속 유형 인 구현 상속이라는 한 가지 유형의 상속 만있었습니다.

GoF Book 권장 사항을 적용 할 수 있도록 : "구현이 아닌 인터페이스를위한 프로그램으로"C ++은 C #의 인터페이스가 수행 할 수있는 (그리고 유용한) 인터페이스를 수행 할 수 있도록 추상 클래스와 다중 구현 상속을 지원했습니다. .

C #에서는 새로운 유형의 인터페이스와 새로운 유형의 상속, 인터페이스 상속을 도입하여 "구현이 아닌 인터페이스를위한 프로그래밍"을 지원하는 두 가지 방법을 제공합니다. 인터페이스 상속 (구현 상속이 아닌)으로 다중 상속을 지원합니다.

따라서 C # 인터페이스의 아키텍처 이유는 GoF 권장 사항입니다.

이것이 도움이되기를 바랍니다.

종류, Gastón

인터페이스에 확장 메소드를 적용하면 공통 인터페이스 만 공유 할 수있는 클래스에서 공통 동작을 적용 할 때 유용합니다. 이러한 클래스는 이미 존재할 수 있으며 다른 방법을 통해 확장에 닫힐 수 있습니다.

새로운 디자인의 경우 인터페이스에서 확장 방법을 사용하는 것이 좋습니다. 유형 계층의 경우 확장 메서드는 수정을 위해 전체 계층을 열지 않고도 동작을 확장하는 수단을 제공합니다.

그러나 확장 메서드는 개인 구현에 액세스 할 수 없으므로 계층의 최상위에서 개인 구현을 공용 인터페이스 뒤에 캡슐화 해야하는 경우 추상 클래스가 유일한 방법입니다.

C #에서는 다중 상속이 지원되지 않으므로 인터페이스 개념이 C #에 도입 된 것 같습니다.

추상 클래스의 경우 다중 상속도 지원되지 않습니다. 따라서 추상 클래스 또는 인터페이스를 사용하도록 결정할 수 있습니다.

C #이 인터페이스에서 연산자 (내 경우에는 암시 적 변환)를 지원하지 않기 때문에 프로젝트에서 추상 클래스를 구현하는 중 입니다.