Почему ReadOnlyCollection <> не включает такие методы, как FindAll (), FindFirst (),

Question

Следуя советам FxCop и моим личным склонностям, я поощряю команду, которую обучаю, использовать ReadOnlyCollections в максимально возможной степени. Если только так, чтобы получатели списков не могли изменить свое содержание. В их теории это хлеб с маслом. Проблема в том, что интерфейс List <> гораздо богаче, предоставляя всевозможные полезные методы. Почему они сделали этот выбор?

Вы просто отказываетесь и возвращаете записываемые коллекции? Вы возвращаете коллекции только для чтения и затем оборачиваете их в доступный для записи вариант? Ahhhhh.

---

Обновление: Спасибо, я знаком с Руководством по проектированию фреймворка и поэтому команда использует FxCop для его реализации. Тем не менее, эта команда живет с VS 2005 (я знаю, я знаю), и поэтому, говоря им, что методы LINQ / Extension решат их проблемы, просто огорчает их.

Они узнали, что List.FindAll () и .FindFirst () обеспечивают большую ясность, чем написание цикла foreach. Теперь я подталкиваю их к использованию ReadOnlyCollections, они теряют эту ясность.

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

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

Answer 1

Прежде всего, ReadOnlyCollection<T> реализует IEnumerable<T> и IList<T>. Со всеми методами расширения в .NET 3.5 и LINQ у вас есть доступ почти ко всем функциональным возможностям исходного класса List<T> с точки зрения запросов, и это все, что вы должны делать с ReadOnlyCollection<T> в любом случае.

При этом ваш первоначальный вопрос побуждает меня делать некоторые предложения ...

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

" НЕ использовать ArrayList или List<T> в публичных API." (Стр. 251)

Если принять это во внимание, то у ReadOnlyCollection<T> нет абсолютно никаких недостатков по сравнению с List<T>. Оба эти класса реализуют IEnumerable<T> и IList<T>, которые являются интерфейсами, которые должны быть возвращены в любом случае.

Answer 2

Раздел 8.3.2 .NET Framework Руководства по проектированию, второе издание :

DO использовать ReadOnlyCollection<T>, подкласс ReadOnlyCollection<T> или в редких случаях IEnumerable<T> для свойств или возвращаемых значений, представляющих коллекции только для чтения.

Мы используем ReadOnlyCollections, чтобы выразить наше намерение возвратить коллекцию.

Методы List<T>, о которых вы говорите, были добавлены в .NET 2.0 для удобства. В C # 3.0 / .NET 3.5 вы можете вернуть все эти методы обратно на ReadOnlyCollection<T> (или любой IEnumerable<T>), используя методы расширения (и также используя операторы LINQ), поэтому я не думаю, что есть какая-либо мотивация для их добавления изначально для других типов. Тот факт, что они вообще есть в List, является лишь историческим примечанием из-за наличия методов расширения, доступных сейчас, но их не было в 2.0.

Answer 3

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

Answer 4

Я думаю, что ответ Джеффа вроде содержит ответ, который вам нужен; вместо ReadOnlyCollection<T> верните его подкласс ... тот, который вы реализуете сами, чтобы включить методы, которые вы хотели бы использовать без обновления до VS2008 / LINQ.