การใช้. NET 4.0 Tuples ในรหัส C # ของฉันเป็นการตัดสินใจออกแบบที่ไม่ดีหรือไม่?

ด้วยการเพิ่มคลาสTupleใน. net 4 ฉันพยายามตัดสินใจว่าการใช้มันในการออกแบบของฉันนั้นเป็นตัวเลือกที่ไม่ดีหรือไม่ วิธีที่ฉันเห็นมันTupleสามารถเป็นทางลัดในการเขียนคลาสผลลัพธ์ (ฉันแน่ใจว่ามีการใช้อื่น ๆ ด้วย)

ดังนั้นนี่:

public class ResultType
{
    public string StringValue { get; set; }
    public int IntValue { get; set; }
}

public ResultType GetAClassedValue()
{
    //..Do Some Stuff
    ResultType result = new ResultType { StringValue = "A String", IntValue = 2 };
    return result;
}

เทียบเท่ากับสิ่งนี้:

public Tuple<string, int> GetATupledValue()
{
    //...Do Some stuff
    Tuple<string, int> result = new Tuple<string, int>("A String", 2);
    return result;
}

ดังนั้นการตั้งค่าความเป็นไปได้ที่ฉันพลาดจุด Tuples เป็นตัวอย่างของTuple ที่เป็นตัวเลือกการออกแบบที่ไม่ดีหรือไม่? สำหรับฉันดูเหมือนว่าจะมีความยุ่งเหยิงน้อยลง แต่ไม่ใช่เอกสารและทำความสะอาดตัวเอง ความหมายที่มีชนิดResultTypeนั้นชัดเจนมากในภายหลังในสิ่งที่แต่ละส่วนของชั้นเรียนหมายถึง แต่คุณมีรหัสพิเศษที่จะรักษา ด้วยการที่Tuple<string, int>คุณจะต้องค้นหาและคิดออกว่าแต่ละItemหมายถึง แต่คุณเขียนและรักษารหัสน้อย

ประสบการณ์ใด ๆ ที่คุณมีกับตัวเลือกนี้จะได้รับการชื่นชมอย่างมาก

สิ่งอันดับที่ดีถ้าคุณควบคุมทั้งการสร้างและการใช้พวกเขา - คุณสามารถรักษาบริบทซึ่งเป็นสิ่งสำคัญในการทำความเข้าใจพวกเขา

อย่างไรก็ตามใน API สาธารณะจะมีประสิทธิภาพน้อยกว่า ผู้บริโภค (ไม่) Tuple<int, int>มีการคาดเดาหรือดูเอกสารโดยเฉพาะอย่างยิ่งสำหรับสิ่งที่ต้องการ

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

คำตอบนี้ยังมีข้อมูลบางอย่าง

วิธีที่ฉันเห็นมัน Tuple เป็นทางลัดในการเขียนคลาสผลลัพธ์ (ฉันแน่ใจว่ามีการใช้อื่น ๆ ด้วย)

มีประโยชน์อื่น ๆ ที่มีคุณค่าสำหรับTuple<> - ส่วนใหญ่เกี่ยวข้องกับการแยกความหมายของกลุ่มเฉพาะประเภทที่ใช้โครงสร้างที่คล้ายกันและรักษาพวกเขาเพียงแค่สั่งชุดของค่า ในทุกกรณีประโยชน์ของสิ่งอันดับคือพวกเขาหลีกเลี่ยงความยุ่งเหยิงในเนมสเปซของคุณด้วยคลาสข้อมูลอย่างเดียวที่เปิดเผยคุณสมบัติ แต่ไม่ใช่วิธีการ

นี่คือตัวอย่างของการใช้งานที่สมเหตุสมผลสำหรับTuple<>:

var opponents = new Tuple<Player,Player>( playerBob, playerSam );

ในตัวอย่างข้างต้นเราต้องการแสดงคู่ของคู่ต่อสู้ tuple เป็นวิธีที่สะดวกในการจับคู่อินสแตนซ์เหล่านี้โดยไม่ต้องสร้างคลาสใหม่ นี่เป็นอีกตัวอย่าง:

var pokerHand = Tuple.Create( card1, card2, card3, card4, card5 );

มือโป๊กเกอร์สามารถคิดได้ว่าเป็นเพียงชุดไพ่ - และ tuple (อาจ) เป็นวิธีที่สมเหตุสมผลในการแสดงแนวคิดนั้น

ตั้งค่าความเป็นไปได้ที่ฉันพลาดจุด Tuples เป็นตัวอย่างที่ Tuple เป็นตัวเลือกการออกแบบที่ไม่ดีหรือไม่?

