Как стать автором
Обновить

Комментарии 10

Более того, нестандартный подход к типовым задачам, и не революционно-гениальный — принесет еще немало бед. Даже если «стандарт» очевидно не идеален.

По примеру в статье, о ленивости — итераторы, есть же итераторы!
Если говорить о работе с БД, такое ощущение что проще реализовать дубовый интерфейс на уровне DAO с двумя методами
List<String> getElements(String key, Integer limit, Integer offset);
int getElementsCount(String key);

чем корректно реализовать ленивый список с постепенной подгрузкой.

Например вы делаете ленивую подгрузку. Какой размер страницы подгрузки выбрать? Если размер страницы подгрузки меньше размера страницы просмотра — будет куча лишних запросов (подгружаете по 10, просматриваете по 100). Если наоборот — тащите лишние данные. Если размер подгрузки как-то передавать в вашу реализацию — потекла абстракция.
Передавать а конструкторе, как в java задается начальный зарезервированный объем, годится?
Задать этот параметр — проблем нет. Вопрос в том, что если клиент этой коллекции будет передавать размер подгрузки — будет протечка абстракции, а если не он — будет неэффективная реализация. Ведь в конце концов только клиент знает наперед сколько ему нужно будет данных
Не нвдо решать все проблемы сразу. метода «получить от сих и до сих» (вкупе с кол-вом всего) вполне достаточно
Далее можно делать различные реализации.
Опять же, итераторы и все такое.
Не будет никакой протечки.
Конструктор — он на то и конструктор, чтобы инициализировать. Никто ведь не парится, задавая initialCapacity ArrayList'у в конструкторе?
Автор подразумевает что клиент АПИ не знает о подгрузке результатов. Если он начнет передавать размер страницы — получается он знает о подгрузке — а это протечка абстракции.
Все так же, как в ArrayList'е. Большинству пользователей достаточно дефолтного значения размера сегмента. А уж если нужно затюнить — протечка абстракции является платой за прирост производительности.
10 — конечно, мало. От 1000 до 10000. Это достаточно много, чтобы пользователь воспринял за раз, но достаточно мало, чтобы получить за раз от большинства систем хранения данных и держать в памяти.
При проектировании ключевых интерфейсов в классической трёхзвенке нужно помнить, что их могут проксировать (через SOAP, например). Возросла нагрузка, переконфигурили в IoC-контейнере, чтобы по интерфейсу доставался не сервис, а его SOAP-прокси и что-то тяжёлое вынесли на клиент. Никакие lazy через прокси не пролезут, предложенное упрощение — фейл в архитектуре взаимодействия компонент.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории