Pull to refresh

Comments 15

Сегодня объекты используются очень активно, хотя это трудно было предположить после выхода PHP 5 в 2005 году.

Да, ладно, ещё в 2003 году я активно использовал объекты в PHP 4. И в книгах по PHP объекты были.
Пародия, не пародия, это были объекты.
Почему пародия? Обычное ООП со некоторыми кривостями.
Никто не спорит что в PHP 5 они реализовано лучше, а в PHP 5.6 еще лучше.
Помню, с появлением PHP 4 старые опытные разработчики мне говорили. «Не надо использовать ООП в PHP. Ты не понимаешь самой сути веб-программирования на PHP.» А я не слушал, и внедрял ООП в свои проекты.
UFO just landed and posted this here
А можете развернуть вашу мысль, мне, например, стало интересно?

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

Угу, да. А как же это: http://habrahabr.ru/post/161629/?
Та статья очень красочно подтверждает эту.
Там:
Версия PHP — 5.3.10

Тут:
Обратите внимание, что в версии 5.3 всё не так хорошо с точки зрения возможностей и общей производительности.
У вас всегда есть возможность уничтожать свои объекты вручную, чтобы полностью контролировать очерёдность.

Если, конечно, вы контролируете весь код, который работает с этими объектами.

PHP вызовет деструктор, когда refcount вашего объекта упадёт до нуля

… или будет подчищен собирателем цикличесих ссылок.
или будет подчищен собирателем цикличесих ссылок

Который вызывается лишь когда собирается необходимый кворум из «корней» (root buffer), которые могут добавляться только на каждое уменьшение refcount у ссылки на объект.

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

В случае же с программированием back-end для web, с целью получить на выходе пригодный для обработки браузером или клиентским приложением xml (json, whatever), объектный подход — это очевидный костыль, который не только не помогает задаче, но и неоправданно усложняет архитектуру самого проекта и делает его менее «прозрачным» для «читателя», а исполнение самого кода более ресурсозатратным.

Не пользуйтесь объектами, там, где они не нужны. Используйте для решения линейных задач функциональный подход. Не умножайте сущности без необходимости. Делайте проще то, что можно сделать проще по определению.
У меня плохие новости, но с такими советами получается лапша из кода, а не приложение.

И цикл жизни/сопровождения такого приложения заканчивается переписыванием оного с нуля.
Используйте для решения линейных задач функциональный подход
Вы тут перепутали функциональный подход с процедурным или имели ввиду что-то, чего я не понял?
Sign up to leave a comment.