PHP + OOП - стоит ли это того?

pachanga · 16 Май 2002

PHP + OOП - стоит ли это того?

Народ, что думашь по поводу сабжа?

mvc_aaa · 16 Май 2002

Re: PHP + OOП - стоит ли это того?

думаю да

pachanga · 16 Май 2002

Re: Re: PHP + OOП - стоит ли это того?

Автор оригинала: mvc_aaa
думаю да

Давайте это разовьем!

Проблема в том, что очень много народу считает PHP несколько поверхностным, радующим многих горе-программеров легкостью применения...этаким языком сиюминутных решений. Сделал за 15 минут - обрадовался - забыл.
Разве это нормально? Да, когда не вылезал html и тут такое счастье в лице PHP привалило, будешь визжать от радости, мешая html с php как вермишель...
А если делал до этого по уму спроектированные OOП приложения, с этим мириться уже никак не можешь...

А вообще к чему весь этот hype? Дело в том, что у нас как бы своя web студия(мы слишком малы, чтобы светиться здесь своим именем). Имея по отдельности достаточный опыт работы в WEB, чтобы понять, что работа нарезки картинок и проч. красоты 5% от готовности сайта, мы порешили писать свою CMS(Content Management System). Насмотревшись, на различные решения(особенно приглянулась Saitistika и Zope), мы засучили рукава.

Делать свою CMS хотелось хорошо, а хорошо такие вещи без ООП писать нереально(я удивляюсь Saitistika, сколько гимору вложено в это дело!). Народ скажет, ну да, ООП на java и супер! Может быть. Только хостинг с Tomcat или Resin не особо распространен, а хотелось сделать как можно более универсальное решение, читай, PHP в завязке c Oracle(MySQL).

Не буду распространяться о тонкостях реализации, только без поддержки классов в PHP мы бы просто завыли!
Так вот в начале долгое UML проектирование, с применением шаблонов, а потом относительно быстрая реализация. Нам это дело дико понравилось!

Понятное дело применение UML несколько хромое - нельзя из PHP кода построить иерархию классов и наоборот, но это не столь важно. Должны же появиться однажды 3d parties, которые напишут, соотв. плаги для PHP под Rational Rose или Visio.

Не знаю, видели ли нет, PHPDoc, систему самодокументации, по принципу javadoc, написанную полностью на PHP с ипользованием грамотного ООП? Думаю, такие примеры скоро как грибы будут появляться...но не раньше чем разработчики изменят свое отношение к PHP.

Да и порой ребят с Zend трудно понять, то ли "avoid using classes", то ли "Zend Engine2's gonna improve classes handling substantially".

...и хотя CMS и по сей день в разработке(мало нас, мало...), мы наделали кучу побочных классов и извлекли уроки.

Этакий кавардак мыслей, но все же.

Ваше мнение?

mvc_aaa · 16 Май 2002

Re: Re: Re: PHP + OOП - стоит ли это того?

Да, мысли разные...

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

А понимание, как сказать... Нету школы нормальный, молодой язык еще сравнительно. Так думается.

nail · 16 Май 2002

К слову, есть программка для рисования UML, называется dia. Еще есть программка для преобразования UML диаграмм в код, которая называется dia2code. Так вот, она поддерживает PHP. Я ей реально пользовался. К сожалению, работает только в одном направлении. Построение диаграмм по коду, насколько я знаю in the works.
Только хочу сказать, что инструменты могут дать только 10% прирост производительности программиста - так говорят классики.

А насчет ООП в PHP - будем надеяться, что будет праздник, когда таки будет на всех хостингах PHP5.

nail · 16 Май 2002

добавлю, что работает оно на win тоже
с вопросами об урлах - к google

Код:

Может кто даст стоящие линки на подобную тематику, только не tutorials, типа my first jsp application!

пжалуста
http://www.javable.com/javaworld/11_00/02/

fisher · 16 Май 2002

давайте, тема крайне полезная

Originally posted by pacha

Давайте это разовьем!

давайте, тема интересная. собственно, я вижу 2 основных вопроса:
1. насколько криво реализовано ООП в PHP.
понятно, что по сравнению с Java не говоря уж о C++ всё скучно, но, может, и то, что есть - уже неплохо?

