ну да

поэтому и 31

За хешкоды и иквалсы это к Михальче https://vladmihalcea.com/2016/10/20/the-best-way-to-implement-equals-hashcode-and-tostring-with-jpa-and-hibernate/ , например

Откуда геттеры?

В смысле? Я еще понимаю отсутсвие сеттеров, чтобы объект был имутабельным. Но без гетеров, как с объектом то работать?

В смысле? Я еще понимаю отсутсвие сеттеров, чтобы объект был имутабельным. Но без гетеров, как с объектом то работать?

геттеры не нужны это не труъ ооп

геттеры не нужны это не труъ ооп

иди набрсывай в свой двор

злой ты

геттеры не нужны это не труъ ооп

Ок, не нужны. Как тогда с объектом взаимодествовать?

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

Ок, не нужны. Как тогда с объектом взаимодествовать?

public

все паблик, все

Ох ты ж, блин. Тогда JS получится.

а какая разница между гетером и пабликом?

зато труъ

а какая разница между гетером и пабликом?

принципиальная.

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

а на деле никакой ты и так и так свою инкапсуляцию ломаешь

Наверно не понимают они чего-то

не для геттеров уж точно

а на деле никакой ты и так и так свою инкапсуляцию ломаешь

инкапсуляция != сокрытие

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

Моральная полиция

инкапсуляция != сокрытие

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

В смысле? Я еще понимаю отсутсвие сеттеров, чтобы объект был имутабельным. Но без гетеров, как с объектом то работать?

Объект сам должен всё делать.

если не нравится бойлерплэйт есть лобок

*ломбок

крутая штука

По фрейду оговорка?

если не нравится бойлерплэйт есть лобок

Если не нравится бордерплейт, то есть kotlin)

Если не нравится бордерплейт, то есть kotlin)

ну это прям совсем радикальный вариант

ну да объект должен сам все делал ) не всегда

дверь сама себя не открывает )

ну да объект должен сам все делал ) не всегда

Когда нет?

когда закрыта

дверь сама себя не открывает )

Ты мало дверей видел просто)

Или в 18 веке живёшь)

ну это прям совсем радикальный вариант

Радикально - это c#)

Ты мало дверей видел просто)

Если так подходить к вопросу, то может быть )

Радикально - это c#)

го сишарп срач

Если так подходить к вопросу, то может быть )

Блин, дверь сама себя открывает. Не видел никогда таких?)

Объект сам должен всё делать.

+ Ну, то есть если уж тебе нужны DTO, то и хрен с ним, пользуйся гетерами, сетерами. Но в бизнес логике это признак текущей абстракции

передай человеку дверь и он ее откроет, уф

не вещь в себе пишешь

Блин, дверь сама себя открывает. Не видел никогда таких?)

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

передай человеку дверь и он ее откроет, уф

Передай человеку дверь, и он даст команду двери открыться.

Передай человеку дверь, и он даст команду двери открыться.

да

разумные люди тут, чего

да

А не откроет сам дверь.

Радикально - это c#)

не нужно, тут все натуралы

А не откроет сам дверь.

ну, да, он не будет делать door.setOpen(true), он сделает door.open() я об этом и говорю, дверь сама себя не открывает, ей не нужно, но команду на открытие выполнять умеет

ну тут с оговоркой ) что дверь все равно себя не открывает даже по команде )

ну мы сейчас про простую дверь из дерева )

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

Смотря что считать дверью, если дверь это кусок доски, который преграждает проход, то да дверь ничего не умеет.

Если есть датчик, который дает команду двери открыться, то можно сказать что дверь сама все умеет )

ну, да, он не будет делать door.setOpen(true), он сделает door.open() я об этом и говорю, дверь сама себя не открывает, ей не нужно, но команду на открытие выполнять умеет

Блин, ну так если судить, то ничего само не делает) Нужно отдавать команду)

А если дверь это доска на петлях в дверной коробке. То уже другое дело.

Там есть функция опен\клоз

Блин, ну так если судить, то ничего само не делает) Нужно отдавать команду)

Не команду, а слать мессадж)

Не команду, а слать мессадж)

Это уже детали реализации)

просто можно по-разному интерпретировать

И вообще все это херово делать параллели в ООП из реальной жизни.

Коллеги, мЫслите ширше: нет задачи открывать/закрывать дверь, есть задача попадать из одного помещения в другое, сл-но, нужна более высокоуровневая абстракция, а дверь — это узкий частный случай!

Дверь может быть и телепортом

И черной дырой

И вообще гиперпространственным туннелем

Или синей телефонной будкой :)

Понятно, я пошёл погуляю. Пока всем!)

ERROR: S client not available

Класс это подпрограмма, просто функция. И чтобы не копипастить, когда надо изменить где-то реализацию. То и придумали все это наследование, инкапсуляцию и полиморфизм. Чтобы можно было взять вон ту функцию, и адаптировать ее под нужные условия, минимальным изменением.

Блин, ну так если судить, то ничего само не делает) Нужно отдавать команду)

А разве не так?

А все эти абстрации про дверь нужны в ГейДеве чтоб движки пилить.

А разве не так?

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

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

>Просто лучше всего проектировать классы так на чем твоё утверждение построено?

с чего ты это взял?

>Просто лучше всего проектировать классы так на чем твоё утверждение построено?

На опыте. С ними проще работать. Чем меньше область, где ты можешь что-то сломать, тем лучше.

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

На опыте. С ними проще работать. Чем меньше область, где ты можешь что-то сломать, тем лучше.

какой опыт?

какой опыт?

Эм... Жизненный.

и много у тебя его? и проектов? поделишься?

именно в джава бэкенд проектах

и много у тебя его? и проектов? поделишься?

Ну, хз. Я бы не сказал, что много. Но мнение такое сформировалось.

вопрос, как мне тестировать классы такие?

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

как бороться с большим кол-вом кода, которое неприменно там образуется?

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

А в чём проблема? Приведи пример класса, который сложно протестировать. Ну или поставь задачу.

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

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

вперед епт

тестируй

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

А кто тебе сказал, что это всё должно быть одним объектом?

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

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

так класс внутри состоит из других классов, бери и тестируй их отдельно кто мешает?

если хочешь внешний класс тестировать у тебя есть вход/выход тестируй

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

Чувак, это не значит, что у тебя должен быть один класс.

Берёшь и строишь матрёшку и всё у тебя замечательно.

т.е. все на внутренних классах?

т.е. все на внутренних классах?

Да.

тогда будет каша

тогда будет каша

Почему?