Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > PHP: Для профи > Объектно-ориентированный PHP

Автор: Bastet 19.11.2005, 16:17

Сразу скажу, что с принципами ООП я знакома, ценю и применяю в 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, ...){ . . . } Я понимаю, что не напрасно люди применяют в программирование на РНР объектный подход. Но смысл пока ускользает... Помогите просто увидеть преимущества... Заранее спасибо за внимание

Автор: -=Ustas=- 19.11.2005, 16:32

Цитата(Bastet @ 19.11.2005, 16:17) Какие преимущества дает этот класс перед простой функцией? В данном случае с данной функцией (если она одна), преимуществ я не вижу никаких..., но: Цитата(Bastet @ 19.11.2005, 16:17) Я понимаю, что не напрасно люди применяют в программирование на РНР объектный подход. Но смысл пока ускользает... если брать в общем, то ООП подход, не важно в какой среде, он помогает создавать более структурированные программы, более читабельные и + экономия символов на коде , но это ИМХО, а также наследование... и т.д. Это я так думаю...

Автор: Bastet 19.11.2005, 16:36

-=Ustas=-, про все преимущества ООП вообще я знаю (за то и люблю). Мне интересно именно в контексте РНР. А если бы в примере была не одна функция? Чем лучше модуля, инкапсулирующего все функции из этого класса?

Автор: -=Ustas=- 19.11.2005, 16:42

Цитата(Bastet @ 19.11.2005, 16:36) Мне интересно именно в контексте РНР. Bastet, разницы нет никакой в каком языке используется этот подход, разница лишь в том, что в где то он хорошо развит, а где наоборот ущемлен (как это является в ПХП). Цитата(Bastet @ 19.11.2005, 16:36) А если бы в примере была не одна функция? Чем лучше модуля, инкапсулирующего все функции из этого класса? Опять же скажу - структура, и возможно, меньшее количество переменных..., хотя...ИМХО

Автор: Bastet 19.11.2005, 17:40

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

Автор: Mal Hack 19.11.2005, 22:19

В ПХП ОО модель носит информационный характер по сути, т.е. это фактически лишь для удобства разработки. Плюсы, которыми обладает ООП в Делфи к ПХП в большинстве не применимы. Дело не только в коде и его стилистике, а в целом в подходе к решению задач. http://vingrad.ru/PHP-ART-002848 - вот тут я в самом начале изложил, так сказать эти вещи. Bastet не сравнивай ООП в Делфи и ПХП. Сам на Делфи пишу. Это совершенно разные вещи. В Делфи это полноценная теория проектирования и реализации проекта, в ПХП - способ реализации, сама понимаешь, это совершенно разные вещи.

Автор: Bastet 20.11.2005, 17:28

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

Автор: Mal Hack 20.11.2005, 17:43

Цитата(Bastet @ 20.11.2005, 17:28) Mal Hack, короче, единственный выигрыш - более структурированный код? Плюс в производительности в определенных ситуациях, но это редко и не всегда на очень много.

Автор: Vaulter 28.11.2005, 13:07

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

Автор: Neitron 30.11.2005, 15:53

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

Автор: Bastet 30.11.2005, 17:21

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

Автор: <Spawn> 30.11.2005, 19:06

Цитата(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 я бы так не сказал...

Автор: 02077461 19.8.2008, 16:22

У меня в проекте 4 типа, ээээ,  я их абстрактно нарек "контентом". Соответственно у меня 5 классов: абстрактный "контент", и от него наследованы 4 ребенка, для которых общие методы (такие как изменение рейтинга и манипуляция комментами) вынесены в родительский класс. Скажете мелочи? Отнюдь: на добавление/удаление комментов работает один триггер, а не 4. Внешних ключей и таблиц отношений (скажем, у каждого контента есть список жанров, много ко многим, в отдельной таблице) не 4 а одна на все.  Манипуляции с контентом во многом одинаковы. Что бы ООП начало приносить пользу, нужно научится анализировать и абстрагироваться. Если нужно манипулировать одним типом контента, то ООП может пригодится в качестве обертки. Простой класс-обертка с понятными именами методов, инкапсулирующих в себе логику. Вот на вскидку уже 2 преимущества. Цитата(<Spawn> @  30.11.2005,  19:06 ) Вот благодяря этому единому интерфейсу общения можно аналогичную операцию провести хоть с MySQL, хоть с InterBase хоть еще с чем угодно, при соблюдении стандартов SQL  Лично я убедился в том, что это лишнее. Трудно представить себе проект, который хотят перенести с MySQL на Oracle, например. А соблюдение стандартов SQL надоест очень скоро. В каждой СУБД имеются свои "изюминки", и в рамках стандарта далеко не все получится реализовать. Самый простой пример для этого: попробуйте используя массивы в Postgre перенести скрипты на MySQL.

Автор: Feldmarschall 19.8.2008, 16:58

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

Автор: krundetz 19.8.2008, 17:17

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

Автор: Mal Hack 19.8.2008, 17:30

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

Автор: Feldmarschall 19.8.2008, 17:31

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

Автор: 02077461 19.8.2008, 17:49

Цитата(Feldmarschall @  19.8.2008,  16:58 ) Но та же работа базой, которую, с одной стороны, хорошо бы упаковать в класс с кучей свойств и методов, все равно сводится только к одному объекту. И ничем, по сути, не отличается от работы кучи разрозненных функций. Это называется инкапсуляция, и является одним из преимуществ ООП. Цитата(Feldmarschall @  19.8.2008,  16:58 ) Как написал последний оратор - классы, реализующие основные операции в пхп Я не писал про классы, реализующие основные операции в PHP, я писал про классы, работающие с объектами, абстрагированно, не зная что это за объект, но зная, что он обладает всеми свойствами "контента". Процетированная фраза говорит о тех же классах-обертках. Цитата(krundetz @  19.8.2008,  17:17 ) Просто человек устроен сам по себе так что мыслит именно оъектами,ю а не функциями.  Ну, уж далеко не каждый человек. ООП сродни некоторому исскуству, как по мне.  Как в математике: найти производную каждого можно научить, а вот найти интеграл... Что бы правильно использовать ООП надо уметь думать, анализировать.

Автор: bobik02 19.8.2008, 20:01

02077461 - Могильщик    Но все же как было подмечено тема актуальна ... До этого писал на процедурном (и пишу), так как в том что нужно было писать, не нужна была  ОО парадигма.  Хотя основы еще тогда из книжек "знал", но как говориться не "пощупал ручками".  Сейчас на рисовался проект, с связи с двумя факторами:  Писать будут 2 человека.   В будущем функционал будет расширятся !   Было принято решение писать на ООП, потому что:  Я считаю проще будет распределить обязанности за написания отдельных участков кода. Также  проще будет объединить наши участки кода.  Проще будет расширить возможности, т.е. более гибкая к изменениям система(При условии что мы "правильно" спроектируем систему).   Только в этом я вижу преимущество ООП перед процедурным.  Хотелось бы услышать мысли тех кто использует ООП, и какие преимущества Вы видите в ООП ?

Автор: source777 19.8.2008, 20:41

Цитата(bobik02 @  19.8.2008,  20:01 ) какие преимущества Вы видите в ООП ? Это бестолку объяснять, это понять нужно.  Какие преимущества у авиалайнера перед бумажным самолётиком? P.S. PHP вообще как язык не очень, а уж объектно-ориентированным его называть вообще смешно, однако и в нём можно ООП применять вопреки языку.

Автор: bobik02 19.8.2008, 21:04

Цитата(source777 @  19.8.2008,  20:41 ) Это бестолку объяснять, это понять нужно.  Какие преимущества у авиалайнера перед бумажным самолётиком? Никаких, каждый из них предназначен для разных функций.  Тема сегодня — Объектно-ориентированный PHP (плюсы и минусы приминения ООП), разъясните, пожалуйста, вашу позицию по этому вопросу!

Автор: lukas 20.8.2008, 19:29

Преимущеста ООП в PHP такие же как и в ООП в С++, Делфи, Java ... правильно сказал source777,  ООП предоставляет кучу возможностей: 1. Структуированное проектирование проекта 2. Наследование классов дает такой скачок в скорости разработки, если кто-то не использует это, значит не знает как использовать. 3. Легкая доработка, очень легкое обнаружение багов, все как в огромном механизме, там поменял шпунтик, тут заменил часть механизма, а логика то вся одна, а реализация может меняться. Вот мое сравнение процедурной парадигмы и ООП.. Процедурный язык - это все равно что разобранный конструктор, для изменения которого приходится постоянно разбирать и собирать всю модель, а ООП - это тот же конструктор, в котором достаточно заменить одну часть, без развинчивания всей модели.

Автор: krundetz 20.8.2008, 21:30

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

Автор: Gold Dragon 22.8.2008, 08:01

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

Автор: krundetz 22.8.2008, 08:22

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

Автор: Mal Hack 22.8.2008, 08:22

Цитата(krundetz @  20.8.2008,  22:30 ) lukas, правильно подмечено это как в машиностроение из одних и техже компонентов можно собрать как трактор так и грузовик, а потом взять и собрать из этого вертолет Если вы мне покажите хоть один трактор с турбовинтовым двигателем и винтом, а также аэродинамичны корпусом, а еще покажите вертолет с колесами диаметром метр-полтора, я с вами соглашусь...  про автоматику я вообще молчу..

Автор: krundetz 22.8.2008, 08:41

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

Автор: Gold Dragon 22.8.2008, 12:58

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

Автор: Mal Hack 22.8.2008, 13:14

Цитата(krundetz @  22.8.2008,  09:41 ) Или танк Т-80 который использует немного модернезированый движек от вертолета вроде ми-8 хотя конечно могу ошибаться.  Движо вертолета в корне отличается от движка танка ) Цитата(Gold Dragon @  22.8.2008,  13:58 ) Mal Hack, krundetz, может вам на тракторномоторный форум?  smile  Ну мы же развиваем винград в разных направлениях  Автофорум вон есть, так что все впереди )) krundetz, по поводу предыдущего поста и универсальности... Я не машиностроитель, а приборист и могу сказать, что универсальность - фигня полная. В технике, если и реализуется, то оооочень редко и на ооооочень небольших участках задач. Что касается ООП, я уже тут не в одной теме озвучивал свою позицию. ООП как проектирование - к языку вообще мало имеет отношение, оно лишь учитывает некоторые возможности языка, не более того. ООП как программирование с точки зрения ПХП - абсурд, т.к. ПХП как был структурированным языком, так им и остался, ООП в пхп носит лишь информационную модель, в которой нет событийности, за исключением __call, __get, __construct, __destruct и trigger_errors, ну может еще небольшой части. В ПХП ООП - просто синтаксически дает синтаксис ООП, а следовательно более простую реализацию приложения, спроектированного по принцыпам ООПроектирования, чем при полностью структурном описании. Хотя, конечно, зависит от задачи. Самый просто пример. Покажите, где у вас объекты в ПХП. Модули? А вы уверены что они у вас именно живут как объекты, а не просто как синтаксически стилизованный набор функций? В ПХП объекты, как объекты - не живут..

