Зачем те это?

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

Всмысле зачем? Ну оптимизация кода,что б самому не писать запросы,а что б программа автоматом их строила. И к слову, мне так "учитель" сказал,а я думаю г*вна он не скажет. Другое дело, реализовывать мне.


linker,Я рад, что Вы откликнулись,спасибо! Право, ООП почитать я бы додумался(простите,если грубо сказал). Я хочу на форуме найти вариант решения от людей. Но если Вам нечего добавить, то и на том Вам большое спасибо!

Я так подразумеваю, что программист не ручками пишет "select * from table", а метод некоторого класса сам строит запросы, основываясь на переданных параметрах.

alexeyfenix
Не обижайся, но там реально все переписывать. Зачем целые отдельные классы для добавления, для редактирования, для удаления и пр. Если бы у меня было больше времени, я бы рассказал как лучше сделать... ну может еще расскажу.

Linker,Всё правильно понял,именно это мне и нужно. Я не боюсь все переписывать, вы можете хотя бы дать направление с чего начать перепись?А переписыванием займусь я сам. С чего начать операцию "ломать-строить"?

Надеюсь,расскажете, мне было бы кстати.

В дополнении к заданию, может это поможет.
Вот что мне дословно сказали сделать

alexeyfenix - ты пойми одну простую вещь... Прежде, чем ты сделаешь какой-либо "автоматизатор" создания запросов, ты должен уметь полностью написать их вручную.

А у тебя пока так и не прозвучало (хотя я прямо спрашивал): а что же должны делать эти запросы? Например, СЕЛЕКТ. Что он будет выбирать? Простая выборка будет, какой-то ДЖОЙН или еще что-то? Если возможны разные варианты, то как твоя система узнает, какой именно тип запроса строить надо?

В данный момент твой вопрос звучит примерно так: мне тут задание дали, я нифига не понял, а вы мне тут скажите, что сделать, чтоб работало.
Нет уж Сначала ты сам пойми, что ты должен получить в итоге. Какие именно запросы.

PS. По твоим ссылкам не ходил и не хочу туда идти. Потому что ты сам должен тут что-то "членораздельное" сказать. Только тогда тебе ответ дать можно будет.

А таблицы будут создаваться в базе тоже через твою прослойку?

sergeiss, У меня есть 4 запроса. Select(для выбора и вывода),insert(добавление),delete,update.
Если Вы не ходили по ссылкам, обьясняю. У меня есть классы ввода,вывода,удаления, обновления. Теперь нужно создать свойство класса, которые,как уже сказали,цитирую

Объясню, упрощенно, как оно у меня.
Что есть таблица? Контейнер, т.е. объект, который может хранить внутри себя другие объекты. Что умеет этот контейнер? Выбирать, добавлять, удалять, изменять объекты внутри себя. Контейнер может хранить внутри себя объекты определенного класса (таблица) или любого другого (xml, например).
Приведу пример, своей абстракции, допустим есть таблица-контейнер UsersContainer, которая хранит объекты класса пользователей, где поля таблицы - это поля данного класса. Допустим, я хочу получить из этого контейнера некоторого пользователя, у которого поле Login='user', а поле Password='1234'. Я пишу

$User = $UsersContainer->apiGetObject('ClassUser', array('Login' => 'user', 'Password' => '1234'));

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

$User = $UsersContainer->apiGetObject('ClassUser', array('Login' => 'user', 'Password' => '1234'));

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

SELECT * FROM Users WHERE Login='user' AND Password='1234'

, то для второго контейнера

//*[child::Property[@Login="user"] and child::Property[@Password="1234"]]

Вот как бы так. А уж динамически составить SELECT на основе array('Login' => 'user', 'Password' => '1234') ты должен уметь сам, плюс куча вариаций и прочего.

linker, спасибо, за пример! Боюсь только что понял я из этого не много. Первые два кода что-то типа запроса на коннект и получают результатом "обьект пользователей".(зачем.моя дурная голова не может понять)

Текст после второго кода понял,только пример после него не очень. Обычный запрос, второй не знаю даже что это. А где наследование и динамическое изменение свойства класса?(из 1 свойства класса в селект, делит, апдейт и т.д.)

П.С. За пример еще раз спасибо, но что делать я так,дурак.и не понял.Можно подробнее(для дибилов)

НУ вот представь себе абстрактный контейнер, туда можно добавлять объекты, удалять, изменять существующие и пр. Вывод, нужен абстрактный класс, который будет определять какие методы должны будут реализованы в классах наследниках. Какие методы:
1. Получение объектов, т.е. некий SELECT (для БД, в моем случае apiGetObject)
2. Добавление, т.е. некий INSERT (в моем случае apiAdd)
3. Удаление, т.е. некий DELETE (в моем случае apiDelete)
4. Обновление, т.е. некий UPDATE (в моем случае apiUpdate)
Это минимум. Естественно, все это накладывает некоторые правила на хранение этих объектов в контейнере, например, у объектов должно быть обязательное поле Id (идентификатор).

abstract class Container
{
    abstract public function apiGetObject($ClassName, $Properties = array());
    abstract public function apiAdd($Object);
    abstract public function apiDelete($Object);
    abstract public function apiUpdate($Object);
}

Вот, шаблон есть. Что есть таблица? Это контейнер, значит смело пишем

class Table extends Container
{
   ... // своя реализация методов предка
}

Что есть XML? Это контейнер, значит смело пишем

class Xml extends Container
{
   ... // своя реализация методов предка
}

Допустим есть таблица с пользователями и есть XML-файл с теми же пользователями. А также описан некий класса пользователей

class UserClass
{
    public function __construct($Properties = array())
    {
        foreach($Properties as $PropertyName => $PropertyValue)
        {
             $this->$PropertyName = $PropertyValue;
        }
    }
}

Задача, получить некоторого пользователя из таблицы с логином (UserLogin) равным 'user' и паролем (UserPassword) равным '1234'. Изменить ему пароль и сохранить в XML-файл.

$MyTable = new Table();
$MyXml = new Xml();

Получить пользователя. Какой метод использовать? apiGetObject(). По каким полям искать этого пользователя? UserLogin и UserPassword. Значит пишем.

$User = $MyTable->apiGetObject('UserClass', array('UerLogin' => 'user', 'UserPassword' => '1234'));

Что происходит? Вызывается метод контейнера-таблицы, который что-то делает и генерирует SQL-запрос вида

$Sql = "SELECT * FROM Users WHERE UserLogin = 'user' AND UserPassword = '1234'";

который, собственно и исполняет

$Result = mysql_query($Sql);
if ($UserRaw = mysql_fetch_assoc($Result))
    return new UserClass($UserRaw);
return null;

В хорошем результате получаем объект-пользователь. Меняем ему пароль на '4321'

$User->UserPassword = '4321';

Вставляем в XML. Вставка у нас осуществляется методом apiAdd()

$MyXml->apiAdd($User);

Я, конечно же опускаю очень много деталей, до которых ты должен сам доходить.

//разбираю код,позже отпишу

Не надо городить лишних классов.

Меня не было два дня(занимался отвлеченными делами от программирования)

Возник вопрос,зачем

PMA изобретаем?
linker