Сразу скажу, что с принципами ООП я знакома, ценю и применяю в Delphi, немного в C++. Все преимущества знаю, понимаю. Вопрос не в этом.

Анализируя то, почему я применяю ООП в создании прикладных программ.., мммм... не могу найти смысла в объектном подходе в РНР хотя бы на примере этого самого форума.
Читала где-то, что если не требуется создание более одного объекта некоторого класса, то можно обойтись простым набором функций. Вот пример (из темы http://forum.vingrad.ru/index.php?showtopic=67535):

Код

$this->lib->to_by_id    = $post['author_id'];                         $this->lib->from_member = $this->ipsclass->member;                         $this->lib->msg_title   = '';                         $this->lib->msg_post    = "";                         $this->lib->force_pm    = 1;                          $this->lib->send_pm();

Какие преимущества дает этот класс перед простой функцией?

Код

function send_pm (to_id, subject, body, ...){ . . . }

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

Помогите просто увидеть преимущества...

Заранее спасибо за внимание

Цитата(Bastet @ 19.11.2005, 16:17)

Какие преимущества дает этот класс перед простой функцией?

В данном случае с данной функцией (если она одна), преимуществ я не вижу никаких..., но:

Цитата(Bastet @ 19.11.2005, 16:17)

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

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

-=Ustas=-, про все преимущества ООП вообще я знаю (за то и люблю). Мне интересно именно в контексте РНР.

А если бы в примере была не одна функция? Чем лучше модуля, инкапсулирующего все функции из этого класса?

Цитата(Bastet @ 19.11.2005, 16:36)

Мне интересно именно в контексте РНР.

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

Цитата(Bastet @ 19.11.2005, 16:36)

А если бы в примере была не одна функция? Чем лучше модуля, инкапсулирующего все функции из этого класса?

Опять же скажу - структура, и возможно, меньшее количество переменных..., хотя...ИМХО

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

Или я недопонимаю сути программирования на РНР, или просто туплю...

В ПХП ОО модель носит информационный характер по сути, т.е. это фактически лишь для удобства разработки.
Плюсы, которыми обладает ООП в Делфи к ПХП в большинстве не применимы. Дело не только в коде и его стилистике, а в целом в подходе к решению задач.

http://vingrad.ru/PHP-ART-002848 - вот тут я в самом начале изложил, так сказать эти вещи.


Bastet не сравнивай ООП в Делфи и ПХП. Сам на Делфи пишу. Это совершенно разные вещи. В Делфи это полноценная теория проектирования и реализации проекта, в ПХП - способ реализации, сама понимаешь, это совершенно разные вещи.

Mal Hack, короче, единственный выигрыш - более структурированный код?
Ясссно....

Цитата(Bastet @ 20.11.2005, 17:28)

Mal Hack, короче, единственный выигрыш - более структурированный код?

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

имеет смысл расмотреть еще и время разработки, доработки, и расширения PHP программы.

Почему же?
Еще можно использовать в качестве единного интерфейса для разных БД например.

Neitron, поподробнее про единый интерфейс к разным БД можно?

Цитата(Bastet @ 30.11.2005, 19:21)

Neitron, поподробнее про единый интерфейс к разным БД можно?

Уровень абстракции от СУБД по просту говря. Хотя в общем не важно СУБД это или нет. Такую абстракцию можно сделать под любого рода сходные источники данных, но реализованные несколько различными интерфейсами. В итоге получится единый интерфейс работы, независимо от используемого источника данных, т.е. приведу примитивный псевдокод:

Код

$db = new db('oracle', 'localhost', 'login', 'pass'); $db->connect(); $db->query('SELECT bla_bla FROM bla_bla_bla'); while ($row = $db->fetch())   echo $row['bla_bla']; $db->disconnect();

Вот благодяря этому единому интерфейсу общения можно аналогичную операцию провести хоть с MySQL, хоть с InterBase хоть еще с чем угодно, при соблюдении стандартов SQL разумеется.
Добавлено @ 19:08

Цитата

...а где наоборот ущемлен (как это является в ПХП).

Про ООП возможности PHP 5 я бы так не сказал...

У меня в проекте 4 типа, ээээ,  я их абстрактно нарек "контентом".
Соответственно у меня 5 классов: абстрактный "контент", и от него наследованы 4 ребенка, для которых общие методы (такие как изменение рейтинга и манипуляция комментами) вынесены в родительский класс. Скажете мелочи? Отнюдь: на добавление/удаление комментов работает один триггер, а не 4. Внешних ключей и таблиц отношений (скажем, у каждого контента есть список жанров, много ко многим, в отдельной таблице) не 4 а одна на все. 
Манипуляции с контентом во многом одинаковы. Что бы ООП начало приносить пользу, нужно научится анализировать и абстрагироваться.
Если нужно манипулировать одним типом контента, то ООП может пригодится в качестве обертки. Простой класс-обертка с понятными именами методов, инкапсулирующих в себе логику. Вот на вскидку уже 2 преимущества.


Лично я убедился в том, что это лишнее. Трудно представить себе проект, который хотят перенести с MySQL на Oracle, например. А соблюдение стандартов SQL надоест очень скоро. В каждой СУБД имеются свои "изюминки", и в рамках стандарта далеко не все получится реализовать. Самый простой пример для этого: попробуйте используя массивы в Postgre перенести скрипты на MySQL.

Bastet, заметь - большинство доводов сводится к "а зато у нас песни хорошие!". Удобство разработки, повторное использование. Это все хорошо, но к сути ООП отношение имеет слабое. Самым убойным из этих аргументов является  применение ООП для эмуляции пространства имен. И такое бывало.
Про суть программ на пхп отлично сформулировано. Линейная, по сути, структура. Плюс время жизни. Можно, конечно, "наструктурировать" себе красивого кода... но, как кто-то метко сравнил в свое время, "была бы виндоус такой, как сейчас, если после каждого клика ей приходилось бы перезагружаться?"
Сюда же - наши реляционные базы. Которые, чтобы отмапить объектно, надо быть очень большим энтузиастом.

Судя по всему, действительно, написать полноценную программу на ООП в пхп занятие не слишком осмысленное. Остается использовать отдельные классы, которые хорошо вписываются в идеологию. Как написал последний оратор - классы, реализующие основные операции в пхп. Это работа с хранилищем данных, вывод. 
В большинстве же случаев ООП в пхп сводится исключительно к внешним признакам, которые ты, опять же, отлично показала в своем примере.

<Spawn>, а можешь привести не примитивный псевдокод, а реальный пример? Вопрос риторический. 

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

Это сообщение отредактировал(а) Feldmarschall - 19.8.2008, 17:16

Для меня приемущество ООП в PHP в первую очередь удобство  и быстрота разработки, проектирования и расширения системы, но это уже больше ООА который уже в свою очередь использует ООП.

Собственно для удобства разработчика обектно-ориентированый подход и вводился в свое время. Просто человек устроен сам по себе так что мыслит именно оъектами,ю а не функциями.

Коллеги, обратите внимание на дату поста, предшествующего "своевременному" посту топик-реаниматора...

Эх. Надо ж было так облажаться.
Но тема все равно актуальная.

Это называется инкапсуляция, и является одним из преимуществ ООП.

Я не писал про классы, реализующие основные операции в PHP, я писал про классы, работающие с объектами, абстрагированно, не зная что это за объект, но зная, что он обладает всеми свойствами "контента". Процетированная фраза говорит о тех же классах-обертках.

Ну, уж далеко не каждый человек. ООП сродни некоторому исскуству, как по мне. 
Как в математике: найти производную каждого можно научить, а вот найти интеграл...
Что бы правильно использовать ООП надо уметь думать, анализировать.

02077461 - Могильщик   
Но все же как было подмечено тема актуальна ...

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

Сейчас на рисовался проект, с связи с двумя факторами:
 Писать будут 2 человека. 
 В будущем функционал будет расширятся !

 
Было принято решение писать на ООП, потому что:
 Я считаю проще будет распределить обязанности за написания отдельных участков кода. Также  проще будет объединить наши участки кода.
 Проще будет расширить возможности, т.е. более гибкая к изменениям система(При условии что мы "правильно" спроектируем систему).
 
Только в этом я вижу преимущество ООП перед процедурным. 

Хотелось бы услышать мысли тех кто использует ООП, и какие преимущества Вы видите в ООП ?

Это бестолку объяснять, это понять нужно.  Какие преимущества у авиалайнера перед бумажным самолётиком?

P.S. PHP вообще как язык не очень, а уж объектно-ориентированным его называть вообще смешно, однако и в нём можно ООП применять вопреки языку.

Никаких, каждый из них предназначен для разных функций. 

Тема сегодня — Объектно-ориентированный PHP (плюсы и минусы приминения ООП), разъясните,
пожалуйста, вашу позицию по этому вопросу!

Преимущеста ООП в PHP такие же как и в ООП в С++, Делфи, Java ... правильно сказал source777, 

ООП предоставляет кучу возможностей:
1. Структуированное проектирование проекта
2. Наследование классов дает такой скачок в скорости разработки, если кто-то не использует это, значит не знает как использовать.
3. Легкая доработка, очень легкое обнаружение багов, все как в огромном механизме, там поменял шпунтик, тут заменил часть механизма, а логика то вся одна, а реализация может меняться.


Вот мое сравнение процедурной парадигмы и ООП..


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

lukas, правильно подмечено это как в машиностроение из одних и техже компонентов можно собрать как трактор так и грузовик, а потом взять и собрать из этого вертолет

Это сообщение отредактировал(а) krundetz - 20.8.2008, 21:34

я начал только постягать азы.. Не вижу никакого отличия по сравнению с использованием отдельных функций пока. НО(!) В ZendStudio я меньше трачу времени печатая код, т.к. все переменные и функции классов у меня "под рукой"  
Универсальных классов я пока не встречал, для каждого проекта они все разные. Му может только исключение составляет работа с базой и почтой 

А начал писать скорее по тому, что все "продвинутые" так делают в надежде что в будущем осознаю приемущество ;)

