S
А такие методы - общепринятая практика?
Нет, это против ООП.
Size: a a a
2020 March 16
M
А, понял
M
Благодарю
ch
А такие методы - общепринятая практика?
ИМХО, dto можно и без них, а вот для остального все не так очевидно
M
ИМХО, dto можно и без них, а вот для остального все не так очевидно
Понял-принял
DK
"Гет/сет" вообще плохая идея почти всегда.
А какая хорошая?
S
Dmitry Kalinichenko
А какая хорошая?
Хорошая - интерфейс класса должен отражать его поведение.
Геттер/сеттер подходят для тех классов, у которых всё поведение - "хранить вот эти данные".
Геттер/сеттер подходят для тех классов, у которых всё поведение - "хранить вот эти данные".
DK
ты имеешь ввиду о pojo классах ? не вижу логики между "отражать его поведение" и способом установки переменных класса.
S
Dmitry Kalinichenko
ты имеешь ввиду о pojo классах ? не вижу логики между "отражать его поведение" и способом установки переменных класса.
Согласно ООП установка начального состояния объекта делается через конструктор(ы), изменение состояния объекта - через интерфейс, отражающий поведение объекта.
Геттеры/сеттеры не выражают никакого поведения, они лишь говорят "дай мне поле класса"/"установи поле класса".
Геттеры/сеттеры не выражают никакого поведения, они лишь говорят "дай мне поле класса"/"установи поле класса".
S
Можно жить и с этим, но это как бы не ООП.
S
Геттеры-сеттеры могут быть оправданы, например, специфическими компромиссами фреймворка - beans, например - но из-за этого добавлять их вообще во все классы не то что бесполезно, но скорее даже вредно.
DK
Согласно ООП установка начального состояния объекта делается через конструктор(ы), изменение состояния объекта - через интерфейс, отражающий поведение объекта.
Геттеры/сеттеры не выражают никакого поведения, они лишь говорят "дай мне поле класса"/"установи поле класса".
Геттеры/сеттеры не выражают никакого поведения, они лишь говорят "дай мне поле класса"/"установи поле класса".
приведи пример "изменение состояния объекта - через интерфейс, отражающий поведение объекта"
DK
как ты будешь влиять на состояние объекта со приватным состоянием не через методы данного объекта, или все public делаем ?
S
Dmitry Kalinichenko
как ты будешь влиять на состояние объекта со приватным состоянием не через методы данного объекта, или все public делаем ?
Всё через методы, конечно.
Другой вопрос - что именно эти методы делают, и какой смысл в них заложен.
Другой вопрос - что именно эти методы делают, и какой смысл в них заложен.
S
class Cat{
float energy;
float hunger;
}
Вот например мы моделируем поведение кота, которого есть "уровень энергии" и "уровень голода".
float energy;
float hunger;
}
Вот например мы моделируем поведение кота, которого есть "уровень энергии" и "уровень голода".
S
В варианте "с геттерами и сеттерами" наш код примерно так выглядит:
class Cat{
float energy;
float hunger;
void setHunger(float h) {hunger - h};
float getHunger() {return hunger;}
void setEnergy(float e){energy =e}
float getEnergy(){return energy;}
}
class Cat{
float energy;
float hunger;
void setHunger(float h) {hunger - h};
float getHunger() {return hunger;}
void setEnergy(float e){energy =e}
float getEnergy(){return energy;}
}
S
Можно установить и прочесть поля объекта, и всё как будто работает.
S
Однако если у нашего кота чуть более сложные "правила", чем "хранить две цифры", то геттеры/сеттеры становятся бесполезны и даже вредны.
S
Например, мы знаем, что кот вообще-то умеет спать, и за час сна набирает 7 единиц энергии.
А ещё каждый час его голод увеличивается на 13 единиц.
И в целом мы держим кота для того, чтобы с ним играть, и он при этом генерирует 1 единицу радости за час игры. Но только если энергия кота выше нуля, и голод меньше 100.
А ещё каждый час его голод увеличивается на 13 единиц.
И в целом мы держим кота для того, чтобы с ним играть, и он при этом генерирует 1 единицу радости за час игры. Но только если энергия кота выше нуля, и голод меньше 100.
l
поясни пожалуйста, когда гет/сет вредны?