Автор: Gold Dragon 22.8.2008, 13:24

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

Автор: Mal Hack 22.8.2008, 13:35

Цитата(Gold Dragon @  22.8.2008,  14:24 ) каждый понимает под объектами и модулями своё  smile   А при чем тут языки. Это технология, она единая.

Автор: Gold Dragon 22.8.2008, 13:50

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

Автор: bobik02 22.8.2008, 14:23

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

Автор: lukas 22.8.2008, 18:28

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

Автор: krundetz 22.8.2008, 19:24

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

Автор: bobik02 22.8.2008, 20:09

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

Автор: Feldmarschall 23.8.2008, 09:21

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

Автор: lukas 23.8.2008, 10:00

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

Автор: skyboy 23.8.2008, 11:01

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

Автор: Feldmarschall 23.8.2008, 11:09

Цитата(skyboy @  23.8.2008,  11:01 ) сколько можно использовать этот аргумент? столько же, сколько и аргумент про "единый интерфейс к разным БД". это одного рода доводы - из мечтательной области "а как хорошо в теории могло бы быть..." =)

Автор: lukas 23.8.2008, 13:17

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

Автор: skyboy 23.8.2008, 14:01

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

Автор: solenko 23.8.2008, 15:57

Стандартный пукть новичка. 1. Начал писать  2. прочитал что ООП это круто  3. начал пытатся писать в ООП стиле  4. набрался опыта и понял что в п.1. он писоал [censored34! Пожалуйста, соблюдайте элементарные правила приличия при общении на форуме] 5. решил что все это благодаря ООП Качественный код можно писть в любом случае (ровно как и не качественный). В моем текущем проекте модульность обеспечивается исключительно за счет статических методов классов. По вашему это то, что подразумевается под громким термином ООП? Никуя -- это просто неймспейсы, которые отсутствуют в PHP (пока). При этом я абсолютно уверен, что это наиболее оптимальное решение.  Учитесь ДУМАТЬ, а не слепо верить какой-то парадигме.

Автор: source777 23.8.2008, 16:46

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

Автор: skyboy 23.8.2008, 17:05

Цитата(source777 @  23.8.2008,  15:46 ) Сколько можно путать ООП и классы? Классы - это всего лишь один из синтаксических вариантов реализации ООП ога. в РНР активно используется протитопное программирование... а я вот сижу и усиленно путаю классы и ООП

Автор: source777 23.8.2008, 18:07

Цитата(skyboy @  23.8.2008,  17:05 ) ога. в РНР активно используется протитопное программирование... а я вот сижу и усиленно путаю классы и ООП  smile   Причём тут PHP? ООП от языка не зависит, и уж тем более не достаточно написать слово class, чтобы твоя программа стала объектно-ориентированной...

Автор: bobik02 23.8.2008, 19:45

Цитата(solenko @  23.8.2008,  15:57 ) Стандартный пукть новичка. 1. Начал писать  2. прочитал что ООП это круто  3. начал пытатся писать в ООП стиле  4. набрался опыта и понял что в п.1. он писоал [censored34! Пожалуйста, соблюдайте элементарные правила приличия при общении на форуме] 5. решил что все это благодаря ООП Это Вы проходили на собственной "шкуре" ? Или же это  со стороны  ?

Автор: lukas 23.8.2008, 20:41

skyboy, прототипное было скорее всего в 4ой версии, если вы конешно понимаете что такое "прототипное"... И причем тут вариант реализации ООП ??? Их не так уж много и они довольно похожи... Цитата(solenko @  23.8.2008,  15:57 ) Стандартный пукть новичка.1. Начал писать 2. прочитал что ООП это круто 3. начал пытатся писать в ООП стиле 4. набрался опыта и понял что в п.1. он писоал гавно5. решил что все это благодаря ООПКачественный код можно писть в любом случае (ровно как и не качественный).В моем текущем проекте модульность обеспечивается исключительно за счет статических методов классов. По вашему это то, что подразумевается под громким термином ООП? Никуя -- это просто неймспейсы, которые отсутствуют в PHP (пока). При этом я абсолютно уверен, что это наиболее оптимальное решение. Учитесь ДУМАТЬ, а не слепо верить какой-то парадигме. Вы опять меня не понимаете, ...   ... как смешно читать как люди применяют ООП, если учесть что статистический вызов для любых методов будет исключен в PHP6, Я же использую ООП для того чтобы не писать одно и тоже по несколько раз, применяю НАСЛЕДОВАНИЕ и в результате наращиваю весь функционал... P.S. И причем тут вера в парадигму, когда с помощью ООП мое затрчиваемое время сильно уменьшается, а главное появляется упорядоченность в коде.