การส่งคืนTuple<>อินสแตนซ์ที่พิมพ์อย่างมากซึ่งเป็นส่วนหนึ่งของ API สาธารณะสำหรับประเภทสาธารณะไม่ค่อยเป็นความคิดที่ดี ในขณะที่คุณรับรู้สิ่งอันดับ tuples ต้องการฝ่ายต่างๆที่เกี่ยวข้อง (ผู้เขียนห้องสมุดผู้ใช้ห้องสมุด) เพื่อตกลงล่วงหน้าเกี่ยวกับวัตถุประสงค์และการตีความประเภท tuple ที่ใช้ มันท้าทายพอที่จะสร้าง API ที่ใช้งานง่ายและชัดเจนโดยใช้Tuple<>สาธารณะเท่านั้นบดบังเจตนาและพฤติกรรมของ API

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

My กฎของหัวแม่มือคือ: ถ้าคุณจะกลับมาได้จากอินเตอร์เฟซที่สาธารณะของคุณ - ทำให้มันเป็นชื่อประเภท

กฎง่ายๆอีกข้อของฉันสำหรับการใช้สิ่งอันดับคือ: อาร์กิวเมนต์เมธอดชื่อและตัวแปร localc ประเภทTuple<>อย่างชัดเจนที่สุด - ทำให้ชื่อเป็นตัวแทนของความหมายของความสัมพันธ์ระหว่างองค์ประกอบของสิ่งอันดับ นึกถึงvar opponents = ...ตัวอย่างของฉัน

นี่คือตัวอย่างของกรณีจริงที่ฉันเคยTuple<>หลีกเลี่ยงการประกาศชนิดข้อมูลอย่างเดียวเพื่อใช้ภายในแอสเซมบลีของตัวเองเท่านั้น สถานการณ์เกี่ยวข้องกับข้อเท็จจริงที่ว่าเมื่อใช้พจนานุกรมทั่วไปที่มีประเภทที่ไม่ระบุตัวตนมันเป็นการยากที่จะใช้TryGetValue()วิธีการค้นหารายการในพจนานุกรมเพราะวิธีการนั้นต้องการoutพารามิเตอร์ที่ไม่สามารถตั้งชื่อได้:

public static class DictionaryExt 
{
    // helper method that allows compiler to provide type inference
    // when attempting to locate optionally existent items in a dictionary
    public static Tuple<TValue,bool> Find<TKey,TValue>( 
        this IDictionary<TKey,TValue> dict, TKey keyToFind ) 
    {
        TValue foundValue = default(TValue);
        bool wasFound = dict.TryGetValue( keyToFind, out foundValue );
        return Tuple.Create( foundValue, wasFound );
    }
}

public class Program
{
    public static void Main()
    {
        var people = new[] { new { LastName = "Smith", FirstName = "Joe" },
                             new { LastName = "Sanders", FirstName = "Bob" } };

        var peopleDict = people.ToDictionary( d => d.LastName );

        // ??? foundItem <= what type would you put here?
        // peopleDict.TryGetValue( "Smith", out ??? );

        // so instead, we use our Find() extension:
        var result = peopleDict.Find( "Smith" );
        if( result.First )
        {
            Console.WriteLine( result.Second );
        }
    }
}

PSมีอีกวิธีหนึ่ง (เรียบง่าย) ในการแก้ไขปัญหาที่เกิดจากประเภทที่ไม่ระบุชื่อในพจนานุกรมและนั่นคือการใช้varคำหลักเพื่อให้คอมไพเลอร์ 'อนุมาน' ประเภทสำหรับคุณ นี่คือรุ่นของ:

var foundItem = peopleDict.FirstOrDefault().Value;
if( peopleDict.TryGetValue( "Smith", out foundItem ) )
{
   // use foundItem...
}

สิ่งอันดับจะมีประโยชน์ ... แต่พวกเขาก็สามารถเจ็บปวดได้ในภายหลัง หากคุณมีวิธีที่คืนค่าTuple<int,string,string,int>คุณจะรู้ได้อย่างไรว่าค่าเหล่านั้นคืออะไรในภายหลัง พวกเขาหรือพวกเขาID, FirstName, LastName, AgeUnitNumber, Street, City, ZipCode

Tuples ค่อนข้างน่าสนใจนอกเหนือจาก CLR จากมุมมองของโปรแกรมเมอร์ C # หากคุณมีการรวบรวมรายการที่มีความยาวต่างกันคุณไม่จำเป็นต้องมีชื่อคงที่ที่ไม่ซ้ำกันในเวลารวบรวม

แต่ถ้าคุณมีคอลเลกชันที่มีความยาวคงที่นี่ก็หมายความว่าสถานที่ตั้งในคอลเลกชันแต่ละแห่งมีความหมายที่กำหนดไว้ล่วงหน้าเฉพาะ และมันก็เป็นเสมอดีกว่าที่จะให้พวกเขามีชื่อแบบคงที่ที่เหมาะสมในกรณีที่แทนที่จะต้องจำความสำคัญของItem1, Item2ฯลฯ