Gold Dragon, класс тем универсальнее чем меньше функциональности в нем реализовано. В большинстве случаев такие классы наследуются и их функционал значительно расширяется.

Допусти у меня есть 2 класса которые отрисовывают на экране свое содержимое. Но у меня такая ситуация это содержимое может формироваться совершенно разным образом что делать? А делать следующие взять и выделить ту часть которая отвечает за отрисовку в одельный класс а ту что отвечает за формирование оставить в этих и унаследовать новый класс обоими классами. В итоге получаем два не универсальных класса и один универсальный который может использоваться и в других ситуациях. В общем посмотрите в сторону такого понятия как рефакторинг и обекто-ориентированое проектирование.

Если вы мне покажите хоть один трактор с турбовинтовым двигателем и винтом, а также аэродинамичны корпусом, а еще покажите вертолет с колесами диаметром метр-полтора, я с вами соглашусь...  про автоматику я вообще молчу..

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

Это сообщение отредактировал(а) krundetz - 22.8.2008, 08:42

Mal Hack, krundetz, может вам на тракторномоторный форум?   


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

Движо вертолета в корне отличается от движка танка )


Ну мы же развиваем винград в разных направлениях  Автофорум вон есть, так что все впереди ))

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

Что касается ООП, я уже тут не в одной теме озвучивал свою позицию. ООП как проектирование - к языку вообще мало имеет отношение, оно лишь учитывает некоторые возможности языка, не более того. ООП как программирование с точки зрения ПХП - абсурд, т.к. ПХП как был структурированным языком, так им и остался, ООП в пхп носит лишь информационную модель, в которой нет событийности, за исключением __call, __get, __construct, __destruct и trigger_errors, ну может еще небольшой части. В ПХП ООП - просто синтаксически дает синтаксис ООП, а следовательно более простую реализацию приложения, спроектированного по принцыпам ООПроектирования, чем при полностью структурном описании. Хотя, конечно, зависит от задачи.

