เป็นการดีที่จะสืบทอดจากประเภททั่วไปหรือไม่?

มันจะดีกว่าที่จะใช้List<string>ในคำอธิบายประกอบประเภทหรือStringListที่ไหนStringList

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

ฉันวิ่งเข้าไปในหลายของเหล่านี้ในประชด

มีอีกเหตุผลที่คุณอาจต้องการรับช่วงจากประเภททั่วไป

ไมโครซอฟท์แนะนำให้หลีกเลี่ยงประเภททั่วไปทำรังในลายเซ็นวิธี

ดังนั้นจึงเป็นความคิดที่ดีที่จะสร้างชื่อโดเมนประเภทธุรกิจสำหรับข้อมูลทั่วไปของคุณ แทนที่จะมี a IEnumerable<IDictionary<string, MyClass>>ให้สร้างประเภทMyDictionary : IDictionary<string, MyClass>จากนั้นสมาชิกของคุณจะกลายเป็น an 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 ใด ๆ พวกเขาสามารถรับ Constructor ทั่วไปได้ อย่างไรก็ตามหากมันไม่เหมาะสมกับธุรกิจที่จะใช้หนึ่งในสองประเภทที่ได้รับผู้พัฒนาสามารถ จำกัด พารามิเตอร์ตัวสร้างเป็นประเภทเฉพาะ

โดยสรุปมันมักจะคุ้มค่าที่จะได้รับประเภทจากประเภททั่วไป - มันช่วยให้รหัสที่ชัดเจนมากขึ้นที่เหมาะสมและช่วยให้สามารถอ่านและบำรุงรักษา

ในหลักการไม่มีความแตกต่างระหว่างการสืบทอดจากประเภททั่วไปและการสืบทอดจากสิ่งอื่นใด

อย่างไรก็ตามทำไมบนโลกนี้คุณจะได้รับจากชั้นเรียนใด ๆและไม่เพิ่มอะไรอีกเลย?

ฉันไม่รู้ C # ดีมาก แต่ฉันเชื่อว่านี่เป็นวิธีเดียวที่จะใช้ a typedefซึ่งโปรแกรมเมอร์ C ++ มักใช้ด้วยเหตุผลบางประการ:

• มันทำให้โค้ดของคุณดูไม่เหมือนทะเลของวงเล็บมุม
• มันช่วยให้คุณสามารถแลกเปลี่ยนคอนเทนเนอร์พื้นฐานที่แตกต่างกันหากความต้องการของคุณเปลี่ยนแปลงในภายหลังและทำให้ชัดเจนว่าคุณขอสงวนสิทธิ์ในการทำเช่นนั้น
• ช่วยให้คุณสามารถพิมพ์ชื่อที่เกี่ยวข้องในบริบทมากกว่า

พวกเขาทิ้งข้อได้เปรียบล่าสุดโดยเลือกชื่อสามัญที่น่าเบื่อ แต่อีกสองเหตุผลยังคงอยู่

ฉันสามารถคิดถึงเหตุผลเชิงปฏิบัติอย่างน้อยหนึ่งข้อ

การประกาศประเภทที่ไม่ใช่ประเภททั่วไปที่สืบทอดมาจากประเภททั่วไป (แม้จะไม่เพิ่มอะไรก็ตาม) อนุญาตให้มีการอ้างอิงประเภทเหล่านั้นจากสถานที่ที่พวกเขาจะไม่สามารถใช้งานได้หรือมีวิธีที่ซับซ้อนกว่าที่ควรเป็น

กรณีหนึ่งคือเมื่อเพิ่มการตั้งค่าผ่านตัวแก้ไขการตั้งค่าใน Visual Studio ซึ่งดูเหมือนว่าจะมีเฉพาะประเภทที่ไม่ใช่ทั่วไปเท่านั้น หากคุณไปที่นั่นคุณจะสังเกตเห็นว่าSystem.Collectionsมีคลาสทั้งหมดแต่ไม่มีคอลเลกชันSystem.Collections.Genericปรากฏขึ้น

อีกกรณีคือเมื่อสร้างอินสแตนซ์ประเภทผ่าน XAML ใน WPF ไม่มีการสนับสนุนสำหรับการส่งผ่านอาร์กิวเมนต์ชนิดในไวยากรณ์ XML เมื่อใช้สกีมา pre-2009 สิ่งนี้ทำให้แย่ลงเนื่องจากข้อเท็จจริงที่ว่าสคีมาปี 2549 ดูเหมือนจะเป็นค่าเริ่มต้นสำหรับโครงการ WPF ใหม่

