Список лучших практик / массив / ReadOnlyCollection создание (и использование)

Мой код завален коллекциями - полагаю, в этом нет ничего необычного. Однако использование различных типов коллекций не является очевидным или тривиальным. Как правило, я хотел бы использовать тип, который предоставляет «лучший» API и имеет наименьший синтаксический шум. (См. Рекомендации по возврату массива значений , Использование массивов списков - Лучшие практики для сопоставимых вопросов). Существуют рекомендации, предлагающие, какие типы использовать в API , но они непрактичны в обычном (не API) коде.

Например:

new ReadOnlyCollection>(
    new List> {
        Tuple.Create("abc",3),
        Tuple.Create("def",37)
    }
)

Список очень распространен структура данных, но создание их таким образом связано с довольно небольшим синтаксическим шумом - и может легко стать еще хуже (например, словари). Оказывается, многие списки никогда не меняются, или по крайней мере никогда не продлевался. Конечно, ReadOnlyCollection вносит еще больше синтаксического шума и даже не передает то, что я имею в виду; в конце концов, ReadOnlyCollection может обернуть коллекцию мутирующих . Иногда я использую массив внутри и возвращаю IEnumerable , чтобы указать намерение. Но у большинства этих подходов очень низкое отношение сигнал / шум; и это абсолютно важно для понимания кода.

Для 99% всего кода, который является не общедоступным API, нет необходимости следовать рекомендациям Framework: однако я все еще хочу понятный код и тип, который сообщает о намерениях.

Итак, что? - лучший способ справиться со стандартной задачей создания небольших коллекций для передачи значений? Должен ли массив быть предпочтительнее List , где это возможно? Что-то совсем другое? Какой лучший способ - чистый, читаемый, достаточно эффективный - передавать такие маленькие коллекции? В частности, код должен быть очевиден для будущих сопровождающих, которые не читали этот вопрос и не хотят читать куски документации API, но все же понимают, в чем заключается цель. Также очень важно минимизировать беспорядок в коде , поэтому такие вещи, как ReadOnlyCollection , в лучшем случае сомнительны. Нет ничего плохого в многословных типах для основных API с небольшими поверхностями, но не в качестве общей практики внутри большой кодовой базы.

Что? - лучший способ передать списки значений без большого количества кода (например, явных параметров типа), но при этом четко передать намерение?

Изменить: пояснил, что речь идет о создании короткого и понятного кода, а не о общедоступные API.

14
задан Community 23 May 2017 в 10:30
поделиться