Удобство или «ленивое программирование» управления IList - защита IList. Добавление метода

Question

Как вы управляете этим простым сценарием, когда у вас есть объект со списком предметов. EG:

public class ContainerObject
{
    IList<ChildObject> Children { get; }

    public void AddCustom(ChildObject toAdd)
    {
        // Some validation ...
        Children.Add(toAdd);
    }
}

Предполагая, что коллекция инициализирована реализацией IList, есть ли способ контролировать способ добавления элементов в список?

Например, у меня есть другой метод в классе ContainerObject, который берет ChildObject и добавляет его в список. Этот метод необходим для выполнения некоторой базовой проверки ChildObject перед его добавлением.

Я ленив в том, что я не хочу возиться и писать собственный интерфейс списка (без метода добавления), который должны реализовать разработчики-потребители. Я также использую метод ToList () в интерфейсе IQueryable, так что это еще одна причина придерживаться IList - он просто работает.

Итак, существует ли подход, при котором вы можете контролировать, как элементы добавляются в экземпляр IList, то есть предотвращать использование метода Add и разрешать добавление в коллекцию только через мой пользовательский метод, или я просто спрашиваю о невозможном? ... и ленивый: (* ​​1010 *

Я могу подумать о нескольких хакерских способах проверки, когда элементы добавляются с помощью моего пользовательского метода или непосредственно в списке, но они кажутся хакерскими!

Кто-нибудь испытывает что-либо подобное этому? Если так, что ты сделал?

Answer 1

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

РЕДАКТИРОВАТЬ: Чтобы объяснить мой комментарий кэширования ...

Предположим, клиент сделал:

IList<ChildObject> originalChildren = container.Children;    
container.AddChild(new ChildObject());
IList<ChildObject> updatedChildren = container.Children;    

со свойством Children, реализованным так:

private IList<ChildObject> children = new List<ChildObject>();
public IList<ChildObject> Children
{
    get { return new ReadOnlyCollection<ChildObject>(children); }
}

Тогда originalChildren и updateChildren будут иметь одинаковое содержимое - возвращенный ReadOnlyCollection не будет снимком коллекции дочерних элементов в первой строке. Это была бы оболочка вокруг коллекции. Клиенты не смогут рассчитывать на то, что он не изменится - они просто не смогут изменить его сами.

Answer 2

Верните ReadOnlyCollection в мир, окружающий ваш список, которым вы управляете надстройками.