ฉันคิดว่าคุณต้องดูเป็นบางประวัติศาสตร์

• มีการใช้ C # เป็นเวลานานกว่ารุ่นทั่วไป
• ฉันคาดหวังว่าซอฟต์แวร์ที่กำหนดมี StringList ของตัวเอง ณ จุดหนึ่งในประวัติศาสตร์
• สิ่งนี้อาจถูกนำไปใช้โดยการห่อ ArrayList
• จากนั้นมีคน a ไปที่ refactoring เพื่อย้ายโค้ดไปข้างหน้า
• แต่ไม่ต้องการแตะที่ 1001 ไฟล์ที่แตกต่างกันดังนั้นจบงาน

มิฉะนั้น Theodoros Chatzigiannakis ก็มีคำตอบที่ดีที่สุดเช่นมีเครื่องมือมากมายที่ไม่เข้าใจประเภททั่วไป หรืออาจเป็นการผสมผสานระหว่างคำตอบและประวัติของเขา

ในบางกรณีมันเป็นไปไม่ได้ที่จะใช้ประเภททั่วไปเช่นคุณไม่สามารถอ้างอิงประเภททั่วไปใน XAML ในกรณีเหล่านี้คุณสามารถสร้างประเภทที่ไม่ใช่แบบทั่วไปซึ่งสืบทอดมาจากประเภททั่วไปที่คุณต้องการใช้ในตอนแรก

ถ้าเป็นไปได้ฉันจะหลีกเลี่ยง

แตกต่างจาก typedef คุณสร้างประเภทใหม่ ถ้าคุณใช้ StringList List<string>เป็นพารามิเตอร์ที่ป้อนให้กับวิธีการโทรของคุณไม่สามารถผ่าน

นอกจากนี้คุณจะต้องคัดลอก Constructor ทั้งหมดที่คุณต้องการใช้อย่างชัดเจนในตัวอย่าง StringList ที่คุณไม่สามารถพูดnew StringList(new[]{"a", "b", "c"})ได้แม้ว่าจะList<T>กำหนดตัวสร้างเช่นนั้น

แก้ไข:

คำตอบที่ได้รับการยอมรับจะมุ่งเน้นไปที่โปรเมื่อใช้ประเภทที่ได้รับภายในรูปแบบโดเมนของคุณ ฉันขอยืนยันว่าพวกเขาอาจมีประโยชน์ในกรณีนี้ แต่โดยส่วนตัวแล้วฉันจะหลีกเลี่ยงพวกเขาแม้ที่นั่น

แต่คุณควร (ในความคิดของฉัน) ไม่ควรใช้พวกเขาใน API สาธารณะเพราะคุณทำให้ชีวิตผู้โทรของคุณยากขึ้นหรือเสียประสิทธิภาพ (ฉันไม่ชอบการแปลงโดยนัยจริงๆ)

นี่คือตัวอย่างของการสืบทอดจากคลาสทั่วไปในคอมไพเลอร์ Roslyn ของ Microsoft และโดยไม่ต้องเปลี่ยนชื่อของคลาส (ฉันรู้สึกสับสนด้วยสิ่งนี้ฉันเลยลงเอยที่นี่เพื่อค้นหาว่ามันเป็นไปได้จริง ๆ หรือไม่)

ใน 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) เพื่อช่วยทอท.:

บางครั้งคุณต้องใช้การรวบรวมล่วงหน้าไม่เพียงรวบรวมเวลา - เช่นการพัฒนาสำหรับ iOS บางครั้งคอมไพเลอร์ 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>ความซับซ้อนน้อยกว่านั้นจะต้องเข้าใจ รายการเท่านั้นที่จำเป็น

StringListสื่อสาร "ต้องแยกชั้น" อาจ List<string>ใช้วิธีการขยาย (ตรวจสอบการใช้งานจริงประเภทนี้) จำเป็นต้องมีความซับซ้อนมากขึ้นในการทำความเข้าใจโค้ด รายการและความรู้การใช้งานคลาสที่ได้รับจำเป็นต้องมี