Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, karbofos42, Вы писали:
K>>Тут же придётся переделывать контракт и менять клиентов, либо внутри метода возвращать не уже заполненный HashSet, а создавать новый List на его основе и уже его возвращать, т.е. лишняя работа.
Doc>Т.е. изначально выбрали не правильную абстракцию. Все дальнейшие проблемы как раз от этого.
Так вроде бы было, что "стоит возвращать самый точный интерфейс", а теперь оказывается, что есть неправильные абстракции
Здравствуйте, karbofos42, Вы писали:
K>Так вроде бы было, что "стоит возвращать самый точный интерфейс", а теперь оказывается, что есть неправильные абстракции
Я про изнечальное решение "создаётся локальный List<T>, в него заполняются все данные и он же возвращается." Или же я не так понял ваш пример.
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, karbofos42, Вы писали:
K>>Так вроде бы было, что "стоит возвращать самый точный интерфейс", а теперь оказывается, что есть неправильные абстракции
Doc>Я про изнечальное решение "создаётся локальный List<T>, в него заполняются все данные и он же возвращается." Или же я не так понял ваш пример.
Допустим, у нас есть объект со словарём. Есть метод типа:
public IReadOnlyCollection<Key> GetActiveItemsKeys()
{
return _dict
.Where(item => item.Value.IsActive)
.Select(item => item.Key)
.ToList();
}
либо без Linq создаётся лист и в него данные записываются по какому-то принципу.
Потом решили оптимизировать и завели ещё множество для хранения активных элементов, что теперь перебор не нужен и есть готовый HashSet со всеми нужными элементами.
Можно будет переделать на:
public IReadOnlyCollection<Key> GetActiveItemsKeys()
{
return _activeItemsKeys;
}
но тут конечно нельзя сказать, что поведение на 100% осталось прежним и нигде ничего не отвалится.
Контракт остался как был, но есть нюанс, что тоже не есть хорошо и нужно учитывать.
