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

атрибут

потому что так привыкли

глядя на name() или param("name") мы тоже понимаем, что внутри объекта у нас есть :)

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

там где одно наследование, там дальше появляются большие и дурацкие иерархии ))

глядя на name() или param("name") мы тоже понимаем, что внутри объекта у нас есть :)

как это мы понимаем?

там где одно наследование, там дальше появляются большие и дурацкие иерархии ))

наследование зло: http://www.yegor256.com/2016/09/13/inheritance-is-procedural.html

наследование зло: http://www.yegor256.com/2016/09/13/inheritance-is-procedural.html

я не спорю

там где одно наследование, там дальше появляются большие и дурацкие иерархии ))

где несколько классов - там много классов? ?

где несколько классов - там много классов? ?

один, нескольк, много. Я про то, что иерархие должны расти горизонтально, а не вертикально

https://github.com/yegor256/takes/blob/master/src/main/java/org/takes/rq/form/RqFormSmart.java#L60

да я чисто на правах рофла это сказал)

один, нескольк, много. Я про то, что иерархие должны расти горизонтально, а не вертикально

я тоже за это: http://www.yegor256.com/2016/08/30/decomposition-of-responsibility.html

как это мы понимаем?

name vs getName vs param("name")

ну вот кстати param("name") говорит меньше всего

вообще какой то изврат :D

наследование зло: http://www.yegor256.com/2016/09/13/inheritance-is-procedural.html

Композиция лучше?)

1. Есть опредлённая строка. 2. Есть большой набор различных строк. Из этого набора нужно выбрать те строки, которые совпадают с опредлённой. Как это сделать без лишнего оверхеда? Хеш?

Композиция лучше?)

не просто лучше, а единственно возможный способ реюза кода

Композиция лучше?)

враппер

Композиция лучше?)

типа да

Чем ужасны геттеры? Как мы понимаем, что они экспозят структуру? Они просто отдают свойство объекта. "Свойство" как "характеристика". Считаете, у объекта не должно быть характеристик, только поведение? //Obj thinking еще не прочитал

Композиция лучше?)

поэтому в котлине все по-дефолту final

поддерживать возможность расширения класса это дикая боль

Чем ужасны геттеры? Как мы понимаем, что они экспозят структуру? Они просто отдают свойство объекта. "Свойство" как "характеристика". Считаете, у объекта не должно быть характеристик, только поведение? //Obj thinking еще не прочитал

https://pragprog.com/articles/tell-dont-ask

И композиция встроена в язык))

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

Продолжаем срыв покровов Из статьи: ООП = объектно-ориентированное программирование. Другими словами программирование которое основано на создании неких объектов. И кто-то решил что речь идет о классах. Но кто это решил? Когда? И почему?

Геттеры же копирование внутри должны иметь

Для мутабельного

в случае с ORM например Hibernate это не так

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

Продолжаем срыв покровов Из статьи: ООП = объектно-ориентированное программирование. Другими словами программирование которое основано на создании неких объектов. И кто-то решил что речь идет о классах. Но кто это решил? Когда? И почему?

классы это зло: http://www.yegor256.com/2016/09/20/oop-without-classes.html

Не, я про нормальные самописные геттеры))

Я придумал термин «объектно-ориентированный», и я уверяю вас, что не имел в виду C++ — Ален Кей 

Я придумал термин «объектно-ориентированный», и я уверяю вас, что не имел в виду C++ — Ален Кей 

а еще он думал про сообщения

а не про объекты)

Геттеры же копирование внутри должны иметь

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

где эта тонкая грань с геттерами? у меня есть обьект, у которого есть имя. я делаю getName - нарушается инкапсуляция, а если я делаю "introduce" или "sayMyName" - это уже не нарушение инкапсуляции?

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

проблем масса: http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html

...а чтобы было просто, надо писать иммутабельное. А это камень в джаву и поливашки в огород Котлина :)

а еще он думал про сообщения

Вот и я думаю про сообщения

где эта тонкая грань с геттерами? у меня есть обьект, у которого есть имя. я делаю getName - нарушается инкапсуляция, а если я делаю "introduce" или "sayMyName" - это уже не нарушение инкапсуляции?

грань тонкая, действительно. вот в двух словах я ее попытался прочертить: http://www.yegor256.com/2016/11/21/naked-data.html

ну как я поспамил?)

да мы поняли, что все ради этого :С

да мы поняли, что все ради этого :С

больше не буду)

