제네릭 형식에서 상속하는 것이 좋습니다?

List<string>타입 어노테이션 또는 StringList어디 에서 사용하는 것이 더 낫습니까?StringList

class StringList : List<String> { /* no further code!*/ }

나는 Irony 에서 이것들 중 몇 가지 를 만났다 .

제네릭 형식에서 상속하려는 또 다른 이유가 있습니다.

메서드 서명에서 제네릭 형식을 중첩하지 않는 것이 좋습니다 .

그런 다음 일부 제네릭에 대해 비즈니스 도메인 이름이 지정된 유형을 만드는 것이 좋습니다. 을 갖는 대신 IEnumerable<IDictionary<string, MyClass>>유형 MyDictionary : IDictionary<string, MyClass>을 만든 다음 멤버가을 IEnumerable<MyDictionary>훨씬 쉽게 읽을 수있게됩니다. 또한 여러 장소에서 MyDictionary를 사용하여 코드의 명확성을 높일 수 있습니다.

이것은 큰 이익처럼 보이지는 않지만 실제 비즈니스 코드에서는 머리카락을 돋보이게하는 제네릭을 보았습니다. 같은 것 List<Tuple<string, Dictionary<int, List<Dictionary<string, List<double>>>>>. 그 일반의 의미는 결코 명백하지 않습니다. 그러나 일련의 명시 적으로 작성된 유형으로 구성된 경우 원래 개발자의 의도가 훨씬 명확 할 것입니다. 또한 어떤 이유로 인해 제네릭 형식을 변경해야하는 경우 해당 제네릭 형식의 모든 인스턴스를 찾아서 바꾸는 것이 파생 클래스에서 변경하는 것과 비교할 때 큰 고통이 될 수 있습니다.

마지막으로 누군가 제네릭에서 파생 된 고유 한 유형을 만들려는 또 다른 이유가 있습니다. 다음 클래스를 고려하십시오.

public class MyClass
{
    public ICollection<MyItems> MyItems { get; private set; }
    // plumbing code here
}

public class MyOtherClass
{
    public ICollection<MyItems> MyItemCache { get; private set; }
    // plumbing code here
}

public class MyConsumerClass
{
    public MyConsumerClass(ICollection<MyItems> myItems)
    {
        // use the collection
    }
}

이제 ICollection<MyItems>MyConsumerClass의 생성자로 전달할 것을 어떻게 알 수 있습니까? 우리는 파생 클래스를 생성하는 경우 class MyItems : ICollection<MyItems>와 class MyItemCache : ICollection<MyItems>, MyConsumerClass는 실제로 원하는 두 개의 컬렉션 중 어느 대해 매우 구체적으로 할 수 있습니다. 그런 다음 IoC 컨테이너와 매우 잘 작동하여 두 컬렉션을 매우 쉽게 해결할 수 있습니다. 또한 프로그래머가 더 정확하게 MyConsumerClass할 수 있습니다. ICollection과 작업 하는 것이 합리적 이면 일반 생성자를 사용할 수 있습니다. 그러나 파생 된 두 가지 형식 중 하나를 사용하는 것이 비즈니스 적으로 의미가없는 경우 개발자는 생성자 매개 변수를 특정 형식으로 제한 할 수 있습니다.

요약하면, 제네릭 형식에서 형식을 파생시키는 것이 가치가있는 경우가 많습니다. 적절한 경우보다 명확한 코드를 허용하고 가독성 및 유지 관리 성을 도와줍니다.

원칙적으로 일반 형식에서 상속하는 것과 다른 형식에서 상속하는 것에는 차이가 없습니다.

그러나 왜 지구상에서 어떤 클래스 에서 파생되어 더 이상 아무것도 추가하지 않겠습니까?

나는 C #을 잘 모르지만 typedef이것이 C ++ 프로그래머가 몇 가지 이유로 일반적으로 사용하는 을 구현하는 유일한 방법이라고 생각합니다 .

• 코드가 꺾쇠 괄호처럼 보이지 않도록합니다.
• 나중에 변경이 필요한 경우 다른 기본 컨테이너를 교체 할 수 있으며 그렇게 할 권리가 있음을 분명히 알 수 있습니다.
• 문맥에보다 적합한 이름을 타입에 부여 할 수 있습니다.

그들은 기본적으로 지루하고 일반적인 이름을 선택하여 마지막 이점을 버렸지 만 다른 두 가지 이유는 여전히 존재합니다.

나는 적어도 하나의 실용적인 이유를 생각할 수 있습니다.

