Форум PHP

Доброго времени суток! Разговаривал на работе с нашим программистом насчет ООП, показывал ему свои коды...... Правда он десктопный программист, но он мне указал, что хоть у меня и используются классы и объекты, подход все равно процедурный..... Он сказал, что все должно быть объектами..... Что ситуация, когда метод возвращает массив с данными, а не массив с объектами - это все процедурно и т.п.... Вот значит есть простая задача...... отобразить список товаров с кратким их описанием.... Раньше у меня был класс каталог, в котором был метод, выполняющий данную задачу и возвращающий массив с данными....... Но потом я понял, что это реально процедурно..... т.е. просто функция упрятана в класс и все...... Сейчас пришла в голову идея сделать так........ но есть ГРОМАДНЫЕ СОМНЕНИЯ...... ИТАК......

class goods{
private $id;
private $name;
private $price;
private $short_description;
private $full_description;
private $features_table;

public function __construct($id){
$this->id=$id;
}

public function get_short_info(){
$query="call short_info($this->id)";
$connect=dbhandler::SELECT($query);
$row = $connect->fetch_array();

$this->name=$row['name'];
$this->price=$row['price'];
$this->short_description=$row['short_description'];
}

public function get_full_info(){
// сейчас это неважно, но этот метод добывает подробную информацию о товаре и используется на странице самого товара
}
public function __GET($var){
return $this->$var;
}

}

class catalog{
private $param1;
private $param2;
..... etc

public function __construct ($param1, $param2, .......etc){
// стандартная иницализация......

}
public function get_goods_list(){
$query="call goods_list ($param1, $param2, ..... etc)";
$connect=dbhandler::SELECT($query);
while ($row = $connect->fetch_array()){
$goods=new goods($row['id']);
$goods->get_short_info();
$return[]=$goods;

}
return $return;

}
}

ну и клинетский код соответственно...

$catalog=new catalog ($param1, $param2, ..... ect);
$objectarray=$catalog->get_goods_list();


Плюсом данного подхода я вижу то, что все данные о товаре (цена, название и т.п.) сосредоточены в одном классе goods... В прежнем варианте они присутствовали также в классе catalog и получалось, что многое дублировалось с классом goods.....
Но есть, как мне кажеться, минус........ Нетрудно заметить, что когда фетчится список id товаров, то на каждой итерации создается экземпляр goods и происходит обращение к БД уже за кратким описанием и т.п..... Мне всегда казалось, что выполнять запросы цикле - это дико плохо и ресурсозатратно. Собственно 2 главный вопроса.....

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

Вы имейте еще в виду, что у него объекты живут долго и они все принадлежат пользователю, а у вас объекты живут мало и каждому пользователю создается набор новых, даже если речь о статических классах, которые должны быть распределены между всеми - новый запрос, новый набор.
1. Имеет.
2. Лучше избегать, но ООП вас будет толкать именно на этот путь, оно вообще не для скорости и не для СУБД. Как и наоборот... однако гибкость SQL лучше бы не терять.

Спасибо за ответ! Вы не поверите, но вариант с запросом в цикле работает быстрее. Правда я пока не оптимизировал запросы, но выигрыш получается за счет облегчения одного запроса (ему надо теперь делать только select id вместо всего набора атрибутов) и за счет легкости другого (там хоть и все атрибуты дергаются, зато where id=параметру)....... Специально поставил большое количество, которого в реальности не будет и проверил.... Скрипт с одним запросом работает примерно 3,5 сек, а скрипт с "запросом в цикле" около 2 сек. Ну да ладно.......... У меня возник другой вопрос.......

FUNCTION __TOSTRING()... ДА или НЕТ?

Как он сочетается с MVC? и даже если абстрагироваться от этого шаблона.........Вы в своей практике применяете этот метод? Ну вот возьмем тот же класс GOODS.... Если там реализовать этот метод. Конечно же не в самом методе писать HTML, а подключать и парсить соответствующий шаблон.
Ну а чтобы отобразить список, в главном шаблоне достаточно в цикле написать echo $obj;
Плюсом опять же вижу то, что не надо передавать параметры, все рядом, все наглядно... и я знаю, что этот код относиться именно к этому классу....... Но плохо то, что этот класс вроде как модель, а мы тут отображение приплетаем(((.

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

2. Группировать по действиям..... а именно.... получаем данные всех сущностей, потом обрабатываем их, и только потом их все в строку и вывод на экран.........

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

>FUNCTION __TOSTRING()... ДА или НЕТ?
Да, и чем больше, тем лучше - вот это очень красивый ООП. Вообще ваши сложные объекты должны вести себя максимально приближено к тому, как ведут себя соседние не ООП-объекты.

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