C
Size: a a a
2021 April 17
SP
окей, то есть тут не будет сеттеров
SP
потому что сеттеры не работают для этой ситуации
SP
еще один пример типичного сеттера который сразу говорит о проблемах -
setStatus. Есть ли место для таких вещей в коде?SP
ну то есть в этом случае разницы между сеттером и публичным полем нет. Так же как в ситуации когда люди лепят сеттеры на кейс где обновляются несколько полей. Или есть скажем 3-4 разные операции когда меняется разный набор данных.
Удобно ж хернуть пачку сеттеров и пусть клиентский код сам решает что он хочет обновлять а что нет. А мы потом просто обмажимся доктрин листенерами что бы updated at проставлять
Удобно ж хернуть пачку сеттеров и пусть клиентский код сам решает что он хочет обновлять а что нет. А мы потом просто обмажимся доктрин листенерами что бы updated at проставлять
SP
я к тому что "логично что сеттер дает больше контроля" и это типичная защита людей которым нравится такой подход. Но коль ты уж решил менять стэйт снаружи то какая разница.
SP
class Profile
{
public function __construct(
public string $name,
public string $dob,
public string $gender
) {}
}
$profile = new Profile(
name: $name,
dob: $dob,
gender: $gender
);
$user->updateProfile($profile);
Вжух
SP
там в целом оч много подводных камней а потому мне оч не нравится это обобщение что сеттеры лучше чего-то. Сеттеры как концепт "засунуть стэйт в объект" в целом плохая идея, и проблема не в способе - проблема в самой идее "засунуть стэйт".
SP
я хз почему возможность сделать доп валидацию какую наивную приписывается в плюсы...
SP
вот еще пример интересный)