2016-06-03 2 views
3

Я модифицирую весь свой код, чтобы он соответствовал FxCop, и это означало, что выкладывали множество массивов, списки в пользу ReadOnlyCollection, и я согласен с этим советом. Однако, при полученииПочему ReadOnlyCollection <ReadOnlyCollection <T>> плохой согласно FxCop и какова альтернатива при создании неизменяемого 2-мерного объекта?

ReadOnlyCollection<ReadOnlyCollection<T>> 

заменить двумерный массив или

List<List<T>> I now get the 

CA1006: Do not nest generic types in member signatures

жалоба. Во-первых, хотя он выглядит громоздким, он не кажется очень сложным или трудным для понимания, поскольку он по существу является неизменным List<List<T>>, который, как я полагаю, чрезвычайно распространен, учитывая недостатки массивов. Во-вторых, я не могу придумать альтернативу, которая хранит двумерные данные и неизменна, если только я не создаю для этого новый тип.

Что лучше всего здесь, пожалуйста. Может быть, это правило FxCop действительно не применяется здесь и должно быть подавлено?

Большое спасибо.

+0

Non-мнение, основанная часть вашего вопроса уже ответила на сайте ([CA1006] (http://stackoverflow.com/questions/14945199/do-not-nest -генерический-тип-в-члена-подпись)). Вы также можете рассматривать новые неизменные типы как альтернативные - http://stackoverflow.com/questions/210428/are-immutable-arrays-possible-in-net, что было бы лучшим выбором (поскольку ReadonlyCollection на самом деле не является неизменным - http: // stackoverflow.com/questions/32438988/readonlycollection-are-the-objects-immutable). –

+1

Действительно ли пользователь вашего типа надеется использовать его как коллекцию коллекций, или они ожидают использовать его в виде коллекции, которая требует двух индексов? Последнее кажется более вероятным; подумайте о том, чтобы создать собственный тип коллекции, который использует «вложенную» коллекцию как это в качестве детали реализации, а не как публичный интерфейс. –

+0

@EricLippert Пользователь хочет коллекцию с двумя индексами. Синтаксис массива намного проще, чем набор коллекций, и учитывая, что его нельзя каким-либо образом изменить, я не вижу никаких преимуществ последнего. Я не думаю, что такой массив существует, что удивляет меня, как я думал, что многие другие разработчики пройдут по тому же пути, что и я, из а) Передача неизменяемых массивов для устранения неожиданного. b) Обеспечение безопасности потоков c) Сокращение изменений и, следовательно, сложность d) Придерживание FxCop.Я думаю, что мой лучший вариант - ImmutableList >. – Pedruski

ответ

-1

Комментарии на этот пост, кажется, здесь также:

Предупреждение является общее предупреждение должно помочь вам разработать лучший и простой открытый интерфейс. В этом случае вы получите предупреждение о с параметром Expression> в вашем методе . Однако для этого метода нет смысла упрощать тип , и вместо этого вы должны подавлять предупреждение с использованием атрибута или полностью удалить правило из вашего набора правил.

Глупый пример, в котором вы, вероятно, следует рассмотреть после советы правила является метод так:

общественного недействительными F (Dictionary<String, List<Tuple<<String, Int32>>> словарь);

Martin Ответ Liversage в @https://stackoverflow.com/a/14945331/1775528

+0

Пожалуйста, проголосуйте/отметьте, чтобы закрыть как дубликат, если вы считаете, что точного ответа на другой вопрос достаточно. Отправка всего ответа (даже с атрибуцией) не является хорошей практикой. –

+0

, если вы считаете, что это ответ, тогда отметьте этот вопрос как дубликат. –

+0

@Tyler Спасибо за это. Является ReadOnlyCollection > общей конструкцией, потому что я не нашел много примеров ее использования, но я бы подумал, что это будет очень часто, когда желательна неизменность. – Pedruski

Смежные вопросы