Самый просто пример. Покажите, где у вас объекты в ПХП. Модули? А вы уверены что они у вас именно живут как объекты, а не просто как синтаксически стилизованный набор функций? В ПХП объекты, как объекты - не живут..

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

А при чем тут языки. Это технология, она единая.

технология одинаковая (или почти) а вот терминология у нас разная..

и кажется  мне что и представления и понимание у нас разные хотя во многом может и схожи...

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

P.S. ООП это не мода, как думают все... Я сам начинал не с PHP, и применял в других языках ООП на ура... там без него было некуда.... 

Это сообщение отредактировал(а) lukas - 22.8.2008, 18:29

lukas, совершено верно

Это сообщение отредактировал(а) krundetz - 22.8.2008, 19:24

Здесь речь как раз идет про ООП в php (как видно по названии топика), а не о использовании этой технологии в других языках...

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

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

Я не спорю, там где нужны функции нужно писать функции а не классы... 

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

столько же, сколько и аргумент про "единый интерфейс к разным БД".
это одного рода доводы - из мечтательной области "а как хорошо в теории могло бы быть..." =)

skyboy, это уже вопрос криворукости программиста...   и с функциональным программированием можно такое намудрить... 

lukas, соотвественно, вопрос расширяемости и внятности структуры - зависит от структуры, а не от объектной (не)ориентированности кода. не согласен?