да мы поняли, что все ради этого :С

а не ради поиска истины!

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

так а с сеттерами уже поборолись?

их вообще быть не должно

в идеале

в реалиях gc - ты будешь спамить объектами на каждый чих, пока что не реалистично же

грань тонкая, действительно. вот в двух словах я ее попытался прочертить: http://www.yegor256.com/2016/11/21/naked-data.html

toHashMap

тоже норм?

в реалиях gc - ты будешь спамить объектами на каждый чих, пока что не реалистично же

да, к сожалению

в реалиях gc - ты будешь спамить объектами на каждый чих, пока что не реалистично же

поэтому мы и юзаем dto и т.д.

Создатель ООП говорит Мне жаль, что давным давно я использовал термин «объект» для этой темы, потому что из-за этого многие люди фокусируются на меньшей из идей. Большая идея, которой не хватает современным статически-типизированным ОО-языкам: Большая идея это «сообщения». Ключ к созданию хороших масштабируемых систем это проработка механизмов общения модулей, а не проработка их внутренних свойств и поведения.

это одна из черт эволюции

сначало создать что-то

потом пытаться развалить)

поэтому меня удивляет почему akka не очень популярна среди джавистов

а spring наоборот

разве не популярна?

не так сильно популярна

Мужики нас обманули, это все нифига ни ООП то что нам подсунули)

@Enleur а что на тему save/update в репозитории?

ну как я поспамил?)

это ведь больше проблема дизайна апи если $order->getStatus() === Order::STATUS_FAILED - это плохо, то $order->isFailed довольно таки окей но с $orderItem->price() тут ничего не сделаешь

ERROR: S client not available

@Enleur а что на тему save/update в репозитории?

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

это ведь больше проблема дизайна апи если $order->getStatus() === Order::STATUS_FAILED - это плохо, то $order->isFailed довольно таки окей но с $orderItem->price() тут ничего не сделаешь

ээ, это жава чат s/$//g s/->/./g

ээ, это жава чат s/$//g s/->/./g

да тут от пхп пригорает да, ну смысл понятен ведь)

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

ну типа они простые dao?

да тут от пхп пригорает да, ну смысл понятен ведь)

даже у меня пригорает :/

Мужики нас обманули, это все нифига ни ООП то что нам подсунули)

переходим в ФП, там все более четко описано

или на го ?

или на го ?

назад к процедуркам!)

хотя почему же назад)

переходим в ФП, там все более четко описано

Фп это тоже не ооп, хочу true OOP!)

Фп это тоже не ооп, хочу true OOP!)

тебя опять обманули ))

Уже дважды) Требую настоящего ооп по заветам создателя!

проблем масса: http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html

не настолько больно, чтобы переходить на другой язык)

не настолько больно, чтобы переходить на другой язык)

а я и не предлагаю переходить

предлагаю писать обьектно

на чем угодно

Егор вскрыл мне мозг)

в мире настоящего oop super() можно использовать или это костыль?

тут вот скинули пример https://github.com/yegor256/jare/blob/master/src/main/java/io/jare/tk/TkAdd.java#L59 честно говоря, мне бы больше нравилось без этих вычурностей

тут вот скинули пример https://github.com/yegor256/jare/blob/master/src/main/java/io/jare/tk/TkAdd.java#L59 честно говоря, мне бы больше нравилось без этих вычурностей

сложно читается если по коду пошариться

тобишь правильное ООП это маленький имутабельный обьект?

такие вещи напрягают например) try { new SafeUser(this.base.user(new RqUser(req).name())).add(name);

тобишь правильное ООП это маленький имутабельный обьект?

в общем виде

тобишь правильное ООП это маленький имутабельный обьект?

иммутабельность это ж фишка фп ведь, успешно повзаимствованная

в мире настоящего oop super() можно использовать или это костыль?

делегирование по идее надо использовать

тобишь правильное ООП это маленький имутабельный обьект?

т.е. на правильном oop быструю субд не напишешь, например

в мире настоящего oop super() можно использовать или это костыль?

зачем тебе super, если ты не наследуешь?)

т.е. на правильном oop быструю субд не напишешь, например

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

иммутабельность это ж фишка фп ведь, успешно повзаимствованная

не то чтобы фишка, это необходимость для описания системы типов

не то чтобы фишка, это необходимость для описания системы типов

хотя вот не уверен в причине и следствии здесь)

есть вакансии джуниора в калининграде?

кто в курсе?