Автор: Bastet 23.8.2008, 20:50

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

Автор: source777 23.8.2008, 21:19

Bastet, поздравляю с  самостоятельным осознанием преимуществ ООП   Цитата(Bastet @  23.8.2008,  20:50 ) Однако, по прежнему считаю, что для разработки не мега-сложный проектов вполне можно обойтись старым добрым функциональным программированием. и будет все красиво, и будет все работать.  Ты уверена, что для не сложных проектов нужно именно http://ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5?

Автор: Bastet 23.8.2008, 21:28

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

Автор: skyboy 23.8.2008, 21:34

Цитата(lukas @  23.8.2008,  19:41 ) если вы конешно понимаете что такое "прототипное" конечно, нет. не понимаю. вот source777 меня просветил, что я, оказывается, зря говою о PHP в разделе "PHP: Общие вопросы" в теме "Объектно-ориентированный РНР". от Вас я с удовольствием выслушаю оцеку собственных познаний прототипного подхода.  кстати говоря, учиывая, что прототипный подход подразумевает требования: 1. возможность полного клонирования объекта. 2. возможность модификации не только данных объекта, но и методов. нет, конечно, я и не думал читать лекцию. просто напомнил.  необходимые механизмы реализованы в http://ua2.php.net/classkit, потому писать в протипно-ориентированном стиле можно под любой версией, под которой работает classkit. потому меня удивляет фраза про 4 версию, в которой "протипное программирование было скорее всего". неужто в 5-ке я не смогу динамически добавлять/удалять методы? или клониорвание объекта стало реализовываться в 5-й версии хуже(ввели http://ua2.php.net/manual/ru/language.oop5.cloning.php, позволяющий реализовать любую логику клонирования). Добавлено через 2 минуты и 12 секунд Bastet, все в порядке. source777 слишком рьяно относится к терминологии. просот функциональным программированием обычно называют немного другое. структура программы, когда обработка производится при помощи функций/процедур называется "процедурным программированием". но это придирки, я думаю

Автор: lukas 23.8.2008, 21:39

Цитата(Bastet @  23.8.2008,  20:50 ) РНР5, ура-ура, теперь достаточно хорошо реализует ООП всетаки много не хватает... например что-то вроде свойств со своими read и write методами, но это можно реализовать обходными путями, а вот про виртуальные методы я что-то ничего не нашел, а это очень многое обламывает...

Автор: skyboy 23.8.2008, 21:41

Цитата(lukas @  23.8.2008,  19:41 ) если учесть что статистический вызов для любых методов будет исключен в PHP6 откуда такая информация? все, что я нашел: что не-статические методы нельзя будет вызывать, как статтические - только для созданного объекта можно будет. но отказываться от статических членов не вижу смысла и не обнаружил про такое никакой информации. поделись источником, будь добр.

Автор: lukas 23.8.2008, 21:43

skyboy, Вся суть прототипного ООП сводится к тому что классов нет, а есть только ОБъекты, которые можно клонировать... остальное уже расширение языка...  Цитата(skyboy @  23.8.2008,  21:34 ) Bastet, все в порядке. source777 слишком рьяно относится к терминологии. просот функциональным программированием обычно называют немного другое. структура программы, когда обработка производится при помощи функций/процедур называется "процедурным программированием". но это придирки, я думаю  Я еще когда писал про это, подумал а как лучше написать процедурное или функциональное,...

Автор: source777 23.8.2008, 22:49

Цитата(skyboy @  23.8.2008,  21:34 ) вот source777 меня просветил, что я, оказывается, зря говою о PHP в разделе "PHP: Общие вопросы" в теме "Объектно-ориентированный РНР".   Тема скорее всё-таки о применении ООП в PHP, а не об объектно-ориентированном РНР. Если тебе всё же хочется исходить из названия темы, то PHP не является объектно-ориентированным и никогда таким не станет, а если станет, то это уже будет не PHP (аналогично переходу от VisualBasic к VisualBasic.NET, название осталось, объектная ориентация появилась, а от языка только синтаксис остался, да и то частично), т.к. определяющую парадигму невозможно навесить на что-то уже существующее, даже такие языки как С++ и Delphi не сумели реализовать встроенную поддержку ООП в полной мере, куда уж тут PHP... Если нужен объектно-ориентированный язык для веб-разработки, то советую обратить внимание на Ruby. Добавлено через 7 минут и 29 секунд Цитата(Bastet @  23.8.2008,  21:28 ) Эм... а ссылка - это к чему? Я что-то напутала в определении?  Назовем его тогда функциональным подходом, что ли...  да, лучше называть этот подход процедурным, или на крайний случай структурным, а функциональный подход обычно применяется для решения математических задач, либо для задач, требующих высокую степень надёжности кода.

Автор: skyboy 23.8.2008, 22:58

Цитата(lukas @  23.8.2008,  20:43 ) Вся суть прототипного ООП сводится к тому что классов нет, а есть только ОБъекты, которые можно клонировать без возможности динамического управления методами у тебя будет не прототипно-ориентированное программирование, а тупо один объект, данные которого ты сможешь переопределить, а вот поведение - нет. простое клонирование объектов - не более, чем клонирование. так что это не "расширение языка", а необходимое условие для реализации прототипов. ты мне так, незнающему, и не сообщил, чем же 4-я версии "более склонна" к прототипно-ориентированному программированию. также, почему то, ничего не говоришь про "отказ от статических методов" в 6-й версии. заинтриговал и молчишь. Цитата(lukas @  23.8.2008,  20:39 ) например что-то вроде свойств со своими read и write методами такое http://ua.php.net/manual/ru/language.oop5.overloading.php уже с пятой версии. только, возможно, не в таком виде, как можно было привыкнуть в десктопном программировании: для объекта существует только один getter: магический метод с именем __get, и только один setter - магический метод с именем __set, в качестве параметров которым передается и имя свойства, к которому прогаммист желает получить доступ. а благодаря магическому методу __call можно сделать getter даже для методов объекта. Добавлено @ 23:03 Цитата(source777 @  23.8.2008,  21:49 ) то советую обратить внимание на Ruby так мы тут про PHP говорить, знач, не будем? так бы и сказал. ушел читать про Ruby. Цитата(source777 @  23.8.2008,  21:49 ) т.к. определяющую парадигму невозможно навесить на что-то уже существующее есть такое понятие: "мультипарадигменнось" Цитата(lukas @  23.8.2008,  20:39 ) а вот про виртуальные методы не знаю, зачем языку с динамической типизацией переменных виртуальные методы. по сути - тут все методы "виртуальные" в том отношении, что как ты объект создал, метод соответствующего класса будет использоваться. а не метод предка, который надо вызывать явно.  виртуальные методы используются ведь для полиморфизма, когда в переменная типа класса-предка ссылается на объект класса-потомка и надо работать с методами класса-потомка. в PHP так и будет в любом случае. [Updated] Цитата(source777 @  23.8.2008,  21:49 ) Если тебе всё же хочется исходить из названия темы мне чаю хочется. а вот твое "при чем тут PHP к ООП?", когда тема с таким названием находится в разделе "РНР" меня удивило своей неожиданностью

Автор: Bastet 23.8.2008, 23:38

lukas, read и white - это да, сама немного сокрушалась по этому поводу. Вместо виртуальных методов, если я еще ничего не забыла, для реализации полиморфизма применяются абстрактные метода у базового класса. Так что полиморфизм должен работать. Мне еще очень хотелось бы модификатор доступа friendly и возможность формировать пакета... *для красоты*

Автор: Mal Hack 24.8.2008, 11:46

