Предметно о разнице процедурного программирования и парадигмы
Одна страница
Распечатать
Вот все хвалят ООП, в книжках по РНР его возносят.
А можно пример одного и того же скрипта (делающего одну и ту же задачу) на обычном методе, и на ООП?
Просто хочется понять, за что его хвалят.
А можно пример одного и того же скрипта (делающего одну и ту же задачу) на обычном методе, и на ООП?
Просто хочется понять, за что его хвалят.
Всё, что мне известно о PHP-меня научил 4X_Pro
Опрос пользователей о деятельности _1_ http://intbpro.ru/flood/119/
Дело в том, что на простых скриптах, которые пишутся один раз и решают какую-то конкретную задачу, плюсы ООП почувствовать сложно. Например, в TextCMS я прекрасно обошёлся без ООП. Преимущества проявляются в больших проектах, особенно в тех случаях, когда техзадание меняется на ходу и приходится переделывать уже написанное. В этом случае главный плюс будет от такой составляющей как инкапсуляция, когда работа с данными внутри объекта локализована в его методах, а не размазана по всему коду.
В качестве примера плюсов наследования можно привести такой. На моём соционическом форуме есть раздел «Исследования». По сути дела там обычные опросы, но нужно вывдодить не суммарные результаты, а с раскладом по социотипам (которые указаны в профиле участников). И вот с помощью ООП это было сделать очень легко: я сделал класс-наследник stdforum, назвал его research и добавил туда всего одно действие: action_results, где сделал нужный вывод.
А если бы код был бы организован, как в IntB 2.x, то есть процедуры назывались бы stdforum_action_что-то там, то пришлось бы в модуле research переопредлять все процедуры и вызывать там соответствующие методы stdforum.
Ещё ООП позволяет создавать такую вещь, как ORMы, которые позволяют скрыть работу с базой от программиста. Но я считаю это злом, поскольку в этом случае объект всегда тащится из базы весь, вне зависимости от того, нужно это или нет, а то и со всеми своими зависимостями. (Ну или приходится городить какой-то сложный lazy loading.)
В качестве примера плюсов наследования можно привести такой. На моём соционическом форуме есть раздел «Исследования». По сути дела там обычные опросы, но нужно вывдодить не суммарные результаты, а с раскладом по социотипам (которые указаны в профиле участников). И вот с помощью ООП это было сделать очень легко: я сделал класс-наследник stdforum, назвал его research и добавил туда всего одно действие: action_results, где сделал нужный вывод.
А если бы код был бы организован, как в IntB 2.x, то есть процедуры назывались бы stdforum_action_что-то там, то пришлось бы в модуле research переопредлять все процедуры и вызывать там соответствующие методы stdforum.
Ещё ООП позволяет создавать такую вещь, как ORMы, которые позволяют скрыть работу с базой от программиста. Но я считаю это злом, поскольку в этом случае объект всегда тащится из базы весь, вне зависимости от того, нужно это или нет, а то и со всеми своими зависимостями. (Ну или приходится городить какой-то сложный lazy loading.)
Критикуя — предлагай, предлагая — обосновывай!
4xpro.ru — мой личный сайт-мультиблог на Intellect Board.
4X_Pro написал(а):
вот с помощью ООП это было сделать очень легко: я сделал класс-наследник stdforum, назвал его research и добавил туда всего одно действие: action_results, где сделал нужный вывод.
А если бы код был бы организован, как в IntB 2.x, то есть процедуры назывались бы stdforum_action_что-то там, то пришлось бы в модуле research переопредлять все процедуры и вызывать там соответствующие методы stdforum.
Так, а если взять одного программиста (допустим, тебя), и написать скрипт этого опроса тем и тем методом, то время выполнения скрипта, и нагрузка на камень от их выполнения-будет одинакова?
Всё, что мне известно о PHP-меня научил 4X_Pro
Опрос пользователей о деятельности _1_ http://intbpro.ru/flood/119/
Если сравнивать конкретно тот пример, который привёл я, то там разница будет такая: на один вызов метода меньше, но зато для ООП-версии передаётся скрытый параметр $this. В принципе, пока классов мало, разница несущественна.
Вот если код будет писать фанат следования паттернам ООП и нарежет его на кучу мелких-мелких классов (этим часто страдают те, кто переходит на PHP с Java) с кучей вызовов между ними или будет в классах хранить то, что можно в обычных хешах, тогда ООП-версия будет проигрывать. Причём основная причина — это затраты на выделение памяти под все эти объекты мелких классов самим PHP на этапе их создания.
Вот если код будет писать фанат следования паттернам ООП и нарежет его на кучу мелких-мелких классов (этим часто страдают те, кто переходит на PHP с Java) с кучей вызовов между ними или будет в классах хранить то, что можно в обычных хешах, тогда ООП-версия будет проигрывать. Причём основная причина — это затраты на выделение памяти под все эти объекты мелких классов самим PHP на этапе их создания.
Критикуя — предлагай, предлагая — обосновывай!
4xpro.ru — мой личный сайт-мультиблог на Intellect Board.
Я постоянно узнаю от тебя что-то новое. Ничего не знал о скрытых параметрах. Погуглил, очень много пишут о нем в С++, как о параметре, передаваемом при компиляции.
Что же касается веб, то скрытые параметры упоминаются при передаче форм.
Хотя я не до конца понял, почему этот параметр ты упомянул именно касательно к ООП. И почему наличие этого параметра тебе "понадобилось" именно при приведении примера с ООП, а не повсеместно...
А при большом проекте с применением ООП и грамотного кеширования-память будет экономится?
Всё, что мне известно о PHP-меня научил 4X_Pro
Опрос пользователей о деятельности _1_ http://intbpro.ru/flood/119/
. Редактировалось 1 раз, последний — #6
Вообще, ты тут спутал два совершенно разных понятия: скрытый параметр метода, который указывает на данные класса. При этом этот скрытый параметр существует в коде, который выполняется уже на сервере. Он есть не только в C, но и во всех ООП-языках. Исключением является только Python, там он прописывается явно из-за философии языка «явное лучше скрытого» и обычно называется не this, а self.
А второе — это скрытое поле формы, которое нужно для передачи данных от клиента к серверу. Например, в этом форумном движке при редактировании сообщения в такое скрытое поле кладётся его id. А ещё в одном скрытом поле лежит authkey, который нужен для защиты от CSRF-атак.
А второе — это скрытое поле формы, которое нужно для передачи данных от клиента к серверу. Например, в этом форумном движке при редактировании сообщения в такое скрытое поле кладётся его id. А ещё в одном скрытом поле лежит authkey, который нужен для защиты от CSRF-атак.
Критикуя — предлагай, предлагая — обосновывай!
4xpro.ru — мой личный сайт-мультиблог на Intellect Board.
4X_Pro написал(а):
Вообще, ты тут спутал два совершенно разных понятия: скрытый параметр метода, который указывает на данные класса.
Это не удивительно. Я тоже самоучка, но не фанат, как ты. Я неглубоко в теме программирования.
4X_Pro написал(а):
А второе — это скрытое поле формы, которое нужно для передачи данных от клиента к серверу. Например, в этом форумном движке при редактировании сообщения в такое скрытое поле кладётся его id
Пошёл гуглить....
Всё, что мне известно о PHP-меня научил 4X_Pro
Опрос пользователей о деятельности _1_ http://intbpro.ru/flood/119/
Одна страница
Распечатать У вас нет прав для отправки сообщений в эту тему.