Как в PHP из массивов сделать объекты с подсказками?

🤣 А я знаю такой анекдот:
Не зли меня, а то заболеешь.
Чем?
Переломом челюсти и сотрясением мозга.
Будьте осторожны так, как первую уже получили в виде дизлайка.

Да чего мне злить, программирование интересная штука и я пришел к выводу, что если ты не можешь покрыть свой код тестами или описать комментариями, то это говнокод =)) Вот человек столкнулся с выдуманной проблемой, если его многомерные массивы разложить на объекты, то помимо того, что любая IDE без всяких костылей начнет его понимать, так появится еще куча полезностей.

Я к тому, что даже в случает автора, он придумал костыль, что надо написать какой то класс, который никогда не будет использоваться по назначению, чтоб потом массив затипизировать в stdObject и просто сделать коммент. Да в таком проекте будет проще застрелиться чем разобраться... зачем делать конструктор приватным и всю эту вакханалию, если можно написать маппер и сделать код вида

class Super {}
$myClasss = new Super($myFackerArray);

и всё, одни плюсы =))

Можно фабрику наваять
$myObject = Factory::create(Super::class, $myFackerArray);

Да и вообще в методологиях программирования уже много всего придумано как делать красиво и легко поддерживаемо, просто как правило битриксоиды не хотят расти, они ставят точку вечно =))

Павел, спасибо за мнение. У меня есть опыт работы с D7 и тоже предпочитаю использовать объекты, но когда имеешь дело со штатными компонентами, то вот там как раз в шаблоне мы и получаем многомерные массивы и это печалит.
А костыль да, ещё тот))
Буду признателен, если поделитесь ссылкой на решение с маппером или фабрикой, которое вы считаете более грамотным.

Ваш код в конкретных случаях будет уникальным, просто почему бы вам ваш пример не сделать проще. Но через конструктор не очень удобно проверять валидность данных, по этому стоит сделать геттеры и сеттеры. Ну и так далее

Согласен про конструктор, немного поправил статью. И я понимаю прекрасно про геттеры и сеттеры, про магические методы я тоже знаю и понимаю. Но нужно будет в конструкторе писать создание экземпляра класса для каждого вложенного объекта.
Вот пример с интерфейсами в TS. Можно вынести объект в отдельный интерфейс и использовать его ещё где-то, а можно оставить объектом с полями. Т.к. такого функционала у php нет, его можно заменить классами и PHPDoc))

Не совсем так (и уж совсем не так про сеттеры).
Вы должны создавать нужные вам для работы сущности. И они совсем не должны повторять структуру массива приходящего от Битрикса. Они могут забирать данные из такого массива (а может и из двух, трех и тп). Равно как из одного массива может собираться несколько совершенно разных сущностей.

Собираться это должно, конечно, в конструкторе. Но так как привязывать конструктор сущности к структуре массива Битрикса не очень хорошо, то конструктор должен описывать структуру сущности (особо в современных версиях ПХП) и вообще может быть приватный. А для создания из массива Битрикса стоит использовать отдельный билдер, чаще это именованный конструктор (для ПХП это будет просто статический метод в классе сущности, что позволит основной конструктор делать приватным при необходимости). Если из массивов получается много объектов - конечно сделать отдельно билдер.

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

Автор предложил создавать сущности для того чтобы указать их в комментарии.
Остальной поток мыслей ваш вообще не понял если честно =)))

1. Приватный конструктор вам нужен только в единственном случае (по крайней мере в php другого использования я не встречал) это сделать синглтон, чтоб был единый объект для всей системы, но это антипаттерн, в том числе потому что меняет поведение в тестах и может быть изменен из вне.

2. Про структуру сущности и стурктуру массива чет я поплыл, слишком сложно, а уточнее про новые версии php вообще привели в тупик, к чему вы это? =))

3. Что будет с вашим кодом, если туда передать другой массив с другими данными? Вот у вас есть метод, в нем прописан входной параметр array и? вы уверены что в поле ID там будет число в виде заказа с битрикса а не UUID из 1С? Вам просто надо переложить будет валидацию на сторону разработчика, но для этого завезли типизацию и я буду уверен что в setId(int $id) придет именно ID либо код упадет, логгер его подхватит и я увижу сообщение в телеге и пойду исправлять косячную логику.

4. Про избегать сеттеров можно подробнее? Для чего в модели данных избегать иммутабельности? Можно примером, а то прям интересно стало.

Бро, а огромные, сколько в секунду нагрузка?)

1. Это хорошо, что есть поддержка в PHPStorm, не все им пользуются. Но есть проблема, если вы используете массивы часто и много, а особенно если они большие, ваш код будет изобиловать комментариями, описывающими структуру массива. Возьмите штатный компонент битрикса и несколько шаблонов для него и получится, что в каждом шаблоне вам придётся описывать структуру этих массивов, а если там есть result_modifier.php и component_epilog.php, то ещё по разу в каждом файле. Такое себе решение, как по мне.
2. За совет спасибо, изучу.

Спасибо, я что-то читал, не совсем мне подошло, вроде.