Похоже моего поста тут никто не увидел, а жаль. Процитирую: Цитата Что касается ООП, я уже тут не в одной теме озвучивал свою позицию. ООП как проектирование - к языку вообще мало имеет отношение, оно лишь учитывает некоторые возможности языка, не более того. ООП как программирование с точки зрения ПХП - абсурд, т.к. ПХП как был структурированным языком, так им и остался, ООП в пхп носит лишь информационную модель, в которой нет событийности, за исключением __call, __get, __construct, __destruct и trigger_errors, ну может еще небольшой части. В ПХП ООП - просто синтаксически дает синтаксис ООП, а следовательно более простую реализацию приложения, спроектированного по принцыпам ООПроектирования, чем при полностью структурном описании. Хотя, конечно, зависит от задачи. Самый просто пример. Покажите, где у вас объекты в ПХП. Модули? А вы уверены что они у вас именно живут как объекты, а не просто как синтаксически стилизованный набор функций? В ПХП объекты, как объекты - не живут..  Ваша ошибка в том, что вы смотрите на ООП, как на реализацию, мол вот в Сях есть дружественные функции, а в ПХП нет и т.п. Нельзя так. ООПрограммирование - это концепция, а не реализация!!! ООПрограммирование в ПХП как таковое - отсутствует, есть синтаксически приближенные конструкции которые позволяют сделать объектный код, упростить несколько разработку, но суть все равно таже. При этом никто не мешает применить принципы ООПроектирования к созданию приложений на ПХП. Виртуальные методы, дружественные функции, это лишь надстройка над реализацией объектной модели, даже той, которая есть в С++, например. Не они определяют тот факт, что вы используйте ООПрограммирование, а наличие объектов, которые живут, как объекты, которые на что-то реагируют, что-то сами иногда делают. в ПХП этого - нет. Есть объектный синтаксис, который позволяет структурировать код, ну и в некоторых отдельных случаях организовать "примитивную псевдо событийность"... Еще раз повторюсь: Покажите, где у вас объекты в ПХП. Модули? А вы уверены что они у вас именно живут как объекты, а не просто как синтаксически стилизованный набор функций? В ПХП объекты, как объекты - не живут..

Автор: lukas 24.8.2008, 12:22

Mal Hack,  мы обсуждаем не как реализованно Объектная модель в ПХП (это вообще дело разработчиков PHP), а какие преимущество его использования... Если уж пойти дальше то можно прийти к тому что все равно это все mov,add, всякие прерывания ASM-лера...  Bastet, абстрактные методы меня не устраивают... например у меня функция A используется в Функции B объекта Obj1, я создаю унаследованный класс Obj2 от Obj1, в нем переопределяю функцию A (т.е. уже функционал другой) и мне нужно чтобы в B вызывалась уже именно переопределенная функция, а не родителя...

Автор: Mal Hack 24.8.2008, 12:34

Цитата(lukas @  24.8.2008,  13:22 ) мы обсуждаем не как реализованно Объектная модель в ПХП (это вообще дело разработчиков PHP) Вы обсуждаете реализацию ООП, которую вам разработчики предлагают. Вот о чем я... В качестве доказательства - ваши же слова: Цитата(lukas @  24.8.2008,  13:22 ) например у меня функция A используется в Функции B объекта Obj1, я создаю унаследованный класс Obj2 от Obj1, в нем переопределяю функцию A (т.е. уже функционал другой) и мне нужно чтобы в B вызывалась уже именно переопределенная функция, а не родителя...   Вот про это я говорил.

Автор: sTa1kEr 25.8.2008, 17:29

Цитата(lukas @  22.8.2008,  19:28 ) Люди просто не доконца осознают мощь ООП Интересно, а в разделах по JavaScript-у, наверное, рассказывают про "мощь" прототипного программирования, в lisp про "мощь" функционального, а в С про "мощь" процедурного?   ООП стоит считать, как обобщенный алгоритм, однин из многочисленых. Алгоритм не может быть сам по себе "крутым", он может быть наиболее оптимальным для решения каких-либо одних задач и наоборот значительно более сложным для решения других. По этому, "натягивать" ООП под все задачи подряд - не самое лучшее решение. Приведите конкретную задачу и только тогда можно будет сказать насколько удачно можно будет применить к ней ОО подход. Цитата(source777 @  23.8.2008,  23:49 ) PHP не является объектно-ориентированным Правильнее будет сказать: 1. PHP изначально не являлся ОО языком. 2. На данный момент в PHP ООП реализован в не достаточной степени. Цитата(source777 @  23.8.2008,  23:49 ) аналогично переходу от VisualBasic к VisualBasic.NET, название осталось, объектная ориентация появилась, а от языка только синтаксис остался, да и то частично Это применимо и к PHP, только в отличии от VB это происходит в несколько этапов и  нету таких четких границ. Цитата(lukas @  23.8.2008,  22:39 ) например что-то вроде свойств со своими read и write методами Будет в PHP 5.3 http://wiki.php.net/todo/php53 Цитата # “real” properties with attached getters and setters Цитата(Bastet @  24.8.2008,  00:38 ) Вместо виртуальных методов, если я еще ничего не забыла, для реализации полиморфизма применяются абстрактные метода у базового класса.  Вы правы. В PHP все не приватные методы по сути являются виртуальными. Т.ч. полиморфизм реализуется в полное мере. Цитата(lukas @  24.8.2008,  13:22 ) например у меня функция A используется в Функции B объекта Obj1, я создаю унаследованный класс Obj2 от Obj1, в нем переопределяю функцию A (т.е. уже функционал другой) и мне нужно чтобы в B вызывалась уже именно переопределенная функция, а не родителя...   Определяете функцию B protected и вызываться будет именно дочерняя функция. Цитата(Mal Hack @  24.8.2008,  12:46 ) А вы уверены что они у вас именно живут как объекты, а не просто как синтаксически стилизованный набор функций? Хе хе. Любые конструкции в высокоуровневых языках - это и есть по сути, как вы сказали "синтаксически стилизованный набор функций"    Цитата(Mal Hack @  24.8.2008,  12:46 ) В ПХП объекты, как объекты - не живут..  А как они "живут", как набор инструкций может быть?    Цитата(Mal Hack @  24.8.2008,  12:46 ) Ваша ошибка в том, что вы смотрите на ООП, как на реализацию, мол вот в Сях есть дружественные функции, а в ПХП нет и т.п. Нельзя так. ООПрограммирование - это концепция, а не реализация!!! Тут совершенно согласен. А название темы вообще странное... Цитата(Mal Hack @  24.8.2008,  12:46 ) в которой нет событийности Тут ноги растут из типизированости в PHP (точнее ее отсутствие). Ведь что такое событийность? Событийность это всего-лишь массив делегатов, и не более того! Делегаты в PHP есть? Есть - это тоже самое что и строка. Ну напишите перед ней /* @var Delegate $delegate */ вот вам и делегат. Асоциативные массивы в PHP? Можно не отвечать. Подписка/отписка на/от события = добавление/удаление делегата в/из массив. Вызов события = поочередный вызов делегатов массива. Все! Вот вам и событийность и не нужны никакие __call. А если еще учесть, что в PHP 5.3: Цитата “real” properties with attached getters and setters operator overloading http://wiki.php.net/rfc/closures SPL То можно использовать событийность практически так же как в C# Код $object->someEvent += function(stdClass $object, EventArgs $args) {     echo 'Event fired !!!'; }

Автор: Mal Hack 25.8.2008, 20:23