Стандартный пукть новичка.
1. Начал писать 
2. прочитал что ООП это круто 
3. начал пытатся писать в ООП стиле 
4. набрался опыта и понял что в п.1. он писоал [censored34! Пожалуйста, соблюдайте элементарные правила приличия при общении на форуме]
5. решил что все это благодаря ООП

Качественный код можно писть в любом случае (ровно как и не качественный).

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

Учитесь ДУМАТЬ, а не слепо верить какой-то парадигме.

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

ога. в РНР активно используется протитопное программирование... а я вот сижу и усиленно путаю классы и ООП   

Причём тут PHP? ООП от языка не зависит, и уж тем более не достаточно написать слово class, чтобы твоя программа стала объектно-ориентированной...

Это Вы проходили на собственной "шкуре" ?
Или же это  со стороны  ?

skyboy, прототипное было скорее всего в 4ой версии, если вы конешно понимаете что такое "прототипное"...

И причем тут вариант реализации ООП ??? Их не так уж много и они довольно похожи...



Вы опять меня не понимаете, ...   ... как смешно читать как люди применяют ООП, если учесть что статистический вызов для любых методов будет исключен в PHP6, Я же использую ООП для того чтобы не писать одно и тоже по несколько раз, применяю НАСЛЕДОВАНИЕ и в результате наращиваю весь функционал...

P.S. И причем тут вера в парадигму, когда с помощью ООП мое затрчиваемое время сильно уменьшается, а главное появляется упорядоченность в коде.

Как своевременно апнули тему, к моему возвращению на форум. За три (*ужас*) года я много чего надумала и теперь практикую в РНР чистый ОО-подход. Почему:

•  РНР5, ура-ура, теперь достаточно хорошо реализует ООП
•  Объектная модель проектируется в UML, там же снабжается комментариями и никакой документации больше фактически не нужно. Все очень наглядно и легко вспоминается много времени спустя
•  Если не полная универсальность, то очень хорошая возможность повторного использования кода при минимуме работы
•  Задалась амбициозной целью реализовать движок сайта, который можно будет собирать из модулей как конструктор Лего. Только в ООП это возможно
•  Просто "хороший стиль" и дополнительная практика в ОО проектировании - но это дело вкуса

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

Bastet, поздравляю с  самостоятельным осознанием преимуществ ООП  

Ты уверена, что для не сложных проектов нужно именно функциональное программирование?    

Это сообщение отредактировал(а) source777 - 23.8.2008, 21:20

Не "нужно", досточно.
Эм... а ссылка - это к чему? Я что-то напутала в определении?  Назовем его тогда функциональным подходом, что ли...

