C#의 인터페이스에서 확장 메소드를 사용한 의사 다중 구현?

Question

비슷한 질문이지만 똑같지는 않습니다

인터페이스와 동일한 네임 스페이스의 확장 메소드를 사용하면 10 개의 다른 클래스에서 동일한 인터페이스를 동일한 방식으로 동일한 인터페이스를 구현할 필요가 없다는 점에서 여러 상속과 유사한 효과를 얻을 수 있다고 생각했습니다.

이것을하는 단점은 무엇입니까? 나는 전문가가 꽤 분명하다고 생각합니다. 그것은 나중에 당신을 물기 위해 보통 돌아 오는 단점입니다.

내가 보는 단점 중 하나는 확장 메소드가 가상이 될 수 없으므로 모든 인스턴스에 대해 동일한 방식으로 구현하기를 원한다는 것입니다.

Answer 1

확장 방법을 통해 인터페이스 기능을 빌드하는 문제는 더 이상 인터페이스를 구현하지 않으므로 객체를 인터페이스 유형으로 사용할 수 없다는 것입니다.

IBAR 유형의 객체를 취하는 메소드가 있다고 가정 해 봅시다. 확장 방법을 통해 클래스 FOO에서 IBAR 인터페이스를 구현하면 FOO는 IBAR에서 파생되지 않으며 IT와 상호 교환 적으로 사용할 수 없습니다 (Liskov 대체 원리). 물론, 나는 Foo에 추가하고 싶은 동작을 얻지 만, 처음에 인터페이스를 만드는 데있어 가장 중요한 측면을 잃어 버렸습니다. 다양한 수업으로 다양한 방법으로 구현할 수있는 추상 계약을 정의 할 수 있습니다 종속 클래스는 구체적인 구현에 대해 알 필요가 없습니다.

여러 상속이 필요하다면 (그리고 지금까지 나는 그것 없이는 살았다) 충분히 충분히 충분히 작곡을 사용하여 코드 복제의 양을 최소화하기 위해 구성을 사용한다고 생각합니다.

Answer 2

이것에 대해 생각하는 괜찮은 방법은 인스턴스 방법이 완료되었다는 것입니다. ~에 의해 객체, 확장 방법은 완료된 것입니다 에게 그 물체. 프레임 워크 설계 가이드 라인은 가능할 때마다 인스턴스 방법을 구현해야한다고 확신합니다.

인터페이스는 "이 기능을 사용하는 것에 관심이 있지만 달성하는 방식은 아닙니다."라고 선언합니다. 그로 인해 구현 자들은 방법을 선택할 수있는 자유를 남깁니다. 메커니즘에서 구체적인 코드가있는 클래스의 의도, 공개 API의 의도를 분리합니다.

이것이 인터페이스의 주요 이점이므로 확장 방법이 목적을 물리 치는 것처럼 보이기 때문에 전적으로 구현합니다. 조차 IEnumerable<T> 인스턴스 메소드가 있습니다.

편집하다: 또한 객체는 포함 된 데이터에 작용하기위한 것입니다. 확장 방법은 객체의 공개 API 만 볼 수 있습니다 (정적 방법이므로). 당신은 그것을 작동시키기 위해 모든 객체의 상태를 노출시켜야 할 것입니다 (oo no-no).