так и сделано

от оом это как то спасёт?

тогда new HashSet(keySet), map.clear

тоже самое ведь будет по-сути

ты можешь грузить и обрабатывать данные батчами?

скажем так - оно и так батчами в общем то

поменьше батч тогда?

но в пределах одного батча может такая хуета вылезти

нет

тогда new HashSet(keySet), map.clear

clear не подчищает массив бакетов (он только содержимое бакетов выпиливает)

ну крч - мораль такова

не трогай пока не падает

?

И красивее http://download.java.net/java/jdk9/docs/api/java/util/Map.html#of-K-V-K-V-K-V-K-V-K-V-K-V-K-V-K-V-K-V-K-V-

Круто. Они все таки утащили это из гуавы

И выглядит лучше

Посмотрел видео Егора Объектно-ориентированное вранье https://www.youtube.com/watch?v=lfdAwl3-X_c В целом всё по делу. Как сделать лучше : Вначале рассказать в чем ошибка такого дизайна (архитектуры) а затем уже обругать конкретные конструкции через которые это обычно реализуют (не по назначению их используют) Не хватает некого введения. Что идея ООП это - декомпозиция задачи на мелкие подзадачи(разделяй и властвуй) и ПОРУЧЕНИЕ объекту решать эту конкретную меленькую задачу а потом уже ругать get-теры и set-теры ... Неплохо бы упомянуть про "Чёрный ящик". Что мол объект что то там делает, реализация скрыта, можно не вникать, а просто используем через public методы, или даже лучше скрыть это за интерфейсом

ой, не тот чат)

Посмотрел видео Егора Объектно-ориентированное вранье https://www.youtube.com/watch?v=lfdAwl3-X_c В целом всё по делу. Как сделать лучше : Вначале рассказать в чем ошибка такого дизайна (архитектуры) а затем уже обругать конкретные конструкции через которые это обычно реализуют (не по назначению их используют) Не хватает некого введения. Что идея ООП это - декомпозиция задачи на мелкие подзадачи(разделяй и властвуй) и ПОРУЧЕНИЕ объекту решать эту конкретную меленькую задачу а потом уже ругать get-теры и set-теры ... Неплохо бы упомянуть про "Чёрный ящик". Что мол объект что то там делает, реализация скрыта, можно не вникать, а просто используем через public методы, или даже лучше скрыть это за интерфейсом

Понравился подход Егора?

Это не ноу хау, это очевидные правила дефакто.

Всё верно говорит

Насчёт выпуска и названия книжки (Elegant Objects). С маркетинговой точки зрения лучше выпустить - самоучитель по Java, но типа не как все, а мол учим Настоящеей объектно ориентированной Jave. Как бы улучшенная версия. Типа все учат не правильно, а у нас тру методика, научись сразу правильно. Например True Object Java или что то такое Целевая аудитория у такой информации как раз те кто только начинает изучать. Те кто уже неправильно научился и гавнокодит - книжки не читают, да и как её найти если она не самоучитель а просто некие советы...

Насчёт выпуска и названия книжки (Elegant Objects). С маркетинговой точки зрения лучше выпустить - самоучитель по Java, но типа не как все, а мол учим Настоящеей объектно ориентированной Jave. Как бы улучшенная версия. Типа все учат не правильно, а у нас тру методика, научись сразу правильно. Например True Object Java или что то такое Целевая аудитория у такой информации как раз те кто только начинает изучать. Те кто уже неправильно научился и гавнокодит - книжки не читают, да и как её найти если она не самоучитель а просто некие советы...

а потом True Object Ruby и True Object PHP?

Точно, клондайк ! )

а потом True Object Ruby и True Object PHP?

пхпшники и так по книжкам java учатся)

Точно, клондайк ! )

мыль на самом деле неплохая. у меня будет семинар на эту примерно тему в Киеве на след неделе.

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

Главное побольше примеров наглядных, т.е. вот как было, и чего мы лишаемся , и вот как стало и что мы обретаем

семинар будет онлайн транслироваться

Главное побольше примеров наглядных, т.е. вот как было, и чего мы лишаемся , и вот как стало и что мы обретаем

да, так и собираюсь. посмотрим, что из этого выйдет

семинар будет онлайн транслироваться

Это великолепно:)

Кстати насчёт True OOP... Есть мнение что модель акторов это как раз и есть та самая имплементация идеи ООП которую описывает Гради Буч. Акторы хорошо разделены и не могут вызывать методы друг друга а обмениваются сообщениями, плюс всё это асинхронно

я против этой идеи