Цитата(sTa1kEr @  25.8.2008,  18:29 ) Хе хе. Любые конструкции в высокоуровневых языках - это и есть по сути, как вы сказали "синтаксически стилизованный набор функций"  smile  Возьмите кнопочку... Тут уже благодаря системным вызовам и прерываниям - не просто синтаксически стиллизованный код. Но по сути, конечно, есть такая тема. Другое дело, что в ПХП это именно стилизованный синтаксис 100%. Цитата(sTa1kEr @  25.8.2008,  18:29 ) А как они "живут", как набор инструкций может быть?  smile  Объект, если рассмотреть в сущности не ПХП, а к примеру кнопочки той же, благодаря cистемным вызовам и прерываниям ведет себя как некая сущность. Цитата(sTa1kEr @  25.8.2008,  18:29 ) Тут ноги растут из типизированости в PHP (точнее ее отсутствие). Ведь что такое событийность? Событийность это всего-лишь массив делегатов, и не более того! Типизация тут не при чем. Событийность - реакции на определенные сигналы, поступающие от туда или отсюда. Делегаты - термин по крайней мере не из С++, хотя может и из МФЦ, но я с ним не работал. И потом, Делегат - функция (если я ничего не путаю), т.е. более высокий уровень абстракции. Цитата(sTa1kEr @  25.8.2008,  18:29 ) Делегаты в PHP есть? Есть - это тоже самое что и строка. Ну напишите перед ней /* @var Delegate $delegate */ вот вам и делегат. Асоциативные массивы в PHP? Можно не отвечать. Подписка/отписка на/от события = добавление/удаление делегата в/из массив. Вызов события = поочередный вызов делегатов массива. Хорошо, есть объект А и Б, с методом А1 и Б1. При срабатыавании Б1 должен автоматически вызваться А1. Б о А ничего не знает. Также, как и А о Б. Цитата(sTa1kEr @  25.8.2008,  18:29 ) А если еще учесть, что в PHP 5.3: Ничего не могу сказать на эту тему, не смотрел еще этих вещей...

Автор: lukas 25.8.2008, 21:22

Цитата(sTa1kEr @  25.8.2008,  17:29 ) Определяете функцию B protected и вызываться будет именно дочерняя функция. Круто, не знал...    Ага, всего что не хватает щас в PHP5.X будет в PHP5.3

Автор: sTa1kEr 25.8.2008, 22:20

Цитата(Mal Hack @  25.8.2008,  21:23 ) Возьмите кнопочку... Тут уже благодаря системным вызовам и прерываниям - не просто синтаксически стиллизованный код. Но по сути, конечно, есть такая тема. Другое дело, что в ПХП это именно стилизованный синтаксис 100%. По поводу кнопочек, специфика HTTP протокола такая, что события типа onClick в server-side скрипте просто не уместны в данном контексте, т.к. они происходят на стороне клиента. Возьмем, к примеру, ASP.NET. В C# ведь используется событийность? Однако что происходит при создании события onClick на кнопку? - Генерируется куча джаваскрипта и куча кода в на C# - вот тебе и вся событийность... по сути всего-лишь фитча IDE. Так чем же PHP в этом плане хуже?  Цитата(Mal Hack @  25.8.2008,  21:23 ) Объект, если рассмотреть в сущности не ПХП, а к примеру кнопочки той же, благодаря системным вызовам и прерываниям ведет себя как некая сущность. Т.е. по твоему, если объект абстрагирован от системных вызовов - то это уже в понимании ООП и не объект вовсе? В таком случае C# так же не ОО язык, т.к. тоже не работает непосредственно с системными вызовами. Цитата(Mal Hack @  25.8.2008,  21:23 ) Типизация тут не при чем. Отсутствие типизации виновато в том, что складывается впечатление о не возможности использования событий в PHP. Хотя да, типизация это не самая большая проблема. Все-таки на первом месте идет многопоточность. Цитата(Mal Hack @  25.8.2008,  21:23 ) Событийность - реакции на определенные сигналы А что такое реакция на сигнал? Это вызов определенной функции при изменении состояния некоторого объекта.  Цитата(Mal Hack @  25.8.2008,  21:23 ) Делегат - функция (если я ничего не путаю) Почти. Делегат - это указатель на функцию. Насколько я понимаю, в C++ это так и называется? Цитата(Mal Hack @  25.8.2008,  21:23 ) Хорошо, есть объект А и Б, с методом А1 и Б1. При срабатыавании Б1 должен автоматически вызваться А1. Б о А ничего не знает. Также, как и А о Б. Как это не знает? А сначала должен подписать на событие А1, прежде чем Б сможет его автоматически вызвать. Т.е. по сути передать А должен передать делегат функции A1 объекту Б. Тогда при срабатывании Б1 просто будут вызваны все делегаты которые ранее были переданы объекту.

Автор: Mal Hack 25.8.2008, 22:34

sTa1kEr, давай сиходить из того, событийность должна реализовываться не программистом, а языком.   В ПХП этого нет. Вот я о чем. Реализовать событийность самому - можно, а вот сделать что-то вроде: connect(A, A1(), B, B1()) - нельзя. На счет 5.3 я не говорю - не знаю. Т.е. объекты А и Б не знают о сущестовании друг друга, об этом знает программа, которая связывает сигнал со слотом. Цитата(sTa1kEr @  25.8.2008,  23:20 ) Отсутствие типизации виновато в том, что складывается впечатление о не возможности использования событий в PHP. Типизация и событийность - совершенно разные вещи, они тут не при чем (в совокупности). Цитата(sTa1kEr @  25.8.2008,  23:20 ) По поводу кнопочек, специфика HTTP протокола такая, что события типа onClick в server-side скрипте просто не уместны в данном контексте, т.к. они происходят на стороне клиента. Так вот и покажите мне в ПХП - объект, который будет себя вести КАК кнопочка. Т.е. его событийность будет реализована средствами ПХП, а не программиста (реализация самих событий - конечно за программистом). Цитата(sTa1kEr @  25.8.2008,  23:20 ) Т.е. по твоему, если объект абстрагирован от системных вызовов - то это уже в понимании ООП и не объект вовсе? В таком случае C# так же не ОО язык, т.к. тоже не работает непосредственно с системными вызовами. Я несколько не корректно выразился. В данном случае я имел ввиду то, что событийность на уровне языка реализуется, а не самим программистом. Он только связывает события.

Автор: sTa1kEr 25.8.2008, 23:12

Цитата(Mal Hack @  25.8.2008,  23:34 ) Так вот и покажите мне в ПХП - объект, который будет себя вести КАК кнопочка. Такого объекта нет ни в PHP, ни в одном другом server-side языке, т.к. такое не возможно. В качестве наглядного примера я выше привел ASP.NET - там все тоже самое, с одной разницей, реализацией события занимается не программист, а IDE. В принципе Zend может сделать тоже самое и для PHP. Цитата(Mal Hack @  25.8.2008,  23:34 ) sTa1kEr, давай сиходить из того, событийность должна реализовываться не программистом, а языком.   Хорошо, в таком случае весь вопрос в том, что в PHP нет такой конструкции event (по сути просто пары встроенных классов)? Да этого в PHP нет и хоть это не сложно реализовать в PHP, скорее всего этого не будет до тех пор, пока в этом нет надобности (а особой надобности в этом, имхо, не будет пока нет полноценной многопоточности). Однако это не мешает использовать событийность и ОО подход.

Автор: Mal Hack 25.8.2008, 23:26

Цитата(sTa1kEr @  26.8.2008,  00:12 ) Такого объекта нет ни в PHP, ни в одном другом server-side языке, т.к. такое не возможно. В качестве наглядного примера я выше привел ASP.NET - там все тоже самое, с одной разницей, реализацией события занимается не программист, а IDE. В принципе Zend может сделать тоже самое и для PHP. Ну дык и я про тоже. Такова специфика ПХП... Среда это среда. А я говорю, ну как бы про транслятор чтоли, в совокупностью с системой. Сейчас могу не корректно выражать мысли, ибо голова забита несколько другими вопросами. Цитата(sTa1kEr @  26.8.2008,  00:12 ) Хорошо, в таком случае весь вопрос в том, что в PHP нет такой конструкции event (по сути просто пары встроенных классов)? Ну как бы грубо говоря да. Грубо говоря, потому, что event лишь один из вариантов реализации связи, а я про механизм, но думаю мы друг друга поняли. Цитата(sTa1kEr @  26.8.2008,  00:12 ) Да этого в PHP нет и хоть это не сложно реализовать в PHP, скорее всего этого не будет до тех пор, пока в этом нет надобности В языке этого нет. Реализовать может только сам программист. Вот в чем суть, я как раз-таки имею ввиду то, что именно в языке этого механизма нет. Цитата(sTa1kEr @  26.8.2008,  00:12 )  (а особой надобности в этом, имхо, не будет пока нет полноценной многопоточности) Надобность вещь спорная, я бы с большим удовольствием использовал бы механизм сигнал/слот, чтобы модули дург с другом не связывать непосредственно, а делать связь в основной программе. Это дает большую гибкость. Многопоточность тут тоже не при чем. В ПХП это не так актуально, а если надо, есть средства ее реализовать руками. А сигнал/слот может и в одном потоке работать. Цитата(sTa1kEr @  26.8.2008,  00:12 ) Однако это не мешает использовать событийность и ОО подход.  Подход, тобишь ООПроектироание - да. Событийность - опять-таки, какую? Встроенное в ядро - нет, реализованное ручками - да, но это уже не совсем то.

