Мой код завален коллекциями - полагаю, в этом нет ничего необычного. Однако использование различных типов коллекций не является очевидным или тривиальным. Как правило, я хотел бы использовать тип, который предоставляет «лучший» 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.