Является ли использование .NET 4.0 кортежей в моем коде 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 );

В приведенном выше примере мы хотим представить пару противников, кортеж является удобным способом объединения этих экземпляров без необходимости создания нового класса. Вот еще один пример:

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

Покерную комбинацию можно рассматривать как набор карт - и кортеж (может быть) является разумным способом выражения этой концепции.

оставляя в стороне возможность того, что я упускаю точку зрения Tuples, является ли пример с Tuple плохим выбором дизайна?

Возвращение строго типизированных Tuple<>экземпляров как части открытого API для открытого типа редко является хорошей идеей. Как вы сами понимаете, кортежи требуют, чтобы вовлеченные стороны (автор библиотеки, пользователь библиотеки) заранее договорились о цели и интерпретации используемых типов кортежей. Достаточно сложно создать интуитивно понятные и понятные API-интерфейсы, которые Tuple<>публично скрывают только намерения и поведение API.

Анонимные типы также являются своего рода кортежем, однако они строго типизированы и позволяют указывать понятные, информативные имена для свойств, принадлежащих типу. Но анонимные типы сложно использовать в разных методах - они были в основном добавлены для поддержки таких технологий, как LINQ, где проекции будут создавать типы, которым мы обычно не хотим назначать имена. (Да, я знаю, что анонимные типы с одинаковыми типами и именованными свойствами объединяются компилятором).

Мое эмпирическое правило таково: если вы вернете его из открытого интерфейса, сделайте его именованным типом .

Мое другое практическое правило использования кортежей: аргументы метода имени и переменные типа 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, Ageили были они UnitNumber, Street, City, ZipCode.

С точки зрения программиста на C #, кортежи являются довольно подавляющим дополнением к CLR. Если у вас есть коллекция элементов различной длины, вам не нужно иметь уникальные статические имена во время компиляции.

Но если у вас есть коллекция постоянной длины, это означает, что каждое из фиксированных местоположений в коллекции имеет определенное предопределенное значение. И в этом случае всегда лучше дать им соответствующие статические имена, чем помнить о значении 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). Это еще более важно, если типы двух полей одинаковы: имя четко различает их.

Как насчет использования кортежей в шаблоне decorate-sort-undecorate? Преобразование Шварца для людей 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 [] из двух элементов или в этом конкретном примере строку [] из двух элементов. Дело в том, что я мог бы использовать что угодно как второй элемент в кортеже, который используется внутри и довольно легко читается.

IMO, эти "кортежи" - это в основном все анонимные structтипы с открытым доступом с неназванными участниками .

Только место , где я хотел бы использовать кортеж , когда вам нужно быстро BLOb вместе некоторые данные, в очень ограниченном объеме. Семантика данных должна быть очевидна , поэтому код не сложен для чтения. Поэтому использование tuple ( int, int) для (row, col) кажется разумным. Но мне трудно найти преимущество передstruct именованными членами (так что никаких ошибок не делается, и строка / столбец не случайно меняются местами)

Если вы отправляете данные обратно абоненту или принимаете данные от абонента, вам действительно следует использовать struct с именованными участниками.

Возьмите простой пример:

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

Версия кортежа

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

Я не вижу никакого преимущества в использовании кортежа вместо структуры с именованными членами. Использование неназванных членов - это шаг назад для читабельности и понятности вашего кода.

Tuple кажется мне ленивым способом избежать создания structс настоящими именованными участниками. Чрезмерное использование кортежа, когда вы действительно чувствуете, что вам / или кому-то другому, сталкивающемуся с вашим кодом, понадобятся именованные участники - A Bad Thing ™, если я когда-либо видел его.

Не судите меня, я не эксперт, но теперь с новыми кортежами в C # 7.x вы можете вернуть что-то вроде:

return (string Name1, int Name2)

По крайней мере, теперь вы можете назвать его, и разработчики могут увидеть некоторую информацию.

Это зависит, конечно! Как вы сказали, кортеж может сэкономить ваш код и время, когда вы хотите сгруппировать некоторые элементы вместе для локального потребления. Вы также можете использовать их для создания более общих алгоритмов обработки, чем если бы вы передавали конкретный класс. Я не могу вспомнить, сколько раз мне хотелось, чтобы у меня было что-то помимо KeyValuePair или DataRow, чтобы быстро передавать некоторую дату из одного метода в другой.

С другой стороны, вполне возможно переусердствовать и обойти кортежи, где можно только догадываться, что они содержат. Если вы собираетесь использовать кортеж между классами, возможно, было бы лучше создать один конкретный класс.

Разумеется, при использовании в качестве модераторов кортежи могут привести к получению более краткого и удобочитаемого кода. Вы можете посмотреть на C ++, STL и Boost, чтобы найти примеры того, как кортежи используются в других языках, но в итоге нам всем придется поэкспериментировать, чтобы найти, как они лучше всего подходят для среды .NET.

Кортежи - это бесполезная фреймворк в .NET 4. Я думаю, что в C # 4.0 была упущена отличная возможность. Я хотел бы иметь кортежи с именованными членами, чтобы вы могли получить доступ к различным полям кортежа по имени вместо Value1 , Value2 и т. Д.

Это потребовало бы изменения языка (синтаксиса), но это было бы очень полезно.

Лично я бы никогда не использовал Tuple в качестве возвращаемого типа, потому что нет никаких указаний на то, что представляют значения. У кортежей есть несколько полезных применений, потому что в отличие от объектов они являются типами значений и, следовательно, понимают равенство. Из-за этого я буду использовать их в качестве ключей словаря, если мне нужен многокомпонентный ключ, или в качестве ключа для предложения GroupBy, если я хочу группировать по нескольким переменным и не хочу вложенных группировок (Кто когда-либо хочет вложенные группировки?). Чтобы преодолеть проблему с чрезвычайным многословием, вы можете создать их с помощью вспомогательного метода. Имейте в виду, что если вы часто обращаетесь к членам (через Item1, Item2 и т. Д.), Вам, вероятно, следует использовать другую конструкцию, такую ​​как struct или анонимный класс.

Я использовал кортежи, как Tupleи новые ValueTuple, в ряде различных сценариев и пришел к следующему выводу: не использовать .

Каждый раз я сталкивался со следующими проблемами:

• код стал нечитаемым из-за отсутствия сильных имен;
• невозможно использовать функции иерархии классов, такие как DTO базового класса и DTO дочернего класса и т. д .;
• если они используются более чем в одном месте, вы в конечном итоге копируете и вставляете эти уродливые определения вместо чистого имени класса.

Мое мнение, что кортежи - это вред, а не особенность C #.

У меня несколько похожая, но гораздо менее резкая критика Func<>и Action<>. Они полезны во многих ситуациях, особенно в простых Actionи Func<type>вариантах, но, помимо всего прочего, я обнаружил, что создание типа делегата является более элегантным, читаемым, обслуживаемым и дает вам больше возможностей, таких как ref/ outпараметры.