конечно, нет. не понимаю. вот source777 меня просветил, что я, оказывается, зря говою о PHP в разделе "PHP: Общие вопросы" в теме "Объектно-ориентированный РНР". от Вас я с удовольствием выслушаю оцеку собственных познаний прототипного подхода. 
кстати говоря, учиывая, что прототипный подход подразумевает требования:
1. возможность полного клонирования объекта.
2. возможность модификации не только данных объекта, но и методов.
нет, конечно, я и не думал читать лекцию. просто напомнил. 
необходимые механизмы реализованы в claskit, потому писать в протипно-ориентированном стиле можно под любой версией, под которой работает classkit. потому меня удивляет фраза про 4 версию, в которой "протипное программирование было скорее всего". неужто в 5-ке я не смогу динамически добавлять/удалять методы? или клониорвание объекта стало реализовываться в 5-й версии хуже(ввели магический метод __clone, позволяющий реализовать любую логику клонирования).

Добавлено через 2 минуты и 12 секунд
Bastet, все в порядке. source777 слишком рьяно относится к терминологии. просот функциональным программированием обычно называют немного другое. структура программы, когда обработка производится при помощи функций/процедур называется "процедурным программированием". но это придирки, я думаю 

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

Это сообщение отредактировал(а) lukas - 23.8.2008, 21:39

откуда такая информация? все, что я нашел: что не-статические методы нельзя будет вызывать, как статтические - только для созданного объекта можно будет. но отказываться от статических членов не вижу смысла и не обнаружил про такое никакой информации. поделись источником, будь добр.

skyboy, Вся суть прототипного ООП сводится к тому что классов нет, а есть только ОБъекты, которые можно клонировать... остальное уже расширение языка... 



Я еще когда писал про это, подумал а как лучше написать процедурное или функциональное,...  

 Тема скорее всё-таки о применении ООП в PHP, а не об объектно-ориентированном РНР. Если тебе всё же хочется исходить из названия темы, то PHP не является объектно-ориентированным и никогда таким не станет, а если станет, то это уже будет не PHP (аналогично переходу от VisualBasic к VisualBasic.NET, название осталось, объектная ориентация появилась, а от языка только синтаксис остался, да и то частично), т.к. определяющую парадигму невозможно навесить на что-то уже существующее, даже такие языки как С++ и Delphi не сумели реализовать встроенную поддержку ООП в полной мере, куда уж тут PHP...

Если нужен объектно-ориентированный язык для веб-разработки, то советую обратить внимание на Ruby.

Добавлено через 7 минут и 29 секунд

да, лучше называть этот подход процедурным, или на крайний случай структурным, а функциональный подход обычно применяется для решения математических задач, либо для задач, требующих высокую степень надёжности кода.

без возможности динамического управления методами у тебя будет не прототипно-ориентированное программирование, а тупо один объект, данные которого ты сможешь переопределить, а вот поведение - нет. простое клонирование объектов - не более, чем клонирование. так что это не "расширение языка", а необходимое условие для реализации прототипов.
ты мне так, незнающему, и не сообщил, чем же 4-я версии "более склонна" к прототипно-ориентированному программированию.
также, почему то, ничего не говоришь про "отказ от статических методов" в 6-й версии. заинтриговал и молчишь.

такое есть уже с пятой версии. только, возможно, не в таком виде, как можно было привыкнуть в десктопном программировании: для объекта существует только один getter: магический метод с именем __get, и только один setter - магический метод с именем __set, в качестве параметров которым передается и имя свойства, к которому прогаммист желает получить доступ. а благодаря магическому методу __call можно сделать getter даже для методов объекта.

Добавлено @ 23:03

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

есть такое понятие: "мультипарадигменнось"

не знаю, зачем языку с динамической типизацией переменных виртуальные методы. по сути - тут все методы "виртуальные" в том отношении, что как ты объект создал, метод соответствующего класса будет использоваться. а не метод предка, который надо вызывать явно. 
виртуальные методы используются ведь для полиморфизма, когда в переменная типа класса-предка ссылается на объект класса-потомка и надо работать с методами класса-потомка. в PHP так и будет в любом случае.
[Updated]