имхо, реализовано кривовато, но. одно время мы плотно работали с mod_perl'ом. все необходимые задачи решались достаточно просто, пусть это и не было ООП в числом виде. Разумеется, ни о каком сходстве с C++ или Java тут не идёт, когда класс - это пакет, то есть модуль

Так вот, может в плане проектирования ООП-подобного кода на PHP тоже есть золотая середина? когда пусть "не по-взрослому" но просто, элегантно, масштабируемо и работает?

2. насколько быстро PHP умеет работать со своими классами?
его можно перевести в практическую плоскость: покрывается ли в среднем проигрыш в анализе ООП-кода временами доступа к СУБД, ereg, preg и т.д.?

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

Originally posted by pacha

Не буду распространяться о тонкостях реализации, только без поддержки классов в PHP мы бы просто завыли!
Так вот в начале долгое UML проектирование, с применением шаблонов, а потом относительно быстрая реализация. Нам это дело дико понравилось!

то есть я не понял PHP-классы - использовались или нет? реализация - хрен с ней - интересен подход к разработке.

pachanga · 16 Май 2002

Re: давайте, тема крайне полезная

Автор оригинала: fisher

давайте, тема интересная. собственно, я вижу 2 основных вопроса:
1. насколько криво реализовано ООП в PHP.
понятно, что по сравнению с Java не говоря уж о C++ всё скучно, но, может, и то, что есть - уже неплохо?

Так вот, может в плане проектирования ООП-подобного кода на PHP тоже есть золотая середина? когда пусть "не по-взрослому" но просто, элегантно, масштабируемо и работает?

Насколько криво?

1) Сами разработчики из Zend говорят, что каждое обращение к методу или свойству класса схоже с использованием eval();

2)Нет таких понятий как public,protected, private... будет в PHP5

3)Нет множественного наследования, а кому оно нужно?

4)Конструкторы есть, но они своебразны, а вот деструкторов(в PHP5 будет) вообще нет, порой это надо, хотя сейчас PHP здорово справляется сам с очисткой памяти

5)Нет классовых констант(в PHP5 будет), тоже иногда не хватает

6)Нужно быть крайне внимательным с ссылками(хотя к классам напрямую это и не относится, но их часто юзаешь именно с разными объектами), так называемыми aliases, где нибудь & забыл поставить - проблемы обеспечены, жаль это они так и собираются оставить

Э..э. там еще есть минусы, которые я не помню, может кто напишет. НО! Инкапсуляция, наследование и полиморфизм работают! А чего еще не хватает?

Реально по скорости раза в полтора все будет тормозней, тут деваться некуда и это на самом деле не смертельно. Зато гимору впоследствие меньше.

2. насколько быстро PHP умеет работать со своими классами?
его можно перевести в практическую плоскость: покрывается ли в среднем проигрыш в анализе ООП-кода временами доступа к СУБД, ereg, preg и т.д.?

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

то есть я не понял PHP-классы - использовались или нет? реализация - хрен с ней - интересен подход к разработке.

Ну попробуй потестить какую-ньть ADODB с прямым обращением к MySQL через mysql_query - разница не будет ну очень дикой. Да и сам забьешь на эту разницу, учитывая то, что умеет ADODB.
А про ~10 запросов, ты загнул

Мы использовали(и используем) классы по полной программе. На стенке висит A1 с иерархией классов, только CMS

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

Но вот в кратце расскажу(кому интересно, могу подробнее), что родилось помимо во время реализации CMS:

Универсальная обработка форм - это проблема №1 для каждого php разработчика. Знаем, знаем есть уже готовые классы - обработчики форм, только ни хрена не гибко они написаны.
Написали свой класс для работы с формами, причем расширять его можно бесконечно: каждый элемент формы - отдельный объект. Захотелось, чтобы данное поле было только для int значений - переопределяй базовый класс и подрубай при инициализации формы. Или скажем, "данное поле только для дат, имеет кнопку выбора дат через javascript" - пожалуйста!
Вот, к примеру часть конечного кода:

PHP:

