왜 일반 서브 클래스에서 형식 제약 조건을 다시 선언해야합니까?

Question

최근에 일반 인터페이스를 구현하여 일반 서브 클래스를 만들려고했습니다.

public interface IModule<T> where T : DataBean { ..... } 
public class Module<T> : IModule<T> where T : DataBean { .... } 

이 , 기본 인터페이스에 정의 된대로 내가 T의 어떠한 제한에 의존 할 수 없다 보인다 나는 그들에게 자신을 다시 선언해야합니다.

MSDN 단지 제공 :

제네릭 형식 매개 변수 서브 클래스를 사용하는 경우, 당신은 어떤 제약이 서브 클래스 레벨에서 기본 클래스 수준에서 규정 반복해야합니다. 예제의 경우 파생어 제한

기본 클래스/인터페이스의 제약 조건을 추론 할 수없는 이유는 무엇입니까?

Answer 1

C#이 이론적으로 제약 조건을 복사 할 수없는 이유가 생길 수 없습니다. 그러나 문서를 명시 적으로 복사 (또는 보강)하는 행위는 사용성 측면에서 가장 단순한 것으로 보입니다. B 항상A때문에 위의에서

public class A{} public class B : A {} public class X<T> where T: A {} public class Y<T> : X<T> where T: B { } 

은 내가 Y<T>에 제약을 복사 explicty하지 않았다 있습니다.

이제 컴파일러가 자동으로 제약 조건을 복사하면 어떻게 될지 살펴 보겠습니다. 제약 조건없이 Y<T>을 정의하고 컴파일러가 자동으로 배치한다고 가정 해 보겠습니다. 많은 코드에서 Y<T>을 사용합니다. 그런 다음 일부 새로운 인터페이스를 포함하도록 X<T> 선언에 대한 제약 조건을 변경합니다. X<T>의 선언을 변경

컴파일러 오류가 나는Y<T>를 사용 사이트에 있습니다!

현재 C# 컴파일러가 작동하는 방식으로 컴파일러 오류는 X<T>의 용도로 사용됩니다.

일부 시나리오에서는 편리하지만 다른 것들도 다소 혼란 스럽습니다. 두 가지 방법 모두 유효한 접근 방법이지만 C# 디자인 팀의 마음을 읽을 수는 없다는 점을 감안할 때 결정적인 판단이라고 생각합니다.

필자는 "단지 기술이 아니라"라고 말하지만 모든 필수 제약 조건을 충족시키는 가장 단순한 제약 조건을 생성하는 대신 모든 제약 조건이 충족되는지 확인하는 것이 어느 정도 쉬운 시나리오를 상상할 수 있습니다.

Answer 2

표준 C# 팀의 지혜. 선언은 자체 문서화해야합니다. 그리고 무엇보다도, 한 유형 선언의 변경은 진단을 생성하지 않고 관련없는 다른 유형의 동작을 변경해서는 안됩니다. 디자인에 투입된 -100 점 원리가 또 다른 문제입니다.

Answer 3

Module 클래스가 가져야하는 제약 조건을 컴파일러에 알리기에는 인터페이스의 constranint가 너무 가깝습니다. 예를 들어 Module 클래스는 DataBean의 수퍼 클래스 (상속 된 클래스)에 대한 제약 조건을 가질 수 있습니다.

저는 C# 디자이너들의 지혜를 모릅니다. 제약 조건이 다를 수 있기 때문에 개발자가 컴파일러에서 가정을하는 대신 명시 적으로 제약 조건을 선언하게하는 결정이 내려진 것 같습니다.