мне чаю хочется. а вот твое "при чем тут PHP к ООП?", когда тема с таким названием находится в разделе "РНР" меня удивило своей неожиданностью

Это сообщение отредактировал(а) skyboy - 23.8.2008, 23:04

lukas, read и white - это да, сама немного сокрушалась по этому поводу.

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

Мне еще очень хотелось бы модификатор доступа friendly и возможность формировать пакета... *для красоты*

Похоже моего поста тут никто не увидел, а жаль. Процитирую:


Ваша ошибка в том, что вы смотрите на ООП, как на реализацию, мол вот в Сях есть дружественные функции, а в ПХП нет и т.п. Нельзя так. ООПрограммирование - это концепция, а не реализация!!!

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

Виртуальные методы, дружественные функции, это лишь надстройка над реализацией объектной модели, даже той, которая есть в С++, например. Не они определяют тот факт, что вы используйте ООПрограммирование, а наличие объектов, которые живут, как объекты, которые на что-то реагируют, что-то сами иногда делают. в ПХП этого - нет. Есть объектный синтаксис, который позволяет структурировать код, ну и в некоторых отдельных случаях организовать "примитивную псевдо событийность"...

Еще раз повторюсь: Покажите, где у вас объекты в ПХП. Модули? А вы уверены что они у вас именно живут как объекты, а не просто как синтаксически стилизованный набор функций? В ПХП объекты, как объекты - не живут.. 

Mal Hack, 

мы обсуждаем не как реализованно Объектная модель в ПХП (это вообще дело разработчиков PHP), а какие преимущество его использования... Если уж пойти дальше то можно прийти к тому что все равно это все mov,add, всякие прерывания ASM-лера... 


Bastet, абстрактные методы меня не устраивают...

например у меня функция A используется в Функции B объекта Obj1, я создаю унаследованный класс Obj2 от Obj1, в нем переопределяю функцию A (т.е. уже функционал другой) и мне нужно чтобы в B вызывалась уже именно переопределенная функция, а не родителя... 

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



Вот про это я говорил.

Интересно, а в разделах по JavaScript-у, наверное, рассказывают про "мощь" прототипного программирования, в lisp про "мощь" функционального, а в С про "мощь" процедурного?  

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

Приведите конкретную задачу и только тогда можно будет сказать насколько удачно можно будет применить к ней ОО подход.


Правильнее будет сказать:
1. PHP изначально не являлся ОО языком.
2. На данный момент в PHP ООП реализован в не достаточной степени.


Это применимо и к PHP, только в отличии от VB это происходит в несколько этапов и  нету таких четких границ.


Будет в PHP 5.3 http://wiki.php.net/todo/php53



Вы правы. В PHP все не приватные методы по сути являются виртуальными. Т.ч. полиморфизм реализуется в полное мере.

Определяете функцию B protected и вызываться будет именно дочерняя функция.


Хе хе. Любые конструкции в высокоуровневых языках - это и есть по сути, как вы сказали "синтаксически стилизованный набор функций"   


А как они "живут", как набор инструкций может быть?   


Тут совершенно согласен. А название темы вообще странное...


Тут ноги растут из типизированости в PHP (точнее ее отсутствие).
Ведь что такое событийность? Событийность это всего-лишь массив делегатов, и не более того!

Делегаты в PHP есть? Есть - это тоже самое что и строка. Ну напишите перед ней /* @var Delegate $delegate */ вот вам и делегат.
Асоциативные массивы в PHP? Можно не отвечать.
Подписка/отписка на/от события = добавление/удаление делегата в/из массив.
Вызов события = поочередный вызов делегатов массива.
Все! Вот вам и событийность и не нужны никакие __call.

А если еще учесть, что в PHP 5.3:

То можно использовать событийность практически так же как в C#

Возьмите кнопочку... Тут уже благодаря системным вызовам и прерываниям - не просто синтаксически стиллизованный код. Но по сути, конечно, есть такая тема. Другое дело, что в ПХП это именно стилизованный синтаксис 100%.


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


