55+ в ИТ

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

Code: Select all

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

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

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

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

[АццкоМото]

cart.getItems() - переливаем из пустого в порожнее?
Сборщик мусора все стерпит.

а в чем проблема-то?

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

Не знаю, о чем речь. Во первых, корзина может содержать много чего, кроме спейска товаров. Ну, допустим, айди магазина. Во-вторых, не понятно при чем тут сборщик мусора. getItems() же возвращает ссылку на коллекцию. Никакие новые абекты не создаются (ну, если, конечно, реализовывал не идиот)

[АццкоМото]

Code: Select all

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

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

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

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

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

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

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

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

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

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-летний погромист просто блеванет

[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 методах обычно не делаем

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

Все зависит от задачи. Если мы про shopping cart то количество предметов в ней не будет того порядка когда разница между hashmap будет существенна и оправданна. Плюс кто сказал что надо будет всегда искать по id? А по категории товара, по количеству, по стоимости?
Я не против быстрого кода, у меня задачи часто такие что без оптимизации просто никуда, но оптимизировать и усложнять там где можно обойтись чем то простым и надежным считаю напрасной тратой времени. То есть если бы речь шла о методе isItemInOrderHistory() то бяда пичалька, а так не особо.
Если не считать что твой старпер не верит в электречество и array.find() не использует, не говоря уже про LINQ. Code review у меня бы по этому не прошел. Читабельность страдает

[АццкоМото]

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

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> ? Не всегда это лучшее решение, но очень часто

Все зависит от задачи. Если мы про shopping cart то количество предметов в ней не будет того порядка когда разница между hashmap будет существенна и оправданна. Плюс кто сказал что надо будет всегда искать по id? А по категории товара, по количеству, по стоимости?
Я не против быстрого кода, у меня задачи часто такие что без оптимизации просто никуда, но оптимизировать и усложнять там где можно обойтись чем то простым и надежным считаю напрасной тратой времени. То есть если бы речь шла о методе isItemInOrderHistory() то бяда пичалька, а так не особо.
Если не считать что твой старпер не верит в электречество и array.find() не использует, не говоря уже про LINQ. Code review у меня бы по этому не прошел. Читабельность страдает

Я там выше в цитате два ключевых момента выделил. Да, не всегда ХэшМап/Таблица это лучшее решение. Но а) их нужно рассмотреть как вариант бэ) даже перебор нужно делать элегантнее

[valchkou]

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

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

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

если мы говорим про агрегацию 100500 миллионов, то одной блятекой тут не обойтись даже интерапту, не зря же наворотили разных хадупов, спарков и следом распределенных in-memory DB.
сначала нужно все это барахло найти поставить настроить и только потом можно будет немного расслабившись налить чайку и написать несколько строчек работающего кода.

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

Если не считать что твой старпер не верит в электречество и array.find() не использует, не говоря уже про LINQ. Code review у меня бы по этому не прошел. Читабельность страдает

Ну тогда по идее самое оно параметризовать тип контейнера в реализации и специализировать функцию поиска, если она отличается от тривиального find()

[Komissar]

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

Откуда там null может появиться?

От бага в другом модуле.

[Zachet]

[map][/map]

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

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

На самом деле 30-летний погромист учился кодить на питоне, поэтому он выдаст чтото вроде

Code: Select all

 
 
 def isInCart(item, cart):
   return len(filter(lambda x: x.getId() == item.getId(), cart.getItems())) > 0
 
 

Что под капотом тот же обход листа