제네릭 형식에서 상속하는 비 제네릭 형식을 선언하면 (아무 것도 추가하지 않아도) 해당 형식을 사용할 수 없거나보다 복잡한 방식으로 사용할 수있는 곳에서 해당 형식을 참조 할 수 있습니다.

제네릭이 아닌 유형 만 사용할 수있는 Visual Studio의 설정 편집기를 통해 설정을 추가하는 경우가 그러한 경우입니다. 거기에 가면 모든 System.Collections수업을 이용할 수 있지만 System.Collections.Generic해당하는 컬렉션은 없습니다 .

다른 경우는 WPF에서 XAML을 통해 유형을 인스턴스화하는 경우입니다. 2009 년 이전 스키마를 사용할 때는 XML 구문에서 형식 인수를 전달할 수 없습니다. 2006 스키마가 새로운 WPF 프로젝트의 기본값 인 것 같습니다.

나는 당신이 어떤 역사 를 조사해야한다고 생각합니다 .

• C #은 일반적인 유형보다 훨씬 오랫동안 사용되었습니다.
• 주어진 소프트웨어는 역사상 어느 시점에서 자체 StringList를 가질 것으로 기대합니다.
• 이것은 ArrayList를 래핑하여 구현되었을 수 있습니다.
• 그런 다음 코드베이스를 앞으로 이동시키기 위해 리팩토링하는 사람이 있습니다.
• 그러나 1001 개의 다른 파일을 건드리고 싶지 않았으므로 작업을 완료하십시오.

그렇지 않으면 Theodoros Chatzigiannakis가 가장 좋은 답을 얻었습니다. 예를 들어 일반적인 유형을 이해하지 못하는 도구가 여전히 많이 있습니다. 아니면 그의 대답과 역사가 섞여있을 수도 있습니다.

어떤 경우에는 제네릭 형식을 사용할 수 없습니다. 예를 들어 XAML에서 제네릭 형식을 참조 할 수 없습니다. 이 경우 원래 사용하려는 제네릭 형식에서 상속되는 제네릭이 아닌 형식을 만들 수 있습니다.

가능하다면 피할 것입니다.

typedef와 달리 새 유형을 만듭니다. StringList를 메소드의 입력 매개 변수로 사용하는 경우 호출자는을 전달할 수 없습니다 List<string>.

또한 StringList 예제 에서는 그러한 생성자를 정의 new StringList(new[]{"a", "b", "c"})하더라도 말할 수없는 모든 생성자를 명시 적으로 복사해야합니다 List<T>.

편집하다:

허용되는 답변은 도메인 모델 내에서 파생 된 유형을 사용할 때 전문가에게 중점을 둡니다. 나는이 경우에 잠재적으로 유용 할 수 있다고 동의하지만 여전히 개인적으로도 피할 수 있습니다.

그러나 당신은 (내 의견으로는) 호출자의 삶을 더 어렵게 만들거나 성능을 낭비하기 때문에 공개 API에서 절대로 사용해서는 안됩니다 (일반적으로 암시 적 변환은 실제로 좋아하지 않습니다).

가치있는 것을 위해, 클래스의 이름을 변경하지 않고 Microsoft의 Roslyn 컴파일러에서 일반 클래스에서 상속하는 방법의 예가 있습니다. (나는 이것에 의해 매우 독창적이어서 이것이 실제로 가능한지 알기 위해 검색에서 끝났습니다.)

CodeAnalysis 프로젝트에서 다음 정의를 찾을 수 있습니다.

/// <summary>
/// Common base class for C# and VB PE module builder.
/// </summary>
internal abstract class PEModuleBuilder<TCompilation, TSourceModuleSymbol, TAssemblySymbol, TTypeSymbol, TNamedTypeSymbol, TMethodSymbol, TSyntaxNode, TEmbeddedTypesManager, TModuleCompilationState> : CommonPEModuleBuilder, ITokenDeferral
    where TCompilation : Compilation
    where TSourceModuleSymbol : class, IModuleSymbol
    where TAssemblySymbol : class, IAssemblySymbol
    where TTypeSymbol : class
    where TNamedTypeSymbol : class, TTypeSymbol, Cci.INamespaceTypeDefinition
    where TMethodSymbol : class, Cci.IMethodDefinition
    where TSyntaxNode : SyntaxNode
    where TEmbeddedTypesManager : CommonEmbeddedTypesManager
    where TModuleCompilationState : ModuleCompilationState<TNamedTypeSymbol, TMethodSymbol>
{
  ...
}

