"sw" <[EMAIL PROTECTED]> сообщил/сообщила в
новостях следующее: news:[EMAIL PROTECTED]
Много копий и не только переломано на фронте R vs OO.
Но часто у сторонников этих подходов наблюдается какая-то крайность
взглядов.
Либо суют OO где не поподя, либо шарахаются от ООП - "не лучше мы
постаринке".
Пытаться совмещать - это тоже компромис не впользу обоих подходов.
Вот я подумал почему нельзя использовать некоторые приимущества ООП не
отходя от Коддовской теории.
Если в предметной области паралельно использовать оба подхода, для
"абстракции".
Например:
Таблица - Класс,
Столбцы таблицы - Поля объекта,
Процедуры для получения и записи строки таблицы - методы доступа
Процедура для обработки обной строки таблицы (удаление, изменение) - метод
объекта
Процедура выполняющая обработки связанные с данными таблицы - метод класса
Информация в метаданных - Поля класса
и т.д.
А ведь в принципе все равно для клиентского приложения где располагается
реализация ООП- в базе или в компонентах доступа к БД. В том же IBX ты
обращаешься к таблице через объект TIBQuery или более общее- TDataSet, поля
таблицы там- метод FieldByName, оперирование данными- процедуры append,
insert, edit, delete. В результате на клиенте ты _УЖЕ_ оперируешь объектами.
Если переносить эту логику на сервер, то необходимо реализовать "три кита"
ООП: наследование, инкапсуляцию и полиморфизм, иначе эта ООПовская
надстройка над реляционной моделью только мешать будет, не привнося в ничего
нового и полезного в разработку БД. Подумай, как будет реализовываться
наследование для таблиц-классов, что в наследнике-таблице будет происходить
со связями (форейн кеями)?
--
Каратаев Владимир.