Типизация тут не при чем. Событийность - реакции на определенные сигналы, поступающие от туда или отсюда. Делегаты - термин по крайней мере не из С++, хотя может и из МФЦ, но я с ним не работал. И потом, Делегат - функция (если я ничего не путаю), т.е. более высокий уровень абстракции.


Хорошо, есть объект А и Б, с методом А1 и Б1. При срабатыавании Б1 должен автоматически вызваться А1. Б о А ничего не знает. Также, как и А о Б.


Ничего не могу сказать на эту тему, не смотрел еще этих вещей...

Круто, не знал...   

Ага, всего что не хватает щас в PHP5.X будет в PHP5.3

Это сообщение отредактировал(а) lukas - 25.8.2008, 21:25

По поводу кнопочек, специфика HTTP протокола такая, что события типа onClick в server-side скрипте просто не уместны в данном контексте, т.к. они происходят на стороне клиента.
Возьмем, к примеру, ASP.NET. В C# ведь используется событийность? Однако что происходит при создании события onClick на кнопку? - Генерируется куча джаваскрипта и куча кода в на C# - вот тебе и вся событийность... по сути всего-лишь фитча IDE. Так чем же PHP в этом плане хуже? 


Т.е. по твоему, если объект абстрагирован от системных вызовов - то это уже в понимании ООП и не объект вовсе? В таком случае C# так же не ОО язык, т.к. тоже не работает непосредственно с системными вызовами.


Отсутствие типизации виновато в том, что складывается впечатление о не возможности использования событий в PHP. Хотя да, типизация это не самая большая проблема. Все-таки на первом месте идет многопоточность.


А что такое реакция на сигнал? Это вызов определенной функции при изменении состояния некоторого объекта. 


Почти. Делегат - это указатель на функцию. Насколько я понимаю, в C++ это так и называется?


Как это не знает? А сначала должен подписать на событие А1, прежде чем Б сможет его автоматически вызвать. Т.е. по сути передать А должен передать делегат функции A1 объекту Б. Тогда при срабатывании Б1 просто будут вызваны все делегаты которые ранее были переданы объекту.

sTa1kEr, давай сиходить из того, событийность должна реализовываться не программистом, а языком.  
В ПХП этого нет. Вот я о чем. Реализовать событийность самому - можно, а вот сделать что-то вроде:
connect(A, A1(), B, B1()) - нельзя. На счет 5.3 я не говорю - не знаю. Т.е. объекты А и Б не знают о сущестовании друг друга, об этом знает программа, которая связывает сигнал со слотом.


Типизация и событийность - совершенно разные вещи, они тут не при чем (в совокупности).


Так вот и покажите мне в ПХП - объект, который будет себя вести КАК кнопочка. Т.е. его событийность будет реализована средствами ПХП, а не программиста (реализация самих событий - конечно за программистом).


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

Такого объекта нет ни в PHP, ни в одном другом server-side языке, т.к. такое не возможно. В качестве наглядного примера я выше привел ASP.NET - там все тоже самое, с одной разницей, реализацией события занимается не программист, а IDE. В принципе Zend может сделать тоже самое и для PHP.


Хорошо, в таком случае весь вопрос в том, что в PHP нет такой конструкции event (по сути просто пары встроенных классов)? Да этого в PHP нет и хоть это не сложно реализовать в PHP, скорее всего этого не будет до тех пор, пока в этом нет надобности (а особой надобности в этом, имхо, не будет пока нет полноценной многопоточности). Однако это не мешает использовать событийность и ОО подход.

Ну дык и я про тоже. Такова специфика ПХП...
Среда это среда. А я говорю, ну как бы про транслятор чтоли, в совокупностью с системой. Сейчас могу не корректно выражать мысли, ибо голова забита несколько другими вопросами.


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


В языке этого нет. Реализовать может только сам программист. Вот в чем суть, я как раз-таки имею ввиду то, что именно в языке этого механизма нет.


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

Многопоточность тут тоже не при чем. В ПХП это не так актуально, а если надо, есть средства ее реализовать руками. А сигнал/слот может и в одном потоке работать.


