Объекты vs массивы

Nicki

Новичок
Объекты vs массивы

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

Сайт на футбольную тематику. Есть список стран. В каждой стране есть список чемпионатов (дивизионов). В каждом дивизионе список сезонов. В сезоне список туров, а в туре список матчей, в которых участвует 16-22 команды.

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

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

Если же отказаться от объектов, то можно просто при получении результата запроса от БД записывать сразу в массив, а не создавать объекты, и этот массив сразу передавать в смарти.

Как быть? Хочется и боюсь что будет тормозной код...
 

Nicki

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

Фанат

oncle terrible
Команда форума
Хочется пиать используя ОО подход от части в образовательных целях, и отчасти от того, что просто хочется именно на объектах.
Если же отказаться от объектов, то можно просто при получении результата запроса от БД записывать сразу в массив, а не создавать объекты, и этот массив сразу передавать в смарти.
Вечная дилемма пхп.

Ну, и вечная мотивация - "потому что хочется".
 

fixxxer

К.О.
Партнер клуба
PHP:
$a = array('foo' => 'bar', 'hello' => 'world'); // фу... массивы
$o = (object)$a; // ура объект!
 

melo

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

Nicki

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

Фанат

oncle terrible
Команда форума
Нельзя одновременно учиться и делать что-то пристойное.
Если ты учишься, то не надо тогда мечтать, что у тебя выйдет что-то путное. Парикмахеры тренируются на манекенах. А не на живых людях. Потому, что они вообще стричь не умеют ещё - только учатся.
А не потому, что ученик стрижет на полторы минуты дольше, чем мастер.

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

-~{}~ 14.07.08 16:39:

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

Nicki

Новичок
согласен...

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

Я в общем ждал подобный коментарий...
 

cranchzerro

Новичок
Но нужно ж на чем то учится и с чего то начинать?
ну ты учишься писать Объектно? ну вот и пиши с использованием ООП.
Или вопрос стоит скорее "следует ли предпочесть ООП подход процедурному, в ущерб (незначительный) производительности... если очень хочется объектами" - если хочется ООП, то однозначно стоит, только что юы после небыло таких последствий, как в моей, несколько похожей по инструментарию (объекты/массивы), но обратной по смыслу проблеме :
http://phpclub.ru/talk/showthread.php?s=&threadid=109227&rand=0
;)))
 

Фанат

oncle terrible
Команда форума
Да и о том, что у меня выйдет что-то путное, я тоже не сказал не слова...
ну вот раз не сказал, то и не вспоминай производительность. это не тот вопрос, который тебя должен волновать в первую очередь.
Хочешь учиться? Учись! Но тогда задавать надо другие вопросы. про идеологию, про смысл классов. А не мечтать, ковыряя в носу, что щас ты напишешь суперпортал, посещаемость повалит за 100 тыщ, надо заранее все оптимизировать!
 

Angerslave

Новичок
Забей на пхп и иди учить Java - вот там ООП. А в пхп что массивы, что объекты... Ну ещё чуть разбавлено уровнями доступа и в 5.3 - неймспейсами...
 

Nicki

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

Фанат

oncle terrible
Команда форума
Я вот сам давно мечтаю, чтобы кто-то подсказал хороший пример для использования объекта.
А то же ведь, как начинаешь думать - вся работа веб-приложения сводится к "достал массиы из базы - положил массив в базу". Ну, можно эти действия реализовать через объекты. Две штуки - объект для работы с БД и объект для отрисовки шаблона.

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

cranchzerro

Новичок
Автор оригинала: *****
Я вот сам давно мечтаю, чтобы кто-то подсказал хороший пример для использования объекта. А то же ведь, как начинаешь думать - вся работа веб-приложения сводится к "достал массиы из базы - положил массив в базу". Ну, можно эти действия реализовать через объекты. Но вот чтобы действительно понадобился какой-то объект, чтобы с ним действительно было удобнее - такого не могу придумать.
пример полезности от "объектов" для БД, но НЕ ИДЕОЛОГИЧЕСКИ ВЕРНАЯ панацея на все случаи жизни:
ORM - как технология, ну и например http://wiki.agiledev.ru/doku.php?id=ooad:dp:data_mapper как альтернатива доставанию и запихиванию массивов в БД

Беда в том, что те, кому удобен ООП, делают слишком большие вещи, в которых суть теряется за частностями.
... как например в JAVA или .NET (например, только одна работа с регулярками чего стоит)
 

maxwell

artifex
ООП это способ мышления.
Инкапсуляция, полиморфизм, наследование...
Ночь, улица, фонарь, аптека...

cranchzerro, чем вам регулярки в JAVA не нравятся?
 

cranchzerro

Новичок
cranchzerro, чем вам регулярки в JAVA не нравятся?
TIP: пример в скобочках был указан возле .NET

-~{}~ 15.07.08 13:28:

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