$pay_form_fields=
		array(
			'doc_type' => array(
					'module'=>'droplist',
					'title'=>Тип документа:',
					'options'=>array('rko'=>'РКО','pko'=>'ПКО'),
					'sel_option'=>'pko',
					'req'=>1,
					'cookied'=>1),
			'payer' => array(
					'module'=>'droplist',
					'title'=>'Житель:',
					'sel_option'=>-1,
					'cookie'=>1),
			'date' => array(
					'module'=>'date',
					'title'=>'Дата:',
					'form_name'=>'payment_form',
					'req'=>1),
			'category' => array(
					'module'=>'droplist',
					'title'=>'<A href="/add_category.php?'.$PHP_SELF.'">Категория:</A>',
					'sel_option'=>-1,
					'cookie'=>1),
			'descr' => array(
					'module'=>'inputbox',
					'title'=>'Описание:',
					'size'=>50,
					'max_len'=>50),
			'summ' => array(
					'module'=>'inputbox',
					'type'=>'numeric',
					'title'=>'Сумма:',
					'req'=>1,
					'size'=>7,
					'max_len'=>7));

$form = new verify_formex($pay_form_fields, 'cash_document');
...
$form->field_attribute('payer','options',$option_hash);
....

if(is_pressed('ok') && $form->validate())
{
...
}

echo $form->parse();

Или еще:

Нас долго досаживала проблема автоматической навигации на сайте. Причем, чтобы это было все гибко и расширяемо, в плане того, что скажем на одном сайте кнопочки с rollover, на другом просто текстовые ссылки, где bold'ом выделяется текущая.
Т.е. некоторая общая фунциональность кочует от сайта к сайта, а вот новыми переопределяются только декораторы ссылок. Или скажем, для данного проекта дерево сайта хранится в xml, а для другого в MySQL - и это тоже все настраивается, в плане того что за это отвечает определенный базовый класс, который можно унаследовать и определить необходимую функциональность для данного проекта.

Немного конечного кода:

PHP:

  <?
    	require_once( $DOCUMENT_ROOT.'/php.setup' );
		require_once( PHP_NAVIGATION_DIR_C.'nav_facade.class.php' );

		$parser = new nav_xml_parser( 'nav.xml' );

		$nav_facade = new nav_facade($parser, $PHP_SELF);
		$nav_facade->set_decorator(0, 'main');
		
		echo $nav_facade->parse_level(0, 1);

	$levels_count = $nav_facade->get_levels_count();
		if  ($levels_count >1){
			$nav_facade->set_decorator($levels_count-1, 'text');
			echo $nav_facade->parse_level($levels_count-1,1);
		}
	?>

Или вот:

Любой ISP поклонется в ножки, если весь сайт на статике

Мы так подумали, а ведь и впрямь глупо постоянно держать динамические файлы на серваке, конечно, если это не mod_rewrite. Подумали, нарисовали и реализовали систему обхода сайта с преобразованием динамики в статику, так и назвали dynastatic

, которая помимо своей основной обязанности еще применяет так называемые фильтры к статичному html, типа комментарии порезать, пробелы убить и проч., тоже все расширяемо.

Что-то наподобие вот этого:

PHP:

<?
require_once($DOCUMENT_ROOT.'/php.setup');

require_once(PHP_DYNASTATIC_DIR_C.'ds_facade.class.php');
require_once(PHP_DYNASTATIC_DIR_C.'ds_xml_parser.class.php');

$xml_parser = & new ds_xml_parser(BASE_DIR.'nav.xml');

$ds = new ds_facade($xml_parser);

$ds->add_filter('trimmer');
$ds->add_filter('commenter');
$ds->add_filter('links');

$ds->convert();
?>

....................

После такого PHP не подходит для ООП - киньте в меня камень!

pachanga · 17 Май 2002

Re: Re: давайте, тема крайне полезная

Народ, чего притих? Хоть кто-то со мной согласен или я ваще не прав

tony2001 · 17 Май 2002

Re: Re: Re: давайте, тема крайне полезная

Автор оригинала: pacha
Народ, чего притих? Хоть кто-то со мной согласен или я ваще не прав

просто народ сидит и тихо пишет объектно-ориентированный код на РНР.
вот я, например, этим и занимаюсь.

kvn · 17 Май 2002

Re: Re: Re: Re: давайте, тема крайне полезная

Автор оригинала: tony2001

