ПГ
Ну это и есть вариант если снаружи обработка истории.
Size: a a a
2021 May 05
ПГ
Агрегатов заказа много, сущность истории заказ - одна
VS
Всё нормально, только за словом Service могут скрываться куча абстракций, которые поленились именовать. И поэтому эти файлы получаются >1k строк
M
Ты можешь назвать EntityService, но оно и так в папке энтити лежит
VS
Лучше тогда EntityServicePhpFile.php
M
Есть таблица, которая мапится на ентити. Order, например. Логику в OrderService пишешь. Потом она у тебя растет, начинаешь еще на классы делить. Вот и все.
T🐜
как же srp?
M
Для этого и делишь )
T🐜
так может лучше сразу писать нормально. чтобы потом не делить?
VS
Так и делаем. Пишем всё в одном файле проснынёй. Когда доходит до 5к строк - делим на два и так далее.
M
Конечно лучше сразу, если знаешь как надо делить
M
5к многовато )
VS
Типа Order структурка с данными. OrderService - поведение?
AV
Добрый вечер. Хотелось бы задать вопросы по вчерашнему примеру, где были чемпионаты, в них были команды, а в них соответственно игроки. Задача - перевести игрока из одной команды в другую, причем трансферы доступны только(!) внутри чемпионата. Кто должен отвечать за проверку команды "не из чемпионата"
Где-то в игроке должен быть метод
function transfer(Team team)
Но разве в методе это будет логично делать?
Где-то в игроке должен быть метод
function transfer(Team team)
Но разве в методе это будет логично делать?
T🐜
оч просто делить. 1 объект 1 отвественность. И называть их соответствующе. А не обстрактным
OrderServiceM
Смотря что у тебя за ордер, может тебе и одного класса хватит
VS
Куда тулить новую фичу?
Я хз. Посмотри в OrderService на 1257 строке похожий метод. Посотри.
Так?
Я хз. Посмотри в OrderService на 1257 строке похожий метод. Посотри.
Так?
M
Поэтому и делишь на меньшие классы, OrderDeliveryService, и т.д.
VS
Хз. С таким подходом может наоборот удобнее структурки называть с префиксом. Типа UserData и убирать префикс Сервис.