и проверять тип через instanceof

типа успешно или нет?

вместо !empty($result->getErrors())

типа успешно или нет?

да

но имхо тут это не надо

можно и так но оно все равно оказывается не лучше исключений)

вот в чем петрушка

как итог у тебя валидация контракта будет отдельно

в валидаторе

валидатор в идеале возвращает ок или не ок

или ошибки

размазывание сущности получается

ты можешь код в terminate заменить на валидатор

и спросить у валидатора валидно ли

если валидно вызывать приватный метод terminate

и возвращать валидатор

я все жду хорошего момента чтоб спросить к чему в итоге пришли ?

у которого будет метод $result->hasErrors

и $result->getErrors

@f3ath все же поясни, что ты имел ввиду

под логикой в результате

я все жду хорошего момента чтоб спросить к чему в итоге пришли ?

я пока решения не вижу)

есть несколько разных вариантов и они отличаются мелкими деталями реализации

но киллер-фичи для всех сценариев нет

сейчас накидаю вариант

вариант с валидатором мне не очень нравится именно из-за размазанности

то есть правила у меня отдельно, сущность отдельно

но правила - это ведь бизнес-логика

ну смотря какие правила

те, о которых говорим)

проверка связанных сущностей, статусов, полей и тд

совместимости всякие, короче

@f3ath все же поясни, что ты имел ввиду

я имел в виду условные операторы, которые говорять выполнить то или другое в зависимости от результата операции.

все равно до меня не доходит? можешь какой-то простой пример набросить?

не кодом

чисто логику

https://pastebin.com/axB5K9Lt

я не вижу того, как результат операции должен решать на основании своего (ведь так?) стейта, что делать дальше коду

вот еще вариант

только как минус

пришлось методы isStarted и unpaidInvoicesPresent сделать публичными

если выносим во внешний класс проверку

можно проверку оставить в этом классе и возвращать объект добавляя ошибки в массив

сделав метод добавления как в прошлый раз

но это уже было

ога

ну идеального решения нет

я бы брал скорей всего предпоследний

последний вроде и интересен

где методы у контракта скрыты и внутри код проверок

но если он станет сильно разрастаться по проверкам

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

их можно вынести во вне

и он не реюзабелен

да его реюзабельность = 0

мне тоже предпоследний вариант нравиться

но могут быть минусы если проверок слишком дофига

неудобно их каждый раз скролить эту лапшу

хотя можно refactoring in method применить

и не выносить в отдельный класс

опять же дело вкуса

да, сложно к чему-то придти

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

хотя это мое имхо

и возмно выкинуть исключение это более правильно и я ничего не смыслю

причем кстате TerminateResult можно реюзать и в других действиях))

он в себе хранит инфу есть ли ошибки и текста ошибок))))

?

все равно до меня не доходит? можешь какой-то простой пример набросить?

не могу выдумать хороший пример. я теперь сомневаюсь, может ли тут быть какая-то логика, которую можно зашить внутри объекта-результата

не могу выдумать хороший пример. я теперь сомневаюсь, может ли тут быть какая-то логика, которую можно зашить внутри объекта-результата

ну именно в этом случае нет наверно хотя хз

но вообще если объект на выходе не bool а другой объект возвращает

то вот тут надо его возвращать уже будет в случае успеха методом

но это совсем другая история

не могу выдумать хороший пример. я теперь сомневаюсь, может ли тут быть какая-то логика, которую можно зашить внутри объекта-результата

да пофиг на кейс я вообще не могу придумать такой случай, не только мой

ну у меня в голове крутились идеи, что например если надо какие-то еще действия совершать как единую транзакцию, их можно было бы как-то зашить в объект результата. ну типа result.notifyAdmins(emailSender)

но это такое

а почему их в объект результата

а не в методе где его возвращают делать ?

ну и я говорю, что это так себе пример

объект результа с продолжением действий у меня было на практики

когда задача завершается фоновая и грубо говоря у нас 3 ситуации

что-то типа result.finalize(some args)

успешно, фатально(не успешно), и надо отложить в конец очереди на время

но это слишком некокретно все

забейте, короче)

так вот в 3 этих ситуация в зависимости от задачи надо делать разные действия

я такой вопрос решил в объектах результатах

вынес результат в интерфейс и сделал разные объекты

ну во

вполне себе пример

я же говорю было в практики но тут чуть сложней

я не ябу какое действие я запускаю в целом

и что оно возвращает)

потому что фоновых тасков у нас довольно много

при этом например время ожидание можно в таске указать типо return new Waiting(60);

угу

где Waiting { public function __construct($sec) { sleep($sec); }} ?

если результат операции это конкретная штука из доменной области, есть шансы, что туда удобно будет какую-то логику еще засунуть