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

Каждый раз лезть в сущности и писать частные методы?

Которые этой сущности сами по себе не нужны

Ну тут скорее ещё вопрос что дальше делается и что это за сущность. Может это вообще структура без логики.

Может надо вынести эту логику в отдельный матчер?

Просто, чтобы "не лезть в 100 мест менять"

Я бы сказал так наверное : если у нас сущность реально анемичная (просто хранитель данных, crud ) - нет смысла какие то матчи в неё пихать. Но как выше Шурик привёл пример - что у нас в 100 местах проверяется что usa - это уже явно бизнесовая какая то штука серьезная - и её можно/нужно инкапсулировать в IsUsa() .  Зависит от задачи. Имхо конечно.

Докину ещё немного. Это наверное как раз то, что говорил Шурик, чето только допер. Вряд-ли есть бизнес требование "принадлежность к городу". Скорее всего есть в бизнесе "возможность выполнения какого то действия". И нужно проверять именно его. 1)потому что у нас будет именованное название проверки по бизнесу. 2) если у нас используется в 100 местах мы изменим только 1 место. Т. Е. в этом случае методы isUsa, ismatch тоже не подходят

Всем привет🖐

Жость

Вот это вас перекрыло

Мутабельные дто

Мож тогда сразу на массивы перелазить? Классы тоже же зло

isUsa выглядит как так себе решение. По геттеру на каждую страну?
Отдельный матчер выглядит как норм решение

Короч, повторюсь: фишка в комплексном подходе. Взять отдельную фичу и попытаться имплементировать без остального не выйдет.

Перечитайте снова.
"Если у вас есть гетеры и сетеры, значит доступ к полям полностью публичный, и в таком случае вообще не имеет смысл делать их приватными и прятать за гетерами сетерами"

если у меня в поле массив с опциями?  Которые во время исполнения могут меняться.
Например здесь:
https://github.com/symfony/zulip-notifier/blob/5.x/ZulipOptions.php
Можно сделать getOption getOptions вместо toArray и сетери соответственно.
Поскольку у меня есть private message и stream а также канал
https://zulip.com/api/send-message
...

Вообще с этим косяк может быть если конкурентный доступ. Вот вы достали что это USA и милисекундой позже другой человек поменял это на Россию.
Но вы в своем коде спокойно принимаете решение на основе неверных данных о том что это США. Тем самым создавая ошибку. В этом и опасность отдавать стейт наружу.
Особенно хорошо такие проблемы вылазят когда к проекту реплики подключают. Или ресурс действительно высококонкурентный становится.

Основное правило как только вы достали данные вы должны понимать что всё, они уже устарели и больше им доверять нельзя.

Можно конечно лочить все места откуда читается. Но с таким подходом вы или всю базу залочите или в дедлоки свалитесь

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

Вообще вы смотрите на программу и решения с точки зрения программы.
А вы смотрите с точки зрения команды которая её пишет и кодстандартов.