55+ в ИТ

[Мальчик-Одуванчик]

getItems() же возвращает ссылку на коллекцию.

Тут я честно не понял. Разве getItems() не создает эту саму коллекцию, то есть новую структуру данных, отличающуюся от cart?

[valchkou]

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

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

[Мальчик-Одуванчик]

Code: Select all

	
	boolean isItemInCart(Item item) {
	    return cart.getItems().contains(item);
	}

Ну вот да, хотя бы как-то так. Даже полученное с сервера в виде массива сохранить во что-то отличное от массива/ArrayList почему-то большинству в голову не приходит

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

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

В общем случае не вижу ничего предосудительного.

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

[valchkou]

Code: Select all

	
	boolean isItemInCart(Item item) {
	    return cart.getItems().contains(item);
	}

Ну вот да, хотя бы как-то так. Даже полученное с сервера в виде массива сохранить во что-то отличное от массива/ArrayList почему-то большинству в голову не приходит

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

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

В общем случае не вижу ничего предосудительного.

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

мы видим задачу по разному, в данном примере я предположил что
cart.getItems() не создает никаких коллекций, а попросту возвращает референс на коллекцию спрятанную внутри объекта cart.
причем имплементация коллекции может быть как массивом так и hash based structure.
но нам по барабану потому как они все имплементируют метод contains().

с другой стороны такой подход не надежен, потому как можно подменить содержимое cart не используя никаких add or set методов.
или даже словить concurrent ex если допустить что один поток пишет а другой ищет

[Komissar]

народ, неужели сборщики мусора по-прежнему куются вручную?!

[Мальчик-Одуванчик]

мы видим задачу по разному, в данном примере я предположил что
cart.getItems() не создает никаких коллекций, а попросту возвращает референс на коллекцию спрятанную внутри объекта cart.
причем имплементация коллекции может быть как массивом так и hash based structure.
но нам по барабану потому как они все имплементируют метод contains().

Тогда предположим дальше что самописный метод getItem(i) не выкидывает исключений, что нельзя сказать про метод contains.

[Мальчик-Одуванчик]

народ, неужели сборщики мусора по-прежнему куются вручную?!

Да, так же как и аллокаторы для определенных типов данных. Не так давно на Хабре хороший пример на эту тему приводился.

[Komissar]

У мужика нормальный читаемый код, скорее всего для данной задачи можно обойтись перебором. Меня напрягло, чтотне взбрасывается exception, если в корзине обнаружен item which is null.

[brrdrr]

У мужика нормальный читаемый код, скорее всего для данной задачи можно обойтись перебором. Меня напрягло, чтотне взбрасывается exception, если в корзине обнаружен item which is null.

Откуда там null может появиться?
Стареет Комиссар. Комиссар уже не тот.
Пример с корзиной конечно некорректный, но смысл понятен, что плохо просто сканировать огромный массив.

[major Major Major Major]

У нас было бы примерно так

Code: Select all

private isItemInCart(item: Item): boolean  {
    return this.cart.Items.Any(cartItem => cartItem.Id === item.Id);
}

Items это LINQ обертка над Item[], внутре у нее неонка которая в генерируемом javascript дергает find, fiter и проч.
Проверку аргументов на null в private методах обычно не делаем

[АццкоМото]

ИЧСХ даже тривиальное решение типа "а зачем считать при необходимости, можно же счетчик менять, когда добавляем/удаляем" тоже мало кто даст

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

это верно. стало быть, нужно взвешивать риски, плюсы-минусы и все такое. ИМЕННО ЭТО есть то, за что платят инжинегру. а не за обход дерева

[АццкоМото]

getItems() же возвращает ссылку на коллекцию.

Тут я честно не понял. Разве getItems() не создает эту саму коллекцию, то есть новую структуру данных, отличающуюся от cart?

та ни, все как valchkou понял: Cart имеет кучу полей, одно из них - спейсок CartItems. getter просто возвращает ссылку на этот спейсок

[АццкоМото]

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

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

я бы сказал, что нетривиально будет все это делать с нуля и самому. но все колеса изобретены до нас и в буквально несколько строк это можно сделать с RxJava или другой подобной "реактивной" бляблятекой. но чтобы высрать эти несколько строк у Интерраптушки уйдет полчаса, у меня - день-два, а у некоторых не выйдет вовсе

[АццкоМото]

У нас было бы примерно так

Code: Select all

private isItemInCart(item: Item): boolean  {
    return this.cart.Items.Any(cartItem => cartItem.Id === item.Id);
}

Items это LINQ обертка над Item[], внутре у нее неонка которая в генерируемом javascript дергает find, fiter и проч.
Проверку аргументов на null в private методах обычно не делаем

Да, это ок, но по сути то же самое. Почему не рассмотреть HashSet<Item> или HashMap<Id, Item> ? Не всегда это лучшее решение, но очень часто

[АццкоМото]

У мужика нормальный читаемый код, скорее всего для данной задачи можно обойтись перебором. Меня напрягло, чтотне взбрасывается exception, если в корзине обнаружен item which is null.

Проблема в том, что вы примерно схожего возраста. Поэтому для вас это норм код. Для меня - нет, хоть я себя и чувствую стариком. Приемлемый 30-летний погромист просто блеванет