Вы используете ООП на полную силу в PHP?

[latrekc]

что значит на полную силу?

[mihazimin]

Я имел ввидк примерно следующее: знать и использовать PHP design patterns, везде использовать ссылки на объекты а не их самих; при создании нового файла в большинстве случаев писать class, а потом по ситуации :-)

[gro]

везде использовать ссылки на объекты а не их самих

А как можно использовать одно или другое по выбору, если язык предоставляет только один вариант?

при создании нового файла в большинстве случаев писать class

Писать class везде где ни попадя, это не "использовать на полную силу", это маразм.

Использовать ООП, это не design patterns и class везде, это значит, мыслить объектами, а не раздельными процедурами и данными.

[mihazimin]

А как можно использовать одно или другое по выбору, если язык предоставляет только один вариант?

В PHP5, — к счастью да. В четверке, — программист мог решать это в объявлении функции.

Писать class везде где ни попадя, это не "использовать на полную силу", это маразм.

У меня там смайл стоит. Я и не говорил где ни попади.

мыслить объектами, а не раздельными процедурами и данными

согласен, но это, в том числе и знание design patterns, вы согласны?

[gro]

В четверке, — программист мог решать это в объявлении функции.

Если вы о "&", то так и в 5-ке можно, но это не совсем то и не совсем так же работает.

это, в том числе и знание design patterns, вы согласны

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

[buddy]

вы правы, это относится к ООД :)
а вообще, "ООП на полную силу в _PHP_" конечно сильно сказано :))

p.s. имхо, выражение "на полную силу" стоит убрать ;)

[norguhtar]

use full force Luke!

[Frobozz]

Можно встречный вопрос - а присутствует ли полноценная реализация вех принципов ООП в РНР (с указанием версии), чтобы их можно было применять? Сам использую РНР и люблю его, но не назвал бы его "полностью правильным" объектно-ориентированным языком. Про PHP6 еще не слышал, спасибо за информацию, ушел искать.

[gro]

А каких конкретно вещей из "полноценной" реализации вам не хватает в PHP5?

[timurkar]

вот не знаю относится ли это к "полноценной" реализации (скорее не относится), но в OOP PHP5 мне не хватает Friend-классов. но в целом полностью устраивают возможности (еще бы более удобную работу со свойствами и вообще было-бы супер)

[gro]

Namespaces уже в 5.3 будут, но это не совсем ООП.
Что вы подразумеваете под перегрузкой методов? Разные методы в зависимости от типа аргументов? В слоботипизированном PHP это реализуется, но в другой форме.

[mihazimin]

может имелась ввиду перегрузка операторов?

[ashofthedream]

