-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Использую ли я Объектную Модель
- Автор темы Alexandre
- Дата начала
WP
^_^
Я не сторонник полного ООП, т.к. это Imho не оправдано, объектом можно сделать библиотеку - это да, news делать объектом... непонятно зачем. Все равно будешь юзать каждый метод по одному разу в основном. А лаги от объектов наблюдаются не кислые, и в этом нет ничего удивительного. А главное это не приносит никакого удобства, просто куча лишнего кода.
jonjonson
Охренеть
Тоже самое можно сказать например о функции подключения к БД
И какая часть функций из API php используется постоянно? А вами лично?
А как вы думаете? Можно ли потом использовать класс новости в других проектах?
И если что, вносить изменения в функционал класса содержащего всю логику работы с новостью намного проще. Или нет?
boombick
boombick.org
Я сделал API своего фреймворка в двух видах... Можно использовать напрямую методы объектов (т.е. $obj->method($val)) или же для поклонников процедурного стиля через функции:
function func_method($val){
return $obj->method($val);
}
кому как удобнее.. С помощью ОО сделано ядро системы... А для конечной разработки оно оказалось не так уж и востребовано.
function func_method($val){
return $obj->method($val);
}
кому как удобнее.. С помощью ОО сделано ядро системы... А для конечной разработки оно оказалось не так уж и востребовано.
boombick
boombick.org
есть куча кода, работающего на функциях. И есть библиотеки этих функций. Переписываем ядро (т.е. библиотеки) в ОО-стиле, добавляем вагон всяких примочек, но сохраняем совместимость с кодом, который вызывает функции, а не методы. Это только один из примеров. Мыслить надо шире, Алексей =)
Gorynych
Посетитель PHP-Клуба
после двух лет писания только под PHP 5 ответ может быть только один: да, разумеется
до маразма не дошел, поэтому не все существующее API неприменно и обязательно оформлено в виде классов и иметодов. Функции, разумеется, есть там, где заводить объект бесперспективно (потому как инкапсулировать функцию в виде метода класса только ради строгости ООП - извращение).
Точно так же, как есть и использование статических переменных в функциях (что, кстати, часто позволяет решить конкретную задачу без нагромождения класса вокруг нужной функции)
до маразма не дошел, поэтому не все существующее API неприменно и обязательно оформлено в виде классов и иметодов. Функции, разумеется, есть там, где заводить объект бесперспективно (потому как инкапсулировать функцию в виде метода класса только ради строгости ООП - извращение).
Точно так же, как есть и использование статических переменных в функциях (что, кстати, часто позволяет решить конкретную задачу без нагромождения класса вокруг нужной функции)
themylogin
Новичок
Своих классов штук 5, не больше. + из библиотек беру. И всё.
Может, когда я стану профессионалом, мне будет удобно писать огромные классы, толком ничего не делающие, но пока не вижу в этом смысла. Вчера разбирался с IPB - это ж надо такого бреда написать...
Может, когда я стану профессионалом, мне будет удобно писать огромные классы, толком ничего не делающие, но пока не вижу в этом смысла. Вчера разбирался с IPB - это ж надо такого бреда написать...
WP
^_^
jonjonson
Во-первых не обязательно один раз. Возможен случай когда нужно два коннекта. Во-вторых методы query, query_fetchrow и т.д. используются очень часто. А также они взаимодействуют между собой, т.е. например пишется последний запрос в $last_query, и т.д. Поэтому использование объекта оправданно. Потому что это законченная библеотека в себе. И она будет использована много раз в разных в местах. Это как например мой class captcha, может быть использован где угодно и когда угодно, а также это законченная библеотека в себе. А новости я так не рассматриваю, т.к. они связаны с другими сущностями, например, у меня JOIN-ится таблица юзеров и групп. Поэтому без исправления этот класс можно было бы использовать только в 1 месте. Смысл теряется. Или вот class multiproc юзается много раз и в разных местах...
Объекты нужны только там где они нужны.
Во-первых не обязательно один раз. Возможен случай когда нужно два коннекта. Во-вторых методы query, query_fetchrow и т.д. используются очень часто. А также они взаимодействуют между собой, т.е. например пишется последний запрос в $last_query, и т.д. Поэтому использование объекта оправданно. Потому что это законченная библеотека в себе. И она будет использована много раз в разных в местах. Это как например мой class captcha, может быть использован где угодно и когда угодно, а также это законченная библеотека в себе. А новости я так не рассматриваю, т.к. они связаны с другими сущностями, например, у меня JOIN-ится таблица юзеров и групп. Поэтому без исправления этот класс можно было бы использовать только в 1 месте. Смысл теряется. Или вот class multiproc юзается много раз и в разных местах...
Объекты нужны только там где они нужны.
crocodile2u
http://vbolshov.org.ru
Проголосовал "иное, укажу в топике".
Я стараюсь не доходить до крайностей. ООП я использую довольно широко, но там, где можно (и, вполне возможно, проще) обойтись, скажем, массивом - использую массив. Например, мне удобно представлять список новостей - результатом выборки из БД, а отдельную новость - объектом шлюза записи данных (но не тогда, когда я работаю со списком новостей, а когда работаю с отдельной новостью). В общем, стараюсь не доходить до паранойи.
Я стараюсь не доходить до крайностей. ООП я использую довольно широко, но там, где можно (и, вполне возможно, проще) обойтись, скажем, массивом - использую массив. Например, мне удобно представлять список новостей - результатом выборки из БД, а отдельную новость - объектом шлюза записи данных (но не тогда, когда я работаю со списком новостей, а когда работаю с отдельной новостью). В общем, стараюсь не доходить до паранойи.