Посмотрел видео Егора Объектно-ориентированное вранье https://www.youtube.com/watch?v=lfdAwl3-X_c В целом всё по делу. Как сделать лучше : Вначале рассказать в чем ошибка такого дизайна (архитектуры) а затем уже обругать конкретные конструкции через которые это обычно реализуют (не по назначению их используют) Не хватает некого введения. Что идея ООП это - декомпозиция задачи на мелкие подзадачи(разделяй и властвуй) и ПОРУЧЕНИЕ объекту решать эту конкретную меленькую задачу а потом уже ругать get-теры и set-теры ... Неплохо бы упомянуть про "Чёрный ящик". Что мол объект что то там делает, реализация скрыта, можно не вникать, а просто используем через public методы, или даже лучше скрыть это за интерфейсом

у меня было ощущение что я прослушал доклад про ддд и что анемичная модель это плохо

я против этой идеи

его не одобряет, все слышали?

вообще, должен признаться, что весь этот шум достаточно интересен вокруг ООП, весело смотреть как люди начали бурно реагировать, обсуждать что-то

его не одобряет, все слышали?

вот здесь подробно мои доводы: https://github.com/yegor256/eo/issues/45

по моему в РУнете джава сообщества ничего подобного давно не было, ну во всяком случае вот так массово и аж до истерии

по моему в РУнете джава сообщества ничего подобного давно не было, ну во всяком случае вот так массово и аж до истерии

значит есть что обсуждать, значит не зря все это)

у меня до сих пор в голове не укладывается. каким образом свойства обьекта преобразовать и отдать скажем как json клиенту? если в правильном ооп вообще не должно быть структур данных

это сущность сама себя должна конвертировать в json/xml?

это сущность сама себя должна конвертировать в json/xml?

Почему бы и нет:)

а как же SRP?

у меня до сих пор в голове не укладывается. каким образом свойства обьекта преобразовать и отдать скажем как json клиенту? если в правильном ооп вообще не должно быть структур данных

а как же принтеры)

entity.toDTO()

это сущность сама себя должна конвертировать в json/xml?

А всегда ли правильно == удобно?

entity.toDTO()

DTO - это структурки данных, что есть плохо в "правильном ООП"

Декоратор мб использовать?

вот здесь подробно мои доводы: https://github.com/yegor256/eo/issues/45

Я английский не достаточно хорошо знаю

Который бы обернул твой объект и извращался над ним

@yegor256 DTO,VO и вообще передача данных в чистом виде, ок это? или процедурщина?

SRP ничто, инкапсуляция все

Вот статья на Хабре интересная по теме https://habrahabr.ru/post/147927/

SRP ничто, инкапсуляция все

ну SOLID вообще мало применим по сути к сущностям если на то пошло

@yegor256 DTO,VO и вообще передача данных в чистом виде, ок это? или процедурщина?

это все зло

Егор, на самом деле вопрос не дает ли такое программирование оверхед (по той же памяти)?

Егор, на самом деле вопрос не дает ли такое программирование оверхед (по той же памяти)?

дает. в джаве и много где ещё

но память дешёвая, а программисты дорогие

поэтому важнее читаемость кода, а не его скорость

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

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

процедурки это зло

процедурки это зло

а можно где-то посмотреть пример реального приложения без всех этих зол и грехов ооп?

www.jare.io например

ERROR: S client not available

мы ж тут вроде как программисты, нам бы исходники посмотреть ?

www.jare.io например

https://github.com/yegor256/jare/blob/master/src/main/java/io/jare/smarts/SafeUser.java#L37

это ж POJO

это ж плохо

или POJO случайно попали в список зла?

не понял

а что такое POJO давайте тогда определимся

plain old java object, красивенькое имя, чтобы как-то по-модному брендировать простые java классы, которые не наследуют всякую инфраструктуру ала entitybean

так у меня только такие и есть)

похоронная табличка какая-то

да, меня уже исправляли на эту тему) я под POJO понимал объекты с сеттерами и геттерами только

DTO так сказать

понятно)

так что можно сказать, что в слайдах ошибка

https://github.com/yegor256/jare/blob/master/src/main/java/io/jare/tk/TkAdd.java#L59 new RqUser(req).name() new RqFormBase(req).param("name") это разве не геттеры только с другой вывеской?

щас начнется

не, не геттеры это

в чем разница между геттером и просто методом, возвращающим объект?

а что это?

геттер экспоузит наружу структуру

что такое "геттер"? дайте определение

в чём разница между геттером и вообще методом

геттер экспоузит наружу структуру

именно

именно

конкретно в примере с реквестами не могу понять, чего бояться того, что по хттп мы гоняем строки, которые трансформируем в глупые объекты? Или пропагандирование отказа лишь из-за злоупотребления?)

где один глупый объект, там и все через время

проблема в нашем мышлении

проблема в нашем мышлении

вотвот, так в чём же разница между getName и name? ?

это же просто привычка, не?