Нормальна ли ситуация, когда в API и на фронте дублируется одна и та же логика? К примеру, если нужно что-то обрабатывать, условно, "реалтайм".

Был бы API на JS, можно было бы этого избежать...

Нормальна ли ситуация, когда в API и на фронте дублируется одна и та же логика? К примеру, если нужно что-то обрабатывать, условно, "реалтайм".

Был бы API на JS, можно было бы этого избежать...

Однажды я услышал, что геттеры — это плохо.

И прошел все этапы реакции по Кюблер-Росс: отрицание, злость, торг, депрессию, принятие 😂
Надеюсь, этот пост поможет пропустить несколько стадий.

DTO. Если тело геттера return $this->privateProperty, заменяем его публичным свойством с аннотацией @psalm-readonly-allow-private-mutation или @psalm-readonly или объявляем весь класс @psalm-immutable. Так мы обеспечиваем инкапсуляцию да ещё и нанооптимизируем код (-N вызовов геттеров). Метод без каких-либо манипуляций не имеет смысла — это 4 строки визуального долга и 1 строка для покрытия тестами.

Кстати, я тут заметил, что геттер — это трюк. К существительному добавили глагол, чтобы удовлетворить фомуле subject.actionVerb(?object). Вот только get — это не предоставить, а получить. То есть мы не просим объект поделиться состоянием, мы его отбираем.

Value Object. Если метод представляет собой query по CQS и возвращает некоторое представление (проекцию) объекта, то его название не должно быть шаблонным, оно должно отражать семантику. Например, Birthday::format(string $format): string, Color::toHex(): string.

Entity. Стараемся применять принцип Tell-Don't-Ask. Попробую сформулировать по-своему. Объект — это состояние + поведение. Если мы программируем объектно-ориентированно, мы должны просить объект совершить действие над принадлежащим ему состоянием, а не отбирать у него состояние и выполнять действие за пределами этого объекта. Если программируем не объектно-ориентированно (что тоже ок), то объекты по определению не используем и геттеры, соответственно, тоже.

---

Итак, в DTO вместо геттеров используем публичные свойства. В Value Object — семантические query методы, и то, если не добавлять "на всякий случай", их будет немного. В моделях оставляем только command методы.

Как тогда вывести состояние модели? Рассудим логически. Для вывода состояния поведение не нужно, нужно только состояние. Значит и сама модель для этой задачи не нужна. Где хранится состояние модели? В хранилище. Вот из него напрямую и запросим. Утрированный GET API контроллер: echo json_encode($pdo->query('select x1, x2 from y where z = ?')->fetch()).

Псалм тебе ничего не обеспечивает.

Однажды я услышал, что геттеры — это плохо.

И прошел все этапы реакции по Кюблер-Росс: отрицание, злость, торг, депрессию, принятие 😂
Надеюсь, этот пост поможет пропустить несколько стадий.

DTO. Если тело геттера return $this->privateProperty, заменяем его публичным свойством с аннотацией @psalm-readonly-allow-private-mutation или @psalm-readonly или объявляем весь класс @psalm-immutable. Так мы обеспечиваем инкапсуляцию да ещё и нанооптимизируем код (-N вызовов геттеров). Метод без каких-либо манипуляций не имеет смысла — это 4 строки визуального долга и 1 строка для покрытия тестами.

Кстати, я тут заметил, что геттер — это трюк. К существительному добавили глагол, чтобы удовлетворить фомуле subject.actionVerb(?object). Вот только get — это не предоставить, а получить. То есть мы не просим объект поделиться состоянием, мы его отбираем.

Value Object. Если метод представляет собой query по CQS и возвращает некоторое представление (проекцию) объекта, то его название не должно быть шаблонным, оно должно отражать семантику. Например, Birthday::format(string $format): string, Color::toHex(): string.

Entity. Стараемся применять принцип Tell-Don't-Ask. Попробую сформулировать по-своему. Объект — это состояние + поведение. Если мы программируем объектно-ориентированно, мы должны просить объект совершить действие над принадлежащим ему состоянием, а не отбирать у него состояние и выполнять действие за пределами этого объекта. Если программируем не объектно-ориентированно (что тоже ок), то объекты по определению не используем и геттеры, соответственно, тоже.

---

Итак, в DTO вместо геттеров используем публичные свойства. В Value Object — семантические query методы, и то, если не добавлять "на всякий случай", их будет немного. В моделях оставляем только command методы.

Как тогда вывести состояние модели? Рассудим логически. Для вывода состояния поведение не нужно, нужно только состояние. Значит и сама модель для этой задачи не нужна. Где хранится состояние модели? В хранилище. Вот из него напрямую и запросим. Утрированный GET API контроллер: echo json_encode($pdo->query('select x1, x2 from y where z = ?')->fetch()).

странный вопрос
конечно да

Хочу заметить, что interface, trait и class в php является одним и тем же типом внутри языка (кроме одного единственного флага)