Форум PHP

Доброго времени суток. Хотел узнать, насколько имеет право такой подход в организации классов.......

Class good{
private $id;
private $short_description;
private $full_description;
private $price;
// еще много много много полей...

public function__ construct($id){
$this->id=$id;
// далее мы вызываем метод из data acess object и ПОЛНОСТЬЮ заполняем ВСЕ ПОЛЯ.... текущий класс не знает о том, откуда берутся данные (файл или БД или еще откуда) этим занимается другой класс.......


}


// тут будут различные методы для работы с полями нашего класса....



}

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

1. Оставить так... забыть про экономию ресурсов и независимо от того, что клиентский код будет вытворять с этим объектом, заполнять данными ВСЕ его поля при создании.....

2. Вообще кординально пересмотреть подход.......

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

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

Напрмиер..... Класс товар (для страниц с кратким его описанием) от него наследуем товар (расширенный, для страниц с подробным описанием) а от него можно наследовать товар (для администрирования с возможностью изменения полей).......

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

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

я наверно совсем человек отсталый, но зачем это все нужно?
по моему мнению класс для работы с БД нужен для того чтобы уйти от конкретной СУРБД
во всех остальных случаях он нафик не нужен...
и кстати зачем разработчики РНР придумали mysql_fetch_object ?

ИМХО для того, чтобы объекты абстрагировались от способа хранения данных..... Чтобы проще был переход от БД к файлам или наоборот...... Объекты занимаются своей логикой, а их физическим хранением или выводом на экран или отправкой по почте или еще что угодно - занимаются отдельные классы...

чтобы объекты абстрагировались от способа хранения данных.....
я уже написал про смену одной БД на другую, смену БД на "файлы" я вообще не рассматриваю как вариант, ибо целесообразность крайне сомнительна, это примерно тоже самое что писать код под РНР3
ну дело ваше как поступать
главное что бы оказалось так, что кроме MySQL ваш код увидел бы еще что-либо
и хоть как-то оправдал эти всевозможные уровни оболочек

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

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

>по моему мнению класс для работы с БД нужен для того чтобы уйти от конкретной СУРБД
Не всегда, иногда удобно инкапсулировать в классы или функции-обертки генерацию исключений, что в ООП, да и обычной программе большого размера является серьезным подспорьем. Есть ряд задач, где построение обертки вокруг стандартных функций оправдано.