Автор: sTa1kEr 25.8.2008, 23:52

Цитата(Mal Hack @  26.8.2008,  00:26 ) В языке этого нет. Реализовать может только сам программист. Вот в чем суть, я как раз-таки имею ввиду то, что именно в языке этого механизма нет. Я имел ввиду не сложно реализовать в самом языке этот механизм. И разработчики PHP вполне могли бы это сделать и в PHP 5.3, и тем более в PHP 6, но не делают, как я думаю, по описанным мной выше причинам.  Цитата(Mal Hack @  26.8.2008,  00:26 ) Такова специфика ПХП... Это специфика не PHP, а HTTP протокола. Цитата(Mal Hack @  26.8.2008,  00:26 ) Многопоточность тут тоже не при чем. Еще как причем. Если в крации, то реализовать ОО модель в PHP на уровне .NET-а мешают, на мой взгляд, именно эти две вещи: многопоточность, не строгая типизация. Mal Hack, PHP это высокоуровневый язык, ты же рассуждаешь с позиции низкоуровнего C++.

Автор: Mal Hack 26.8.2008, 00:04

Цитата(sTa1kEr @  26.8.2008,  00:52 ) Я имел ввиду не сложно реализовать в самом языке этот механизм. И разработчики PHP вполне могли бы это сделать и в PHP 5.3, и тем более в PHP 6, но не делают, как я думаю, по описанным мной выше причинам.  По каким причинам? наверное я пропустил просто... ты не подумай, что я придираюсь, просто реально я их либо в упор не вижу, приведи еще разок Цитата(sTa1kEr @  26.8.2008,  00:52 ) Это специфика не PHP, а HTTP протокола. Давай так. Отбросим кнопочки. Мы про событийность внутри самого ПХП, т.е. в скрипте. Тут HTTPне при чем. Тут специфика структурного, интерпретируемого языка программирования, как Perl, например. Цитата(sTa1kEr @  26.8.2008,  00:52 ) Еще как причем. Если в крации, то реализовать ОО модель в PHP на уровне .NET-а мешают, на мой взгляд, именно эти две вещи: многопоточность, не строгая типизация. Пример однопоточного выполнения (чисто на пальцах, суть, которую хочу показать).  Код connect(A, signal(), B, slot()) .... A::somefnc() {     emit signal(); } B::slot() {  //  dosomething } Зачем тут многопоточность? есть сигнал - выполнилась функция, по другому: Код A::somefnc() {     B::slot(); } B::slot() {  //  dosomething } Да, для Визуалки испольузется многопоточность, но по сути, сам механизм сигнал/слот не обязательно должен быть в другом потоке. Цитата(sTa1kEr @  26.8.2008,  00:52 ) не строгая типизация. А при чем тут типизация? То, что это минус ПХП и т.д. - отложим, не в этом суть темы, чем  она мешает событийности? Скажем так, да жесткая типизация позволилабы прописывать объекты и т.п. в этом ты имеешь ввиду? Цитата(sTa1kEr @  26.8.2008,  00:52 ) Mal Hack, PHP это высокоуровневый язык, ты же рассуждаешь с позиции низкоуровнего C++.  Ну что такое низкий и высокий уровень я бы еще поспорил. Это условность всетаки. И потом, В C++ той событийности, о которой я говорю нет, ее дает Qt, например. Это уже более высокий уровень, все-таки.

Автор: sTa1kEr 26.8.2008, 14:40

Цитата(Mal Hack @  26.8.2008,  01:04 ) По каким причинам? наверное я пропустил просто... По тем причинам, что в этом практически нет потребности. Для кнопок этого не сделать, а отсутствие многопоточности не позволит создать сколько-нибудь приемлемое серверное приложение. Остаются только простейшие события вроде onRowDeleted, onPageRender итд - это просто реализуется и как-то не в стиле PHP что-ли... В общем не стоит овчинка выделки на данные момент, то что вместо /* @var event */ можно будет написать просто event, кроме большей наглядности ничего не даст. Разве что "для галочки" реализовать. Цитата(Mal Hack @  26.8.2008,  01:04 ) Зачем тут многопоточность? Давай по порядку. Естественно здесь она не нужна, она не причина, она один из факторов не дающих PHP создать, так сказать, благоприятную почву для создания событийности на уроне языка. Или другими словами отсутствие таких вещей как многопоточность и строгая типизация сильно сдерживает развитие PHP в нужном, так сказать, ОО направлении. Наглядный пример http://php.net/socket-select - вот как приходится извращатся, что бы избежать fork-ов! И это еще цветочки! Естественно, про реализацию event patern-а я вообще молчу...  Строгая типизация естественно тоже сама по себе ни причем. Но она во первых - так же сковывает развитие PHP (тут можно долго перечислять проблемы из-за отсутствия типизации, но это уже к оффтоп). Во вторых - она (точнее ее отсутствие) вводит в заблуждение, раз в PHP нету типа Delegete - значит в PHP нету делегатов, анонимных делегатов... раз нету ключевого слова event, значит нельзя использовать событийность, и все в таком духе. Хотя на самом деле все это есть, пусть и называется строкой... Будь строгая типизация - ничего бы такого не было. Кстати, еще пример - SplTypes. Eще больше двух лет назад был уже реализован тип Enum (это из C#) + реализованы попытки совместить строгую и не строгую типизацию... И ведь даже работает, только вот не нужно никому. Цитата(Mal Hack @  26.8.2008,  01:04 ) Пример однопоточного выполнения (чисто на пальцах, суть, которую хочу показать).  Цитата(Mal Hack @  26.8.2008,  01:04 ) connect(A, signal(), B, slot()) Я не знаю что это за функция, но насколько я предполагаю это и есть подписка на событие? И в чем проблема тоже самое сделать в PHP? Опять же пример из C#, взять подписку на событие и пройтись рефлектором. И что мы увидим? Да всеголишь вызов метода add_Listener() у обычного, ничем не отличающегося от других класса Event ! Т.е. по сути событие это класс в из 3 методов (addListener, removeListener и fire) и одного свойства - коллекции делегатов (читай массив указателей на функции).  Твой пример портированный на C# Код public delegate void SomeEventHandler(object sender, EventArgs e); public class Program {     public static void Main()     {         A.signal += new SomeEventHandler(B.slot); // аналог твоей функции коннект     } } public class A {     public static event SomeEventHandler signal;     public static void somefnc() // твоя функция A::somefnc()     {         signal(); // если я правильно понял, то тоже саоме что: emit signal();     } } public class B {     public static void slot() // твоя функция B::slot()     {         //  dosomething     } } А вот как бы это могло выглядеть в PHP Код A::$signal[] = 'B::somefunc'; // вместо функции connect class A {     public static event $signal;      public static function somefnc()     {         $this->signal();     } } class B {     public static function slot()     {         //  dosomething     } } А вот как это уже сейчас можно использовать Код A::$signal = new Event(); // Можно в конструкторе A::$signal[] = 'B::somefunc'; // Да да, благодаря интерфейсу ArrayAccess, это возможно уже сейчас, не смотря на то что Event - это обычный класс class A {     public static $signal; // если бы не был статический, то в конструкторе $this->signal = new Event();      public static function somefnc()     {         $this->signal->fire(); // в PHP 5.3 уже можно будет реализовать просто $this->signal();     } } class B {     public static function slot()     {         //  dosomething     } } Найди 3 отличия

Автор: lukas 26.8.2008, 19:36

Люди да причем тут события, это вообще задумка для ОС приложений, где без событийной модели не обойтись, вот ее и встроили... Mal Hack, ты думаешь во всех языках под ОС релизовано событийность, да событийность часто реализуется только за счет IDE, и за частую события это обычные свойства с read и write (которые принимают в качестве результата ссылку на функцию)... Далее же где вызывать то или иное событие определяется часто программистом... События довольно легко реализовать через callback функции, и они не имеют никакого отношения к ООП.

Автор: krundetz 26.8.2008, 22:14

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

Автор: Mal Hack 26.8.2008, 23:25

Цитата(sTa1kEr @  26.8.2008,  15:40 ) Естественно здесь она не нужна, она не причина, она один из факторов не дающих PHP создать, так сказать, благоприятную почву для создания событийности на уроне языка.  Согласен. Цитата(sTa1kEr @  26.8.2008,  15:40 ) Строгая типизация естественно тоже сама по себе ни причем. Но она во первых - так же сковывает развитие PHP (тут можно долго перечислять проблемы из-за отсутствия типизации, но это уже к оффтоп). Согласен, в какой-то степени, но в концепте тоже. Цитата(sTa1kEr @  26.8.2008,  15:40 ) Во вторых - она (точнее ее отсутствие) вводит в заблуждение, раз в PHP нету типа Delegete - значит в PHP нету делегатов, анонимных делегатов... раз нету ключевого слова event, значит нельзя использовать событийность, и все в таком духе. Хотя на самом деле все это есть, пусть и называется строкой... Будь строгая типизация - ничего бы такого не было. Ну, в принципе да. Цитата(sTa1kEr @  26.8.2008,  15:40 ) А вот как это уже сейчас можно использовать Да, но, согласись, это криво, по сути это callback, не очень удобный. В принципе да, это механизм, несколько не тот, который я считаю оптимальным, но реальный, работающий механизм. С какого момента это стало возможно? Плюс в репу. Цитата(lukas @  26.8.2008,  20:36 ) События довольно легко реализовать через callback функции, и они не имеют никакого отношения к ООП.   Объект должен обладать событийностью, механизм которой реализован в самом языке, и его не надо делать программисту. Цитата(krundetz @  26.8.2008,  23:14 ) sTa1kEr, Mal Hack, чет вы в реализацию помоему ударились как в свое время говорил мой научник реализовывать будете потом вы концепцию концепцию поймите. Потому, что вопрос коснулся конкретной реализации задачи построения событийности. Цитата(krundetz @  26.8.2008,  23:14 ) Ище раз повторю свою позицию ООП это прежде всего способ облегчить жизнь программиста, и в первую очередь при проектирование, а уже грамотоно спроиктированая система облегчит труд при ее реализации.  В данном случае ООП - проектирование - исключительно...

Автор: lukas 27.8.2008, 07:31

Цитата(Mal Hack @  26.8.2008,  23:25 ) Объект должен обладать событийностью, механизм которой реализован в самом языке, и его не надо делать программисту ну если нет в ПХП событийности, что отказываться от использования классов??? P.S. На дрюпале если я не ошибаюсь (я не знаток дрюпала) событийностью называются хуки, которые скорее всего реализованы через колбек функции...

Автор: Mal Hack 27.8.2008, 08:53

Цитата(lukas @  27.8.2008,  08:31 ) ну если нет в ПХП событийности, что отказываться от использования классов??? Нет, конечно, просто говорить, что мы используем объектный синтаксис, а не работаем с ОО моделью, в реализации

Автор: awers 27.8.2008, 11:02

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

Автор: source777 27.8.2008, 11:12

Цитата(Mal Hack @  27.8.2008,  08:53 ) просто говорить, что мы используем объектный синтаксис, а не работаем с ОО моделью, в реализации  Тоже самое нужно сказать и про С++ и про Delphi, если уж быть последовательным, т.к. там тоже нет встроенной в язык реализации ООП.  Да и чего уж там,  даже C# & Java тоже не дают полной встроенной поддержки ООП. Но стоит ли настолько ударяться в пуризм? А то останется выбирать между SmallTalk`ом и Eiffel`ем... P.S. Осталось лишь решить каждому для себя как программировать: "на языке" или "с использованием языка"...

Автор: sTa1kEr 27.8.2008, 12:29

Цитата(Mal Hack @  27.8.2008,  00:25 ) Да, но, согласись, это криво, по сути это callback, не очень удобный. Да, выглядит кривовато. Впрочем в PHP много что кривовато выглядит. Но в будущем эта ситуация должна улучшится. Я уже выкладывал ссылку на лямбда функции из PHP 5.3, выложу еще раз http://wiki.php.net/rfc/closures Это крайне интересные возможности, я их уже протестировал в альфе PHP 5.3. Цитата(lukas @  27.8.2008,  08:31 ) оторые скорее всего реализованы через колбек функции... Давайте определимся термином "callback функция".  В общем случае callback функция - это делегат(ссылка на функцию, строка/массив с именем функции) с конкретным определенным заранее набором параметров и возвращаемым типом. Т.е. к примеру любая callback функция для preg_replace_callback() имеет единственный параметр - массив и возвращает строку. Имея ссылку на такую функцию можно с уверенностью вызывать ее с заранее известным набором параметров. Правильно? Теперь события, события вызывают т.н. обработчики событий - собственно то, ради чего они и нужны. Обработчик событий, в общем случае, - это тоже функция с двумя параметрами: объектом в котором произошло событие и набором аргументов с которыми оно вызвано. Т.е. получается, что все event handler-ы это частный случай callback функций, а значит можно спокойно утверждать, что механизм событий использует вызовы callback функций. Цитата(Mal Hack @  27.8.2008,  00:25 ) С какого момента это стало возможно? ArrayAccess появился в PHP 5.0. Остальное, вроде бы, и в PHP 4 возможно. Магический метод __invoke() будет в PHP 5.3 Самого класса Event, конечно же, в PHP нету  Это реализуется своими силами. Цитата(awers @  27.8.2008,  12:02 ) Организовать подобие полноценного ООП на пхп можно, но сложно. Раньше было сложно, сейчас намного проще. Думаю, что вскоре уже можно будет сказать, что в PHP реализовать ОО модель так же просто, как и в C# или Java (если, конечно, исключить задачи требующие многопоточности). Цитата(source777 @  27.8.2008,  12:12 ) Да и чего уж там,  даже C# & Java тоже не дают полной встроенной поддержки ООП. Да. В .NET почти весь фреймворк написан на самой .NET, т.ч. в этом плане можно сказать, что в PHP даже больше внутренней реализации

Автор: Kipter 11.1.2009, 02:15

Народ, ей богу вы развели просто Болтологию и не более того! Какие нафиг события? Где вы видели что в парадигме ООП - ключевой частью являеться наличие событий? События в программирвоании это вообще всего-лишь абстракция! Все это Callback вызовы красиво завернутые Фантиком. Этим Фантиком может быть что угодо библиотека С++, язык C# и т д. Если говорить о ООП языках.... да в идеале их вообще не существует! Все языки программирования где есть ООП, в них ООП это абстракция! На выходе мы получаем все тотже машинный код. Да и вообще программирование само по себе это абстракция. Вся истина в бинарном коде! Идите пишите на нем веб движки  пробивая перфокарты дыроколом, и потом грузитесь с них. И это вам будет истинная реалистичность кодинга =) и материальность =) И жизнь если вам так угодно... коли вам обьекты неживые    Смысл ООП именно в "новом" уровне Абстракции программирования! Это не технология! Это инструмент позволящий делать код приложения визуально более структурным и логичным. Есть ли смысл применять ООП в ПхП?  - мое личное мнение... если проект бошльшой и если ты рабоатешь над проектом не один, в команде или если с твоим кодом прийдеться работать кому то другому - то ДА.

Автор: 02077461 11.1.2009, 12:12

Цитата(Kipter @  11.1.2009,  02:15 ) Смысл ООП именно в "новом" уровне Абстракции программирования! Это не технология! Вы отчасти правы, это далеко не технология, а всего лишь шаблон программирования.  Цитата(Kipter @  11.1.2009,  02:15 ) Есть ли смысл применять ООП в ПхП?  - мое личное мнение... если проект бошльшой и если ты рабоатешь над проектом не один, в команде или если с твоим кодом прийдеться работать кому то другому - то ДА. Перечисленные критерии не отображают действительности. ООП нужно использовать тогда, когда можно получить отдачу от применения этого паттерна. Пусть проект будет маленький, над ним будет работать один человек, но он поймет, что ООП использовать стоит.  Использование ООП в PHP обусловленно распространенностью PHP как платформы, и удобностью принципов ООП для увеличения скорости разработки. Ну а разговор про делегатов в данной теме -- вообще не вызывает ничего кроме улыбки.

Автор: KonstRuctor 17.1.2009, 19:30

Ребята, извините, что встреваю в тему. Мне мой вопрос показался уместным именно в этом обсуждении. Суть такая: я пользуюсь в своих проектах тремя классами: работы с mysql, авторизации юзеров и аплоада картинок. Все эти классы я использую написанные кем-то, работать с ними умею. Проблема: хочу научиться писать классы самостоятельно. Нашел несколько книг, но одна из них очень сложная, ничего не понятно.  Другая книга в принципе о PHP, где пара страниц о классах. Что порекомендуете почитать, чтобы научиться писать свои классы самостоятельно? Спасибо

Автор: bars80080 17.1.2009, 19:46

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

Автор: krundetz 18.1.2009, 07:00

Цитата(bars80080 @  17.1.2009,  19:46 ) само понятие класса объясняется в одном абзаце на примере класса автомобилей, конкретного жигулёнка в качестве экземпляра, цветом, номерным знаком и максимальной мощностью двигателей в качестве свойств и движении вперёд, назад, открытии капота, включении музыки в качестве методов. работа с классами расписывается на двух страницах, плюс ещё на двух всякие методы наследования и переопределения. и всё тут ты прав, только не забывай что необходимо еще понимание как правильно с классами работать!

Автор: FoV 5.4.2009, 15:02

KonstRuctor,  Цитата Что порекомендуете почитать, чтобы научиться писать свои классы самостоятельно? Почитайте про http://ru.wikipedia.org/wiki/Шаблоны_проектирования, попробуйте разобрать какой-нибудь http://ru.wikipedia.org/wiki/Фреймворк

Автор: Elfet 5.4.2009, 19:05

Где не нужно использовать ООП, там его не нужно использовать

Автор: Aliance 20.4.2009, 15:07

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

Автор: IZ@TOP 21.4.2009, 18:07

Цитата(Aliance @  20.4.2009,  16:07 ) Скажите, я упорно не понимаю: зачем нужна инкапсуляция, кроме как для скрытия в абстрактном классе свойств, не требующих наследования. Ведь, как в той же Java, никакой безопасности инкапсуляция не несет. Поправьте если не прав.  Хотел сказать своими словами, но лучше чем в википедии не скажешь: Цитата Предостережение: Одна из наиболее распространенных ошибок — делать сокрытие реализации только ради сокрытия. Целями, достойными усилий, являются:     * предельная локализация изменений при необходимости таких изменений,     * прогнозируемость изменений (какие изменения в коде надо сделать для заданного изменения функциональности) и прогнозируемость последствий изменений. Образ в пример: ложка опущенная в стакан, не меняет его свойств и не становится частью стакана, хотя и помогает пить из него чай; в то же время, сахар, растворенный в чае с помощью ложки, делает его сладким. Часто инкапсуляция может быть достигнута простейшими организационными мерами: знание того, что «вот так-то делать нельзя» иногда является самым эффективным средством инкапсуляции! http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%BA%D0%B0%D0%BF%D1%81%D1%83%D0%BB%D1%8F%D1%86%D0%B8%D1%8F_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

Автор: Aliance 22.4.2009, 08:04

IZ@TOP, Ну фактически это и есть мои слова, только более развернуты. А если я пишу "статический" класс, не подразумевающий наследование - тогда получается инкапсуляция излишняя?

Автор: SureGOOD 22.4.2009, 11:24

нет, прежде всего это хороший тон программирования)привыкайте объявлять методы и свойства класса, как private, если ситуация не требует обратного, так и у читающего ваш код будет меньше вопросов

