Вдобавок, такая "оптимизация" может ухудшить дело, потому что не получится реализовать ленивый подсчет данных. Простой пример - если заказ не подтвержден, то не нужно выводить сумму его товаров, а если подтвержден - нужно. Представим, что сумма нигде не хранится и считается на лету из товаров в корзине заказа. При использовании объекта, подсчет суммы не выполнялся бы вообще для неподтвержденных заказов, потому что метод getTotal() не будет вызван в шаблоне. А при конвертации в массив нужно будет высчитывать всё, ведь неизвестно, что пригодится в шаблоне, а что - нет.
Сразу скажу, что я не считаю вызов метода в шаблоне проблемой и считаю использование разных шаблонов для подтвержденных и неподтвержденных заказов оверкилом, если количество различий в них невелико и эти различия не слишком сильные.
Евгений Елчев: я вам настоятельно рекомендую не тратить время, вы сами видите, как пациент автор реагирует на конструктивные советы, которые более, чем на шаг, отступают от конкретного ответа на его конкретный вопрос. И даже конкретные ответы он не анализирует и не извлекает никаких уроков для себя.
Да, можно во все классы запилить поддержку ArrayAccess, но какой в этом смысл? Если вью будет работать с объектом, то это только трата времени. Если вью будет работать с массивом, то ArrayAccess тут ничем не поможет - никакого объекта уже нет. Я не вижу смысла делать такой hot swap.
Это как делать framework-агностик приложение, чтобы в любой момент можно было заменить Симфони на Ларавел - идея прикольная и дизайн в итоге, возможно, будет лучше (но далеко не факт, потому что такое усложнение может сделать всё только хуже), но на практике такие переезды происходят очень редко и даже когда происходят, безболезненно они не проходят.
Гораздо эффективнее сделать минимально необходимый дизайн, а потом, если уж припрет, потратить дополнительное время на перенос. По большому счету, то, что вы предлагаете, это Big Upfront Design и я не сторонник такого подхода. Лучше вносить изменения итеративно исходя из текущих потребностей бизнеса, оплачивающего работу и не заглядывать сильно далеко в будущее. Есть ненулевая вероятность, что пока вы будете имплементировать в классах ArrayAccessable Interface, заказчик разорится и ваш красивый, расширяемый, поддерживаемый код окажется никому не нужным.
Разумеется, я утрирую в данном конкретном случае, но мой опыт показывает, что такое отношение является самым выгодным и для меня и для заказчика.
Если смотреть на объект исключительно как на выполнятель каких-то команд и операций, то да, вы правы, во вью этому не место. Но ведь объект еще и хранит состояние. Лично я по дефолту предпочитаю читаемость кода скорости его выполнения (разумеется, до тех пор, пока эта скорость не является очевидной проблемой), и именно объекты предоставляют эту читаемость.
Вот опять - вы на стороне сервера отдаете массив объектов, а на стороне клиента пытаетесь обратиться к свойству fio этого массива. Вы не понимаете, в чем разница между объектом и массивом?
Посторонним В.: для этого композер и создан - вы храните свои классы, организованные в пакеты, в репозитории и подключаете их как зависимости в composer.json. А уже скачиванием и автозагрузкой занимается композер.
Сразу скажу, что я не считаю вызов метода в шаблоне проблемой и считаю использование разных шаблонов для подтвержденных и неподтвержденных заказов оверкилом, если количество различий в них невелико и эти различия не слишком сильные.