Вернуть коллекцию как доступную только для чтения

Если ваши базовые данные хранятся в виде списка, вы можете использовать метод Список (T) .AsReadOnly. Если ваши данные можно перечислить, вы можете использовать метод Enumerable.ToList, чтобы привести вашу коллекцию в List и вызвать для нее AsReadOnly.

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

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

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

Я думаю, вы здесь путаете понятия.

ReadOnlyCollection предоставляет оболочку только для чтения для существующей коллекции, позволяя вам (класс A) передавать ссылку на коллекцию, зная, что вызывающий (класс B) не может изменить коллекцию (т.е. не может Добавить или удалять какие-либо элементы из коллекции.)

Нет абсолютно никаких гарантий безопасности потоков.

• Если вы (класс A) продолжите изменять базовую коллекцию после того, как передадите ее как ReadOnlyCollection, тогда класс B увидит эти изменения, сделает любые итераторы недействительными и т. д. И, как правило, будет открыт для любых обычных проблем параллелизма с коллекциями.
• Кроме того, если элементы в коллекции являются изменяемыми, оба вы (класс A) и вызывающий (класс B) сможете изменить любое изменяемое состояние объектов в коллекции.

Ваша реализация зависит от ваших потребностей: - Если вас не волнует, что вызывающий абонент (класс B) видит какие-либо дальнейшие изменения в коллекции, вы можете просто клонировать коллекцию, раздать ее и перестать заботиться. - Если вам определенно нужен вызывающий объект (класс B) для просмотра изменений, внесенных в коллекцию, и вы хотите, чтобы это было потокобезопасным, тогда у вас больше проблем. Одна из возможностей - реализовать собственный потокобезопасный вариант ReadOnlyCollection, чтобы разрешить заблокированный доступ, хотя это будет нетривиально и неэффективно, если вы хотите поддерживать IEnumerable, и Все еще не защитит вас от изменяемых элементов в коллекция.

Вместо этого вы можете использовать копию коллекции.

public IList<string> Data {
get {
    return new List<T>(data);
}}

Таким образом, не имеет значения, будет ли он обновлен.

Вы хотите использовать ключевое слово урожай. Вы просматриваете список IEnumerable и возвращаете результаты с помощью yeild. Это позволяет потребителю использовать для каждого без изменения коллекции.

Это выглядело бы примерно так:

List<string> _Data;
public IEnumerable<string> Data
{
  get
  {
    foreach(string item in _Data)
    {
      return yield item;
    }
  }
}

Я проголосовал за принятый вами ответ и согласен с ним. Могу я предложить вам кое-что для рассмотрения?

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

Основное преимущество этого заключается в том, что вы не можете добавлять код в коллекции, поэтому всякий раз, когда у вас есть собственная «коллекция» в вашей объектной модели, у вас ВСЕГДА есть не-объектно-ориентированный код поддержки, распространенный по всему проекту для доступа к ней.

Например, если ваша коллекция представляет собой счета-фактуры, у вас, вероятно, будет 3 или 4 места в вашем коде, где вы перебираете неоплаченные счета. У вас может быть метод getUnpaidInvoices. Однако настоящая сила проявляется, когда вы начинаете думать о таких методах, как «payUnpaidInvoices (плательщик, счет);».

Когда вы передаете коллекции вместо того, чтобы писать объектную модель, вам никогда не придут в голову целые классы рефакторинга.

Также обратите внимание, что это делает вашу проблему особенно приятной. Если вы не хотите, чтобы люди меняли коллекции, ваш контейнер не должен содержать мутаторов. Если позже вы решите, что только в одном случае вы действительно ДОЛЖНЫ его изменить, вы можете создать безопасный механизм для этого.

Как вы решаете эту проблему при передаче нативной коллекции?

Кроме того, собственные коллекции не могут быть дополнены дополнительными данными. Вы узнаете это в следующий раз, когда обнаружите, что передаете (Collection, Extra) более чем одному или двум методам. Он указывает, что «Extra» принадлежит объекту, содержащему вашу коллекцию.