คลาสที่ไม่เปิดเผยตัวตนใน C # ได้เสนอวิธีแก้ปัญหาที่ยอดเยี่ยมสำหรับการใช้งานทูเปิลส่วนตัวทั่วไปและพวกเขาให้ชื่อที่มีความหมายกับไอเท็มดังนั้นพวกมันจึงเหนือกว่าในแง่นั้น ปัญหาเดียวคือพวกเขาไม่สามารถรั่วไหลออกจากวิธีการตั้งชื่อ ฉันต้องการที่จะเห็นข้อ จำกัด ที่ยกขึ้น (อาจเป็นเพียงวิธีส่วนตัว) กว่ามีการสนับสนุนเฉพาะสำหรับสิ่งอันดับใน C #:

private var GetDesserts()
{
    return _icecreams.Select(
        i => new { icecream = i, topping = new Topping(i) }
    );
}

public void Eat()
{
    foreach (var dessert in GetDesserts())
    {
        dessert.icecream.AddTopping(dessert.topping);
        dessert.Eat();
    }
}

เช่นเดียวกับคำหลักvarมันมีจุดประสงค์เพื่อความสะดวก แต่มีการละเมิดอย่างง่ายดาย

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

// one possible use of tuple within a private context. would never
// return an opaque non-descript instance as a result, but useful
// when scope is known [ie private] and implementation intimacy is
// expected
public class WorkflowHost
{
    // a map of uri's to a workflow service definition 
    // and workflow service instance. By convention, first
    // element of tuple is definition, second element is
    // instance
    private Dictionary<Uri, Tuple<WorkflowService, WorkflowServiceHost>> _map = 
        new Dictionary<Uri, Tuple<WorkflowService, WorkflowServiceHost>> ();
}

การใช้คลาสResultTypeไลค์นั้นชัดเจนกว่า คุณสามารถให้ชื่อที่มีความหมายกับฟิลด์ในชั้นเรียน (ในขณะที่มีสิ่งอันดับพวกเขาจะถูกเรียกItem1และItem2) สิ่งนี้สำคัญยิ่งกว่าหากประเภทของทั้งสองฟิลด์เหมือนกัน: ชื่อจะแยกความแตกต่างระหว่างทั้งสองอย่างชัดเจน

วิธีการเกี่ยวกับการใช้ Tuples ในรูปแบบการตกแต่งเรียงลำดับไม่ได้ตกแต่ง? (Schwartzian Transform สำหรับคน Perl) นี่คือตัวอย่างที่คาดการณ์ไว้เพื่อให้แน่ใจ แต่ Tuples ดูเหมือนจะเป็นวิธีที่ดีในการจัดการสิ่งนี้:

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            string[] files = Directory.GetFiles("C:\\Windows")
                    .Select(x => new Tuple<string, string>(x, FirstLine(x)))
                    .OrderBy(x => x.Item2)
                    .Select(x => x.Item1).ToArray();
        }
        static string FirstLine(string path)
        {
            using (TextReader tr = new StreamReader(
                        File.Open(path, FileMode.Open)))
            {
                return tr.ReadLine();
            }
        }
    }
}

ตอนนี้ฉันสามารถใช้ Object [] ของสององค์ประกอบหรือในตัวอย่างเฉพาะนี้เป็นสตริง [] ของสององค์ประกอบ ประเด็นคือฉันสามารถใช้อะไรก็ได้เป็นองค์ประกอบที่สองใน Tuple ที่ใช้ภายในและอ่านง่าย

IMO เหล่านี้ "tuples" มีพื้นการเข้าถึงของประชาชนที่ไม่ระบุชื่อstructประเภทที่มีสมาชิกชื่อ

ที่เดียวที่ฉันจะใช้ tuple คือเมื่อคุณต้องการหยดข้อมูลบางอย่างเข้าด้วยกันอย่างรวดเร็วในขอบเขตที่ จำกัด มาก ความหมายของข้อมูลควรชัดเจนดังนั้นรหัสจึงไม่ยากที่จะอ่าน ดังนั้นการใช้ tuple ( int, int) สำหรับ (row, col) ดูเหมือนสมเหตุสมผล แต่ฉันรู้สึกกดดันที่จะหาข้อได้เปรียบเหนือstructสมาชิกที่มีชื่อ (ดังนั้นจึงไม่มีข้อผิดพลาดเกิดขึ้นและแถว / คอลัมน์ไม่ได้ถูกสับเปลี่ยนโดยไม่ตั้งใจ)