Автор: Aliance 23.4.2009, 16:09

SureGOOD, тон программирование - это не причина, а следствие. Меня интересует причина. Можете ее назвать? Как следствие ("так надо и все тут" или "а в яве все так делают") и я всем говорю. Но когда меня спрашивают а какой от этого выигрыш, то ответа четкого у меня нет, кроме как наследование. Но этого явно не достаточно.

Автор: IZ@TOP 23.4.2009, 17:37

Aliance, хороший тон, это не следствие, это необходимость  Это как умение есть используя столовые приборы, а не руками. Еще одна причина - это ограничение свободы, возможностей. Как гласит закон Мерфи - если что-то может быть сделано не так, оно будет сделано не так. Потому и надо ограничить возможность выбора, что бы нельзя было сделать никак, кроме того, как это подразумевалось.

Автор: SureGOOD 24.4.2009, 15:40

это прежде всего структурированность, что влечет за собой более читабельную запись кода, можно как бы и просто функции, но либо они будут большими, что уже недопустимо, либо много маленьких, которые не будут объединеныЮ вот и все) Добавлено через 5 минут и 25 секунд ###) не по теме ответил) сорри) а вообще, зачем закрывать доступ извне это предотвращение нестандартных ситуаций, всегда лучше предусмотреть все варианты и избежать ненужных, а это отличный, простой и верный способ, к тому же, тот, кто будет читать ваш код, будет уверен, что ничего изменяется извне, если это не предусмотренно внутри класса