그런 다음 CSharpCodeanalysis 프로젝트에는 다음과 같은 정의가 있습니다.

internal abstract class PEModuleBuilder : PEModuleBuilder<CSharpCompilation, SourceModuleSymbol, AssemblySymbol, TypeSymbol, NamedTypeSymbol, MethodSymbol, SyntaxNode, NoPia.EmbeddedTypesManager, ModuleCompilationState>
{
  ...
}

이 제네릭이 아닌 PEModuleBuilder 클래스는 CSharpCodeanalysis 프로젝트에서 광범위하게 사용되며 해당 프로젝트의 여러 클래스가 직간접 적으로 상속됩니다.

그런 다음 BasicCodeanalysis 프로젝트에는 다음과 같은 정의가 있습니다.

Partial Friend MustInherit Class PEModuleBuilder
    Inherits PEModuleBuilder(Of VisualBasicCompilation, SourceModuleSymbol, AssemblySymbol, TypeSymbol, NamedTypeSymbol, MethodSymbol, SyntaxNode, NoPia.EmbeddedTypesManager, ModuleCompilationState)

우리는 Roslyn이 C #에 대한 광범위한 지식을 가진 사람들이 작성했다고 가정 할 수 있기 때문에 (어떻게 사용 해야하는지) 이것이 기술의 권장 사항이라고 생각합니다.

누군가 내 머리 꼭대기에서 그것을 시도하는 이유는 세 가지가 있습니다.

1) 선언을 단순화하려면 :

확실 StringList하고 ListString길이는 같지만 대신 UserCollection실제 Dictionary<Tuple<string,Type>, IUserData<Dictionary,MySerializer>>또는 다른 큰 일반적인 예 를 사용하고 있다고 상상해보십시오 .

2) AOT를 돕기 위해 :

때로는 iOS 용 개발과 같이 Just In Time Compilation이 아닌 Ahead Of Time 컴파일을 사용해야하는 경우가 있습니다. 때때로 AOT 컴파일러는 모든 제네릭 형식을 미리 알아 내기가 어려우므로 힌트를 제공하려는 시도 일 수 있습니다.

3) 기능을 추가하거나 종속성을 제거하려면

어쩌면 그들은 그들이 구현하려는 특정 기능이 StringList(아직 추가, 또는 기록하지, 확장 방법에 숨겨진 수)가 중 하나에 추가 할 수없는 List<string>그것에서 상속하지 않고, 또는 그들이 더럽 싶지 않아 List<string>와 .

또는 그들은 StringList다운 트랙 의 구현을 변경하고 싶을 수도 있으므로 클래스를 마커로 사용했습니다 (보통 인터페이스를 만들거나 사용하십시오 IList).

또한 Irony 에서이 코드를 찾았습니다.이 코드는 상당히 특이한 종류의 응용 프로그램 인 언어 파서입니다. 이것이 사용 된 다른 특정 이유가있을 수 있습니다.

이 예제는 너무 일반적이지 않더라도 그러한 선언을 작성해야하는 합법적 인 이유가있을 수 있음을 보여줍니다. 다른 것과 마찬가지로 몇 가지 옵션을 고려하고 당시에 가장 적합한 것을 선택하십시오.

소스 코드를 살펴보면 옵션 3이 이유 인 것 같습니다.이 기술을 사용하여 기능을 추가하고 컬렉션을 전문화합니다.

public class StringList : List<string> {
    public StringList() { }
    public StringList(params string[] args) {
      AddRange(args);
    }
    public override string ToString() {
      return ToString(" ");
    }
    public string ToString(string separator) {
      return Strings.JoinStrings(separator, this);
    }
    //Used in sorting suffixes and prefixes; longer strings must come first in sort order
    public static int LongerFirst(string x, string y) {
      try {//in case any of them is null
        if (x.Length > y.Length) return -1;
      } catch { }
      if (x == y) return 0;
      return 1; 
    }

나는 그것이 좋은 습관이 아니라고 말하고 싶습니다.

List<string>"일반 문자열 목록"을 전달합니다. 분명히 List<string> 확장 방법이 적용됩니다. 이해하는 데 복잡성이 줄어 듭니다. List 만 필요합니다.

StringList"별도의 클래스의 필요성"을 전달합니다. 아마도 List<string> 확장 메소드가 적용될 수 있습니다 (실제 유형 구현을 확인하십시오). 코드를 이해하려면 더 복잡해야합니다. 목록과 파생 클래스 구현 지식이 필요합니다.