Подход, тобишь ООПроектироание - да. Событийность - опять-таки, какую? Встроенное в ядро - нет, реализованное ручками - да, но это уже не совсем то.

Это сообщение отредактировал(а) Mal Hack - 25.8.2008, 23:34

Я имел ввиду не сложно реализовать в самом языке этот механизм. И разработчики PHP вполне могли бы это сделать и в PHP 5.3, и тем более в PHP 6, но не делают, как я думаю, по описанным мной выше причинам. 


Это специфика не PHP, а HTTP протокола.


Еще как причем. Если в крации, то реализовать ОО модель в PHP на уровне .NET-а мешают, на мой взгляд, именно эти две вещи: многопоточность, не строгая типизация.

Mal Hack, PHP это высокоуровневый язык, ты же рассуждаешь с позиции низкоуровнего C++.

По каким причинам? наверное я пропустил просто...
ты не подумай, что я придираюсь, просто реально я их либо в упор не вижу, приведи еще разок


Давай так. Отбросим кнопочки. Мы про событийность внутри самого ПХП, т.е. в скрипте. Тут HTTPне при чем. Тут специфика структурного, интерпретируемого языка программирования, как Perl, например.


Пример однопоточного выполнения (чисто на пальцах, суть, которую хочу показать). 

Зачем тут многопоточность? есть сигнал - выполнилась функция, по другому:

Да, для Визуалки испольузется многопоточность, но по сути, сам механизм сигнал/слот не обязательно должен быть в другом потоке.


А при чем тут типизация? То, что это минус ПХП и т.д. - отложим, не в этом суть темы, чем  она мешает событийности? Скажем так, да жесткая типизация позволилабы прописывать объекты и т.п. в этом ты имеешь ввиду?


Ну что такое низкий и высокий уровень я бы еще поспорил. Это условность всетаки. И потом, В C++ той событийности, о которой я говорю нет, ее дает Qt, например. Это уже более высокий уровень, все-таки.

По тем причинам, что в этом практически нет потребности. Для кнопок этого не сделать, а отсутствие многопоточности не позволит создать сколько-нибудь приемлемое серверное приложение. Остаются только простейшие события вроде onRowDeleted, onPageRender итд - это просто реализуется и как-то не в стиле PHP что-ли... В общем не стоит овчинка выделки на данные момент, то что вместо /* @var event */ можно будет написать просто event, кроме большей наглядности ничего не даст. Разве что "для галочки" реализовать.


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

Наглядный пример http://php.net/socket-select - вот как приходится извращатся, что бы избежать fork-ов! И это еще цветочки! Естественно, про реализацию event patern-а я вообще молчу... 

Строгая типизация естественно тоже сама по себе ни причем. Но она во первых - так же сковывает развитие PHP (тут можно долго перечислять проблемы из-за отсутствия типизации, но это уже к оффтоп). Во вторых - она (точнее ее отсутствие) вводит в заблуждение, раз в PHP нету типа Delegete - значит в PHP нету делегатов, анонимных делегатов... раз нету ключевого слова event, значит нельзя использовать событийность, и все в таком духе. Хотя на самом деле все это есть, пусть и называется строкой... Будь строгая типизация - ничего бы такого не было.
Кстати, еще пример - SplTypes. Eще больше двух лет назад был уже реализован тип Enum (это из C#) + реализованы попытки совместить строгую и не строгую типизацию... И ведь даже работает, только вот не нужно никому.



Я не знаю что это за функция, но насколько я предполагаю это и есть подписка на событие? И в чем проблема тоже самое сделать в PHP?
Опять же пример из C#, взять подписку на событие и пройтись рефлектором. И что мы увидим? Да всеголишь вызов метода add_Listener() у обычного, ничем не отличающегося от других класса Event ! Т.е. по сути событие это класс в из 3 методов (addListener, removeListener и fire) и одного свойства - коллекции делегатов (читай массив указателей на функции). 

Твой пример портированный на C#


А вот как бы это могло выглядеть в PHP


А вот как это уже сейчас можно использовать


Найди 3 отличия   

Это сообщение отредактировал(а) sTa1kEr - 26.8.2008, 14:46