หากคุณกำลังส่งข้อมูลกลับไปยังผู้โทรหรือรับข้อมูลจากผู้โทรคุณควรใช้ a structกับสมาชิกที่มีชื่อ

ยกตัวอย่างง่ายๆ

struct Color{ float r,g,b,a ; }
public void setColor( Color color )
{
}

รุ่น tuple

public void setColor( Tuple<float,float,float,float> color )
{
  // why?
}

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

Tuple ทำให้ฉันขี้เกียจเพื่อหลีกเลี่ยงการสร้างstructสมาชิกที่มีชื่อจริง การใช้ tuple มากเกินไปซึ่งคุณรู้สึกว่าคุณ / หรือคนอื่นที่ต้องเผชิญกับรหัสของคุณจะต้องมีสมาชิกที่มีชื่อคือ A Bad Thing ™หากฉันเคยเห็น

อย่าตัดสินฉันไม่ใช่ผู้เชี่ยวชาญ แต่ด้วย Tuples ใหม่ใน C # 7.x ตอนนี้คุณสามารถส่งคืนสิ่งที่ชอบ:

return (string Name1, int Name2)

อย่างน้อยตอนนี้คุณสามารถตั้งชื่อได้และนักพัฒนาอาจเห็นข้อมูลบางอย่าง

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

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

ใช้ในการดูแลของหลักสูตร tuples สามารถนำไปสู่รหัสรัดกุมและอ่านง่ายขึ้น คุณสามารถดู C ++, STL และ Boost สำหรับตัวอย่างของการใช้ Tuples ในภาษาอื่น ๆ แต่ในที่สุดเราทุกคนจะต้องทดสอบเพื่อหาวิธีที่เหมาะสมที่สุดในสภาพแวดล้อม. NET

Tuples เป็นคุณสมบัติที่ไม่มีประโยชน์ใน. NET 4. ฉันคิดว่าโอกาสที่ยอดเยี่ยมพลาดไปกับ C # 4.0 ฉันอยากจะมีความรักที่จะมี tuples กับสมาชิกในการตั้งชื่อเพื่อให้คุณสามารถเข้าถึงด้านต่างๆของ tuple โดยใช้ชื่อแทนค่า 1 , Value2ฯลฯ ...

มันจะต้องมีการเปลี่ยนแปลงภาษา (ไวยากรณ์) แต่มันจะมีประโยชน์มาก

ฉันจะไม่ใช้ Tuple เป็นชนิดส่งคืนเป็นการส่วนตัวเนื่องจากไม่มีสิ่งบ่งชี้ว่าค่าแสดงถึงอะไร สิ่งอันดับมีประโยชน์เนื่องจากแตกต่างจากวัตถุที่เป็นประเภทค่าจึงเข้าใจความเท่าเทียมกัน ด้วยเหตุนี้ฉันจะใช้พวกเขาเป็นคีย์พจนานุกรมถ้าฉันต้องการคีย์หลายส่วนหรือเป็นคีย์สำหรับประโยค GroupBy ถ้าฉันต้องการจัดกลุ่มตามตัวแปรหลายตัวและไม่ต้องการการจัดกลุ่มแบบซ้อนกัน (ใครเคยต้องการการจัดกลุ่มซ้อนกัน) เพื่อแก้ไขปัญหาด้วยการใช้คำฟุ่มเฟื่อยมากคุณสามารถสร้างพวกเขาด้วยวิธีการช่วยเหลือ โปรดจำไว้ว่าถ้าคุณเข้าถึงสมาชิก (ผ่านรายการ 1, รายการ 2, ฯลฯ ) บ่อยครั้งคุณควรใช้โครงสร้างที่แตกต่างกันเช่นโครงสร้างหรือคลาสที่ไม่ระบุชื่อ

ฉัน tuples สินค้าทั้งTupleใหม่และValueTupleในจำนวนของสถานการณ์ที่แตกต่างกันและมาถึงข้อสรุปต่อไปนี้: ไม่ได้ใช้

ทุกครั้งที่ฉันพบปัญหาต่อไปนี้:

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

ความคิดเห็นของฉันคือ tuples เป็นความเสียหายไม่ใช่คุณลักษณะของ C #

ฉันมีค่อนข้างคล้ายกัน แต่มีจำนวนมากที่รุนแรงน้อยกว่าการวิจารณ์ของและFunc<> Action<>สิ่งเหล่านั้นมีประโยชน์ในหลาย ๆ สถานการณ์โดยเฉพาะอย่างยิ่งสิ่งที่เรียบง่ายActionและFunc<type>หลากหลาย แต่นอกเหนือจากนั้นฉันพบว่าการสร้างประเภทของผู้ร่วมประชุมนั้นสง่างามอ่านง่ายบำรุงรักษาและให้คุณสมบัติเพิ่มเติมเช่นref/ outพารามิเตอร์