перегрузки операторов очень не хватает :(

[gro]

Нет, через if (is_int(...) в теле функции :)
Приведите пример функции, где это требуется в PHP и как по-вашему в том же PHP это можно было бы реализовать "правильно".

[ashofthedream]

мечта блин... тоже хочу такую чтуку, хотя она частично в пятом есть, но только для указания классов которые нам нужны, к примеру __construct(MyClass $myclass) {}

[gro]

PHP's Strong typing (SPL_Types)

[gro]

Данная проблема для PHP не слишком большая, а решение весьма спорное.

[ashofthedream]

большая, решение - отличное.

[gro]

Может проблема и действительно не меньше, неправильно выразился. Решение спорно, как и большинство решений дословно, переносимые с других языков.
В текущей реализации PHP, это можно решить нисколько не сложнее:
public function setLocale($locale)
{
if (is_object($locale)) {
$locale = $locale->getId();
}
$this->localeId = $locale;
}

Более того, если в методе подразумеваются другие действия, не зависящие от типа аргумента, то в вашем варианте их придется держать в двух местах.

[ashofthedream]

а если у нас не два, а 20 различных видов значений может быть? встолбик использовать if/elseif или начать уже писать switch?

[gro]

Двадцать вариантов типов это ПЦ. Как полным ПЦ будет и двадцать перегруженных методов.
Хотя такое может быть при различных вариантах задания какого-то значения, но тогда лучше иметь метод/функцию, которая бы производила приведение всех эти варианты к одному, а в прикладном коде вызывать её.

[gro]

А как мне узнать о том, что такой метод принимает только int и экземпляры только класса Locale

Да так же, как собственно и для любого метода, который может принимать только int. Документированием/самодокументированием кода.
Да, IDE для PHP менее развиты, чем IDE для некоторых других языков. Да и вряд ли они вообще в принципе могут иметь многие фишки которые есть в IDE сильнотипизированных языков.
Но это общая проблема, а не только перегрузки методов и тем более ООП.

[Frobozz]

Ну "три кита" (наследование, полиморфизм, инкапсуляция) присутствуют уже в РНР5, поэтому снимаю свой коммент. Т.е. я все-таки бы отнес РНР (начиная с 5) к объектно-ориентированным языкам. Все остальные особенности относятся к реализации.

Но шутка в том, что в РНР остается возможность писать и в старом добром процедурном стиле, и ничего этому не мешает. Что, наверное, и раздражает в РНР (наряду с нестрогой типизацией) тех, кто пишет на Java и .NET.

[neudor]

Кто-нибудь мог бы подкинуть ссылок про то, КАК его использовать правильно. Желательно с примерами. Сейчас использую ООП только для разделения пространств имён логически отдельных кусков программы.

[va1en0k]

http://ru.wikipedia.org/wiki/Шаблоны_про… отсюда и дальше

[blackstone]

Стремлюсь использовать в php "best practices" такие как паттерны, разработка посредством тестирования и т.д.
Но пока не хватает опыта в этих вещах.

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

[ashofthedream]

Он сформирован давно, очень много полезной инфы можно по этой теме (архитектура приложений, разработка, паттерны) найти по другим языкам - С, Ява.

[blackstone]

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

[ashofthedream]

Дело в том, что когда я начинал понимать все эти шаблоны, я тоже был ленив и думал, что они будут немного различаца применительно к пхп и вебу - задачи все таки разные. Но потом, когда опыта стало чуточку больше понял, что вообще-то они не привязанны веревкой ни к какому языку, а надо просто чуточку подняпряься, подумать, и самому понять (а это уже будет очевидно) как можно их использовать в вебе, когда ты пишешь на пхп :)

[blackstone]

При всех возможных недостатках php - это не значит что там не нужно стремиться к хорошей архитектуре. Сложно опровергнуть, что php - самый популярный на данный момент в рунете.
И при всем уважении к другим языкам, для них и хостинг сложней найти и заказчика, который захочет.
Просто я также работаю с asp.net и даже под эту замечательную технологию трудно заказчиков убедить.
Я бы сказал так - везде хотят php.

[blackstone]

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

[nekt]

не стоит забывать что и пхп-кодеров(программистов) гораздо больше, нежели жавщиков

[blackstone]

Очень важным фактором это считаю.
Одно время пытался на asp.net найти удаленку - очень мало предложений.
Многие компании не хотят ниче кроме php, т.к. найти разработчиков сложно на других технологиях.

[ashofthedream]

То что надо научится мыслить объектно - это правильно, но вот говорить о том, что PHP - это совсем не тот язык, в котором можно реализовыавть свои мысли объектно - полностью не согласен

[nekt]

лучше всего ООП показывает себя в программах, которые потенциально могут работать достаточно продолжительное время, а не в скриптах...

по крайне мере у меня такое имхо

[nekt]

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

[ashofthedream]

Мне кажется что называть бизнес логику работы сайта "скриптом" - немножко неправильно

[nekt]

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

[blackstone]

А в чем разница?
Просто жизненный цикл страницы начинается и заканчивается быстро.

[nekt]

взаимодействие объектов не настолько полное. Само представление о объектах, по сути, разное. В одном случае это набор методов, а в другом - все-таки объект как логический элмент структуры.

[ashofthedream]

Вы определенно не в том направлени мыслите.

[gro]

нечто крутится в памяти, составные части которого взаимодействуют друг с другом, совершая в течение некоторого времени, определенные действия

А в веб-сценариях это разве не так?
Разве программа, которая на основании полученных данных формирует ответ, чем-то принципиально отличается от других?
PHP-сценарий быстро выполняется... Для кого быстро? Он выполняется на протяжении миллиардов процессорных тактов.

[nekt]

он выполняется настолько быстро, что в процессе выполнения не может появится никаких новых входных данных.

[gro]

То есть вы имеете в виду, то что php-сценарий не интерактивный? Но ни время выполнения, ни ООП тут не причем.

[buddy]

позволю себе вклиниться в ваш разговор...
состояние объекта в пхп (осбственно как и сам объект) храниться на протяжении выполнения сценария, а не на протяжении работы всего приложения в целом, как это может быть например в Java...

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

[gro]

