ну скорее код результата, потому что это предусмотренный случай

Я так и не понял, чем плох вариант с \Exception и методом toString()

вот именно

случай предусмотренный

имхо тут никаких исключений не должно быть

мы знаем, что такое возможно

нормальый флоу

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

нормальый флоу

Ну это если у человека есть метод который проверяет: можно закрыть контракт или нет То здесь как бы bool вполне себе логичен А если у него все в одной куче?

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

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

а что мне мешает пихнуть проверку в метод в контракте?)

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

Ну это если у человека есть метод который проверяет: можно закрыть контракт или нет То здесь как бы bool вполне себе логичен А если у него все в одной куче?

ну если есть метод - тогда нахрен мне не сдалась проверка в методе

в $contract->close(); исключение

ну если есть метод - тогда нахрен мне не сдалась проверка в методе

?

Ну это если у человека есть метод который проверяет: можно закрыть контракт или нет То здесь как бы bool вполне себе логичен А если у него все в одной куче?

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

я ведь тогда могу проверить извне

дернуть метод-проверку

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

Задача метода дать ответ "можно закрыть N контракт или нет"

и в зависимости от ответа дернуть закрытие или не дернуть

Вроде бы bool не плох

if (!$contract->isHaveOpenInvoices()) $contract->close();

могу его же дернуть и изнутри но это слегка изврат

можно и так

Задача метода дать ответ "можно закрыть N контракт или нет"

а, типа canClose(): bool? ну тут да

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

это исключение

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

до закрытия

но вообще тогда проверка вытекает из сущности

но можно и public function terminateContract() : bool { if ($this->unpaidInvoicesPresent()) { return false; } $this->terminate(); return true }

допустим так (буль фигня, но писать больше неудобно)

можно и так

но terminate может выкинуть исключение в теории

внутренний?

да

но terminate может выкинуть исключение в теории

Какое?

окей, давай переделаю

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

так не надо его оборачивать ни во что

твой вариант имхо правильный

public function terminateContract() : bool { if ($this->unpaidInvoicesPresent()) { return false; } $this->status = 'terminated'; return true }

злой гуанокод, но пофиг

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

и без проверки я не закрою контракт

потому мне и не нравится вариант с hasUnpaidInvoices - так все равно можно выстрелить себе в ногу

я сейчас вообще прихожу к плавному написанию домена в запрещающем стиле

я бы вот так делал

https://pastebin.com/r0JUAFsx

а что изменится?)

тем более

если вызов terminate будет происходить только из terminateContract

тем более нейминг (незачем повторять Contract с учетом того, что это у нас уже в имени класса присутствует)

https://pastebin.com/18en9sLK

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

который бы отменял контракт

потомучто мне кажется потом еще правила добавятся

и заказчик захочет знать почему именно он не отменен

преждевременная оптимизация) "почему именно" - да, можно завернуть, конечно но 1. сделать это позже несложно 2. разные классы исключений/возвращаемых результатов, как коняш предлагал и соответственно можно уже на основании них проверять все

а так мы все равно с bool далеко не уедем

у тебя несколько проверок могут быть

например не начал ли контракт действия

или не закончил ли он действия

помимо неоплаченных счетов

могут но опять-таки - мы упираемся в возврат bool

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

возвращай объект "результат операции" постарайся всю условную логику инкапсулировать в нем

https://pastebin.com/Hy6ebHZh

я бы вот так мб делал

лапша только в одном месте

но она легко на валидатор меняется

и потом из валидатора ошибки забирть

фронтв первую очередь не должен показывать кнопку, а во вторую - должен быть готов к ситуации "не получилось закрыть" потому что у тебя распределенная система и race conditions неизбежны

да я писал про фронт

пока не говорим о фронте

я вот чисто со стороны бэкенда написал

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

мб наследовался бы от RuntimeException

если хочешь можешь убрать наследование от исключения и возвращать $errors

ну вот тут мы пришли к возврату объекта результата

и проверять наличие ошибок через $error->getErrors(); и в зависимости от возврата делать реакцию

возвращай объект "результат операции" постарайся всю условную логику инкапсулировать в нем

что ты имеешь ввиду под условной логикой "результата"?

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

что ты имеешь ввиду под условной логикой "результата"?

логику ттипа if (wasClosed) {...} else {...}

ну так это ведь собственно проверка того, как завершится операция

если "результат" - это нечто вроде DTO - тогда не особо складывается

ну так это ведь собственно проверка того, как завершится операция

ну смысл в том, что проверка должна быть только в одном месте, вот и пусть она будет внутри этого объекта

но ведь она относится к логике самого объекта/доменной модели

вот вариант с возвратом результата

https://pastebin.com/DQhzHuZ5

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

ну тут проверка в процессе чекаута будет. Если после чекаута, то ты его изъять уже не сможешь, но сможешь сделать возврат (за свой счёт уже правда)

и обработкой

тут результат - это контейнер

в таком виде я еще понимаю логику

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

ну там можно и массив вернуть пустой))

?

и использовать его в качестве контейнера с ошибками)

но это слишком магически