Автор: 02077461 24.4.2009, 16:32

Вообще, если говорить об ООП в РНР, это -- конечно же -- убожество.  Нет, действительно, в РНР есть понятие интерфейса и даже ввели типизацию параметров (кстати, мне было любопытно услышать, что вызов функции с типизированными параметрами происходит значительно дольше чем обычной, и тем дольше чем больше типизированных параметров), но те, кто понимает как это использовать не пишут на РНР. Ну а вообще, безусловно, все зависит от задачи: если хочется разобраться с ООП, то от РНР нужно уйти в этом случае.  Кстати, плюс ООП подхода в любом скрипте -- возможность думать на уровне ОБЪЕКТОВ, а не переменных. Например создаем класс image, этом классу присущи свойства (размер, плотность, ...) и методы (повернуть, отразить, ...). Создаем объект типа image -- и мы можем передавать его например как парамерт, выполнять с ним присущие именно ЭТОМУ ТИПУ действия.  Вообщем, это просто удобнее, но еще нужно воспитать такое восприятие.  ПС: если повторяю чьи-то слова, то прошу прощения -- не специально.

Автор: nerezus 25.4.2009, 00:46

Цитата но те, кто понимает как это использовать не пишут на РНР.  Ты не прав =) PHP — это инструмент, а не тест на IQ и т.д. Цитата если хочется разобраться с ООП, то от РНР нужно уйти в этом случае.   Ты не прав.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)