просто народ сидит и тихо пишет объектно-ориентированный код на РНР.
вот я, например, этим и занимаюсь.

Истину глаголишь - амиго.
Реальный пример: PEAR (http://pear.php.net/).
Пишут люди и не жужжат..

Удачи всем.

pachanga · 17 Май 2002

Re: Re: Re: Re: давайте, тема крайне полезная

Автор оригинала: tony2001

просто народ сидит и тихо пишет объектно-ориентированный код на РНР.
вот я, например, этим и занимаюсь.

Как в той басне, типа, " а Васька слушает, да ест"

tony2001 · 17 Май 2002

Re: Re: Re: Re: Re: давайте, тема крайне полезная

Автор оригинала: pacha

Как в той басне, типа, " а Васька слушает, да ест"

а че тут разговаривать?
работать надо! писать код!
все недостатки ООП в ПХП давно уже известны (см. http://www.digiways.com/articles/php/phpoop/ ), ждем ZE2, а пока - не сидим сложа руки.

fisher · 17 Май 2002

Re: Re: Re: Re: Re: Re: давайте, тема крайне полезная

Originally posted by tony2001

а че тут разговаривать?
...
все недостатки ООП в ПХП давно уже известны (см. http://www.digiways.com/articles/php/phpoop/ )
...

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

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

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

pachanga · 17 Май 2002

Re: Re: Re: Re: Re: Re: Re: давайте, тема крайне полезная

Автор оригинала: fisher
лично я не очень понимаю, почему так много внимания уделяется проектированию классов для каких-то форм. конечно, всё дело в том, как устроен коллектив, но имхо верстать должен верстальщик, и он это сделает безо всяких классов форм. если говорить о билдере форм - это уже ближе к делу, но тогда возникает масса другой рутины. выигрыша в доступе к отправленным данным через объект-форму не вижу, хотя is_pressed это забавно . xml и прочие шаблонно-ориентированные подходы - это да, интересно. но лично мне на данный момент интереснее всего автоматизация доступа к объектам базы и связей между ними, чем и занимаюсь, ибо 90% SQL-кода можно руками не писать

Вообще-то шаблоны несколько другие имелись в виду

fisher · 18 Май 2002

может мы не поняли друг друга

Originally posted by pacha

Вообще-то шаблоны несколько другие имелись в виду

nav.xml - это у тебя что, не шаблон?
ты привел код из 3-х частей, одна часть - про формы, две остальные - с классами, которые парсят что-то xml-подобное и реализуют над этим какие-то операции, по-видимому на выходе имея готовый html для клиента. я имел ввиду их. если ты с чем-то не согласен - напиши поподробнее, а то мне лично непонятно, что тебе не понравилось

pachanga · 18 Май 2002

nav.xml - всего лишь информация о дереве сайта, всех его разделов. Это используется, чтобы полностью автоматизировать вывод навигации сайта.

А имелись в виду шаблоны проектирования(design patterns).

Потом, тот самый класс для работы с формами он не только просто парсит форму, а еще ее проверяет, что говорить, лучше глянь вот сюда:

http://www.capvidia.be/users/registration.htm

или сюда:

http://www.kostume.sura.ru/feedback.php

попробуй повводить разные ошибочные значения.
Как раз реализовано на нашем классе.

fisher · 18 Май 2002

затык

Originally posted by pacha
А имелись в виду шаблоны проектирования(design patterns).

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

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

pachanga · 18 Май 2002

Смысл прост: PHP и ООП - неплохо дружат, давайте писать хорошие приложения

nail · 20 Май 2002

У меня немного по-другому дело обстоит.
Меню сайта - не просто меню для навигации, а прежде всего стержень сайта, как предлагает паттерн Front Controller http://java.sun.com/blueprints/patterns/j2ee_patterns/front_controller/index.html

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

ссылка по теме: http://www.theserverside.com/patterns/thread.jsp?thread_id=11947

PHP + OOП - стоит ли это того?

Новичок

MvC of PHPClub

Новичок

MvC of PHPClub

nail

Guest

nail

Guest

накатила суть

Новичок

Новичок

TeaM PHPClub

programmer

Новичок

TeaM PHPClub

накатила суть

Новичок

накатила суть

Новичок

накатила суть

Новичок

nail

Guest