유형 자체 대신 유형 제약 조건이있는 일반 메소드를 사용하는 이유는 무엇입니까?

다른 StackExchange 질문 에서이 프로토 타입을 사용하는 사람을 발견했습니다.

void DoSomething<T>(T arg) where T: SomeSpecificReferenceType
{
    //Code....
}

단 하나의 타입 제약 ( SomeSpecificReferenceType) 만이 있다는 점을 명심 하면, 단순히 작성하는 것보다는 다음과 같이 작성하는 것의 차이점과 장점은 무엇입니까?

void DoSomething(SomeSpecificReferenceType arg)
{
    //Code....
}

두 경우 모두 arg컴파일 타임 유형 검사가 적용됩니다. 두 경우 모두, 메소드의 본문은 arg컴파일 타임에 알려진 특정 유형의 지식 (또는 그 후손) 에 안전하게 의존 할 수 있습니다 .

일반 상속에 대해 배우기 전에 제네릭에 대해 배우는 열렬한 개발자의 경우입니까? 아니면 메소드 서명이 이런 식으로 쓰여지는 합당한 이유가 있습니까?

일반 상속에 대해 배우기 전에 제네릭에 대해 배우는 열렬한 개발자의 경우입니까?

그렇습니다.

아니면 메소드 서명이 이런 식으로 쓰여지는 합당한 이유가 있습니까?

아마 . 일반적으로 관련된 반환 값 T이나 사용 된 다른 매개 변수가 있으면 더 의미가 있습니다 T.

그러나, 그것은 코드 사용의 내부에있을 가능성이 T와 (아마도 시리얼 라이저에 인수?)을 필요가 특별히 사용 T하지 제약 클래스입니다. 제약 조건이 new제약 조건과 쌍을 이루는 인터페이스 일 때 메소드의 내장이 T어떤 이유로 s를 생성하는 경우가 있습니다.

따라서 구속 조건 버전이 필요한 경우는 드물지만 때때로 적용되는 경우가 있습니다. 그리고이 방법은 것이 항상 가능 사용 을 필요로하지만, 지금은하지 않습니다 및 개발자는이 같은 주요 변경을 소개하지 않는 것입니다 떠났다.

나는 이것을 포함하는 대답을 입력하는 것을 기억한다고 생각합니다.

당시 그 이유는 다음과 같습니다.
(코드가 다를 수 있습니다. 일반적인 방법으로 형식 매개 변수에 제약이있는 가능한 이유 중 하나를 설명하기 위해.)

class SomeSingleton
{
    static Dictionary<Type, List<object>> staticTypeSpecificList;
    public void AddObjectToList<T>(T t) where T : SomeCommonThing
    {
        Type tt = t.GetType();
        List<object> list;
        if (!staticTypeSpecificList.TryGet(tt, out list))
        {
            list = new List<object>();
            staticTypeSpecificList.Add(tt, list);
        }
        list.Add(t);
    }
}

기본적으로 코드는 수동으로 유형 조작 자체를 코딩합니다. 또한 반사 효과와 섞일 수도 있습니다.

예를 들어, 사용하여 Method<T>(T arg) where T : ..., 하나는 교체 할 수 있습니다 arg.GetType()로 typeof(T). 그러나 나는 그 선택이 좋은지 나쁜지 모른다.

나는 이것이 다른 질문 / 문제에 너무 집중하여 코딩의 모든 가능성 을 신중하게 생각하지 않는 저자 (아마도 나 또는 다른 사람)의 예일 뿐이라고 생각 합니다.