Alex P., верно, искал не совсем то, мы работаем по DDD с БМПО, и геттеры-сеттеры не наш стиль :-) А так-то да, у нас именно что будут объекты, не связанные с БД сервиса, где они существуют, и мы будем заполнять их через рефлексию с сериализацией или типа того.
Конструктор плох тем, что может содержать какую-то внутреннюю логику, которая будет скрыта и с одной стороны может вносить какие-то неожиданные изменения, а с другой стороны должна дублироваться в случае использования сущностей в различных сервисах (проектах).
То есть, задача такая: есть некий (микро)сервис, который выступает в роли хранилища неких сущностей, документов, например. Он их должен создавать, он их должен отдавать на чтение, и тд. При этом другие сервисы тоже хотят работать с этой сущностью, но выступая в роли ее потребителя или инициатора создания, в части случаев. Из этого вытекает, что мы должны нарушать принцип DRY, если я верно его понимаю - тот же конструктор у нас должен с его логикой дублироваться на стороне обоих сервисов.
Соответственно, приемлемым решением видится создание объекта и заполнение его свойств на стороне ответственно службы, после чего передача данного объекта через сериализацию. Можно даже распространять конфиги таких сериализаций через некую общую точку ответственности, ну или как минимум один раз задать их в документации к ответственному сервису, после чего везде их использовать. Насколько я знаю, как-то подобным образом (через автоматизацию) такая задача решена в Авито, например.
Мы работаем на HashiCorp стеке (Nomad + Consul). Но внедрять Vault ради всего этого я думаю мы не будем, да и не мне решать, на что мы потратим деньги в этом вопросе. Но спасибо за ответ!
Дмитрий, в том-то и дело, что не факт, что он будет, так как пока непонятно, как это фиксить - можно не передавать параметр про выброс исключения, и соответственно исключения и не будет.
Ну, пока нет возможности кроме как стабами указывать что выбрасывает некие исключения, ваш ответ наверное будет верным. Как создать свой стаб или например скопировать от JetBrains и внести в него правки, я знаю, но проблема не в этом, а в том, чтобы это работало везде и всегда. На своей локальной машине, на машинах ревьюверов, на машине дома, на переустановленной системе, ну и тд. Для меня тут вариантами решения было два способа:
1. Внести правки в некий общий стаб, либо в штормовский, либо в phpшный
2. Найти некую инструкцию, которой в коде можно было бы указать, что вот тут будет выброшено исключение.
У меня вообще EAP. Но и в самой свежей версии будет то же самое.
Еще раз уточню, видимо, это не совсем ясно - проблема не в PhpStorm как таковом, он всего лишь использует для узнавания об исключениях либо stubs из самого php, либо из специально разработанной ими же самими либы JetBrains/phpstorm-stubs.
И вот там нет в аннотациях исключения JsonException для функции json_decode, которое мне интересно. Его нет в целом, наверное, по адекватной причине - совершенно не факт, что я передам в json_decode опцию JSON_THROW_ON_ERROR, которая и заставит выбрасываться данное исключение. Но как в итоге быть, если я опцию передал? Надо же иметь возможность указать IDE и себе самому, что тут на самом деле все ОК. И глушить проверку этой ошибки тоже не вариант, выше уже писал почему.
Дмитрий, это понятно, в вопрос внес изменения. Но подсвечиваться они все равно не стали. Стабы что в php.jar что от самой IDE там никакие "@throws" не имеют, соответственно проблема остается, и непонятно, как ее можно решить без лишних плясок.
При этом вопрос достаточно насущный, так как в итоге можешь забывать потом включать эти исключения в аннотации метода, и соответственно потом его где-то не отлавливать, ну и тд. Впору хоть впрямь идти делать форк и реквесты в официальные стабы.
BoShurik, я понял ваш ответ, и наверное он по сути своей верный. Только подскажите, он отличается чем-либо от того ответа, в ветке которого мы общаемся? Если да, то опубликуйте, пожалуйста, свой комментарий как ответ с разъяснением этого отличия. Если нет, помечу данный ответ как верный, чтобы людям потом удобно было :-)
Ну и собственно я это решил созданием прямо в папке тестов, где это все требуется, фейковых классов, по классу на файл. Выглядит, как по мне, чуть эстетичнее, чем писать его прямо в коде, да и переиспользовать можно.
