Форум Flasher.ru - Ищу мастера...(вопрос не коммерческого плана)

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- PHP (http://www.flasher.ru/forum/forumdisplay.php?f=20)

- - Ищу мастера...(вопрос не коммерческого плана) (http://www.flasher.ru/forum/showthread.php?t=50982)

Ищу мастера...(вопрос не коммерческого плана)

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

Спасибо...

Лидер. Ты лидер.

слабо что-ли

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

на самом деле практика показа, что использование ООП не прибавляет скорости, а даже скорее наоборот - уменьшает ее. Все-таки в скриптовых языках ИМХО надо использовать ооп ограничено.По крайней мере в пхп. У меня была ситуация - надо было реализовать дерево объетов. При реализации с использование ооп и при реализации того же самого на ассоциативных массивах победа в скорости была в 5 раз в пользу последней реализации :))
(Уровней в дереве было пять у каждого объекта ~5 свойст и 5 методов. Объектов всего ~20 000)

вот такая ситуевина.... если у кого лучше получалось - поделитесь.

Ты хочешь сказать что массив в 20000 элементов будет работать быстрее?

juggy
ты когда-нить видел ООП, нет, возьми релиз хотя-бы Делфи, и посмотри
, а я спрашиваю как это можно сделать в РНР,

П.С. лидер

да, в пхп - да. быстрее. проверено на практике.
вместо красиво ООП'а пришлось кодить на массивах, что не придает прозрачночти и красоты коду :)

2 Elmir:
если тебя интересует именно КАК выглядит ООП во флэше - могу скинуть документацию по пхп. правда на английском. там есть описание с примерами по ООП.

2 Elmir: опечатка!!! ООП в пхп, сорри. :)

2 juggy :
массив ассоциативный
на самом деле там не одномерный массив из 20000 элементов а многомерный. если это важно конечно.

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

Более существенным является несколько иное: Объектно Ориентированное Проектирование. Увы, в русском языке оба термина сокражаются одинаково -- англичанам с их OOD/OOP повезло больше. Соответственно, ниже в тексте под термином ООП я буду иметь в виду именно проектирование.

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

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

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

В принципе, никто не мешает по объектной модели написать программу на паскале образца 1970г или на Plain C. Однако использование для этого ОО-языка уменьшит фактические расходы на воплощение модели.

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

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

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

Кстати, весьма рекомендую сходить сюда: http://www.phppatterns.com/

2 Crazy : с руками как и с головой все в порядке. так что, ваша язва пролетела мимо :D

Итак. Взял и рандомом засунул в базу 10.000 значений в виде

PHP код:


		
			
$sql = "CREATE TABLE `test` ( `id` INT(11) NOT NULL AUTO_INCREMENT PRIMARY KEY, `parent` INT(11) NOT NULL, `title` VARCHAR(200) NOT NULL, `sub1` VARCHAR(200) NOT NULL, `sub2` VARCHAR(200) NOT NULL );";

Дальше взял и вывел это дело посчитав время.
Результат: 2.73

Потом взял и захреначил это всё в массивы и вывел.
Резельтат: 2.89

Разницы - секунда.

2 juggi: а при чем здесь база данных? мы говорили про ооп в пхп.

! JUGGY !

А получал я по-твоему что?

ооп в пхп подрузамевает использование конструкций вида
class......
.....extends....
this->......
в твоем посте об этом речь не шла

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

Цитата:

Оригинал написал(а) mishinaelle
2 Crazy : с руками как и с головой все в порядке.

May be.

Цитата:

так что, ваша язва пролетела мимо :D

Да нет, она просто летает кругами в ожидании публикации кода. :)

я вполне понимаю что подразумевает ООП в ПХП;-)

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

PHP код:


		
			
<?

class DE 

{

  var $variable = "Название которое мы взяли из Базы Данных";

  var $desc1 = "Первое рандомное описание";

  var $desc1 = "Второе рандомное описание";



    function generate(){

        while($i<10000){ // У нас всего 10000

                echo $this->variable;

                echo $this->desc1;

                echo $this->desc2;

            $i++;

        }

    }



}

$de=NEW DE();

$de->generate();

?>

мне кажется что скорость сильно будет зависеть от сложности объекта.

предтавь такую архитектуру:
на первом уровне стоят все буквы алфавита от А до Я
на втором уровне у каждого узла появляется некоторый набор букв из алфавита и т.д.

то есть если идти от корня дерева по любой цепочке - получаем слово

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

например, вывод цепочки узлов одной длины.

А зачем объекты в описанном алгоритме? :)

2Crazy: эта штука была описана для примера.

А разумные примеры есть? :)

juggy
хыхыхыхыыыыыыыы

1. Насчет ООП и ПХП - забудьте. Только там, где это необходимо или там, где хочется и можно или хочется очень.
2. Сам я первым правилом пренебрегаю.
3. Джагги ты не прав.
потому что для большинства известных мне языков:
1. есть массив
2. есть объект
3. физически данные расположены в одном и том же месте (доупстим память)
4. при работе с элементами массива ты тратишь время на то,чтобы узнать, гле записаны элементы и найти отедлно взятые и из памяти вытащить значения тех самых байтов, полубайтов
5. при работе с объектом, экземпляром объяекта, экземпляром объекта который сам является объектом итд итп тебе нужно еще - обращаться к другим данным хранимым в том же месте. чтобы узнать, где именно размещены данные, как и с чем они логически связаны.
6. то есть в данном случае мое пояснение базируется на заявлении "ты находишься "уровнем выше"".
7. Согласен?

Nirva, твои рассуждения имею тонкое место: в PHP массивы означают вовсе не то, что массивы в C. В PHP, где типы данных более специфичны, есть массивы и хэши. Массив в PHP есть комбинаци обоих этих типов.

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

крейзи... я смотрел код пхпшных функций... конечно, не объектов, я тут до сих пор levenshtein()'a копаю, преподов своих по дсикретке достаю. =) но веь то же самое, пхп строку - в ту же сишную строку. Разве не так?

Цитата:

Оригинал написал(а) Nirva
но веь то же самое, пхп строку - в ту же сишную строку. Разве не так?

Если я правильно понял твой вопрос, то не совсем то же самое. К примеру, в C доступ к символу по номеру позиции в строке -- операция быстрая. В PHP -- долгая, сравнимая (если не более долгая) с вызовом substr.

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