Скажем, у меня есть базовый интерфейс, подобный следующему:
public interface IObjectProvider
{
IEnumerable<IObject> GetObjects();
}
Источником объекта является некоторое резервное хранилище, которое может быть обновлено, и реализация этого интерфейса заботится об использовании этого резервного хранилища. Теперь я бы хотел, чтобы потребители этого интерфейса могли выполнять действия всякий раз, когда изменяется коллекция объектов, предоставляемых этим интерфейсом. Как бы вы реструктурировали этот интерфейс, чтобы обеспечить эту возможность? Мне бы хотелось, чтобы результат был применим ко многим интерфейсам «провайдера» в приложении для хорошей согласованности проекта.
Пример. Следующее обеспечивает эту функцию в сжатой и понятной форме, но добавляет значительную связь (включая ссылки на сборки WPF в коде до .NET 4.0). Должен ли я просто использовать это, поскольку мы знаем, что как только код переходит на .NET 4.0, он автоматически становится «легче»?
public interface IObjectProvider
{
ReadOnlyObservableCollection<IObject> Objects
{
get;
}
}
Редактировать 1:
Исходя из ответа Рида, я склоняюсь к тому, чтобы оставить интерфейс IObjectProvider без изменений по следующим причинам:
- Это новое приложение, поэтому проект может быть задокументирован на ранней стадии и согласован во всем.
- Объявите, что для всех поставщиков, если поставщик поддерживает уведомления об изменении предоставленной коллекции, значение, возвращаемое
GetObjects(), обязательно будет реализовывать INotifyCollectionChanged.
В связи с этим есть еще два случая, которые мне необходимо учесть в моем проекте:
- Предоставляемая коллекция никогда не меняется.
- Предоставленная коллекция может измениться, но клиенту потребуется опросить, если он хочет обновления. Могу ли я просто заявить, что этот случай не будет существовать в приложении (и это хорошая идея)?