Аргументируйте своё мнение.

[nekt]

см ответ выше. И повторюсь. это только мое мнение.

[mihazimin]

Господин Chapaev, я разделяю ваши симпатии к Ruby. Отчасти и к Java. Но у меня впринципе не стоит вопрос "на чём программировать", "какой язык лучше" и т.п. И не считаю, что php лучше какого-то языка. Я не говорю, что ООП в php6 будет сравним с ООП да хотя бы в том же Ruby. Я вообще не собираюсь поднимать эти вопрос. Потому что знаю на них ответы.

Мне просто интересно кто как использует ООП в PHP и всё.

[nekt]

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

[gro]

Вы либо не в полной мере знаете уровень задач на ПХП. Либо не знаете уровень для ООП.

[blackstone]

Я думаю одним из примеров нужного использования ООП в php может являться след. решение: уровень доступа к данным сделать через астрактный класс, от которого будет наследоваться "провайдер" для конкретной СУБД. И соотв. для смены СУБД потребуется просто переписать провайдер, а остальные уровни системы даже не заметять подмены СУБД.

[smith]

Давайте поподробнее взглянем на ваш пример. Очень распространенное мнение, что смена реализации класса доступа к БД достаточно для смены самой БД. Вы в это верите? Я еще не сталкивался с ситуацией, когда необходимо сменить БД в проекте, без глубокого переписывания самого проекта. В данном случае класс просто меняет обращение к БД с функций на методы. Кроме того мы получаем дополнительные вызовы, которых можно легко избежать. Так что пример с БД не самый хороший.

[blackstone]

Мне кажется что красивое решение.
Эту идею я почерпнул из хорошей книги по asp.net.
Имеется ввиду, что унаследованный класс от абстрактного будет абсолютно по разному реализован с учетом особенностей СУБД. А если на бизнес-уровень передаются коллекции объектов от дата-уровня, то какая разница как они реализованы на дата-уровне - там к чему-угодно может быть обращение и к СУБД и xml и текстовый файл, а может даже web-сервис.
А дополнительные вызовы сокращать кэшированием.

[ashofthedream]

Тогда мне кажется вы не писали больших приложений :)

[blackstone]

А что не так с данной теорией?
Может меня не правильно поняли? Я имею ввиду не универсальные запросы к БД, а именно написание провайдеров с учетом особенностей каждой СУБД.
А на бизнес-уровень передавать коллекции объектов от дата-уровня.
Разве большое приложение не может иметь такую архитектуру, где все разделено на уровни(BBL, DAL, UI) и можно переделать один, не меняя остальные?

[ashofthedream]

может быть это к коменту выше :) ?

[nekt]

это был коммент мне.

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

Хотя уровни, это несомненно хорошо.

[nekt]

на пхп? :) нет :)

[w0lf]

Зависит от задач на самом деле. В каких то проектах использую в полную силу, где то не использую абсолютно.

[jodaka]

что значит не устраивать holy war?
Ведь в посте есть слово PHP, а значит холиворам быть! :)

по теме:
года 4 назад назад, я писал проект на php и там ООП использовался, но его реализация в php на тот момент была, скажем так, убогой. Но, тем не менее — ООП использовали и будем использовать (благо сейчас языков много - есть из чего выбрать)

[mihazimin]

Т.к. уже отхабрили, а значит вопрос этот к войне не приведет, то задам (просто интересно):
и на чём пишите сейчас?

[jodaka]

ruby и perl(просто для души :)

на самом деле я ничего не имею против php, просто на мой взгляд есть более интересные языки. Те-же самые ruby и python, например

[mihazimin]

т.е. реально пишете на Ruby в коммерческих веб проектах?

[jodaka]

реальнее не бывает.
И на руби и на перле.
А почему собственно нет? Удобно же

[mihazimin]

да, согласен, что ruby хороший язык. И ещё вопрос, а вы рельсы используете или что-то другое?

[jodaka]

rails 1.2
до 2.0 как-то всё руки не доходят :-\

[ignatov]

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

[abba]

мы рады за вас... повезло что называется!

[3biga]

Я правильно понимаю, что среди людей на хабре только один человек из пяти не является разработчиком на ПХП?

[mihazimin]

Скорее 1 из 5 никогда не пробовал PHP на вкус. Думаю в этой статистике нет ничего преступного :-)

[3biga]

Для меня как раз наоборот: хотелось бы видеть больше людей, занимающихся не php и html-кодингом.