25 февраля 2011 г. 12:52 пользователь Andrey N. Oktyabrski
<ano@bestmx.ru> написал:
On 02/25/11 12:02, Dmitriy Igrishin wrote:
Итого: выразить концепции проекта в виде классов и связей между
ними можно - это просто разработка ER-модели. Определить
полиморфные типы - то есть фундаментальный смысл
ОО-проектирования непосредственно нельзя (можно, как в Си,
но это того не стоит :-)
Что понимается под "непосредственно" и под "как в Си"?
Под "непосредственностью" здесь понимается использование средств,
которые делают использование стиля ОО-проектирования
удобным (простым, надежным и эффективным). Если же для выражения
этого стиля (написания программы) при использовании той или иной
платформы (или языка) требуются чрезмерные усилия либо
мастерство, то такая платформа (язык) не позволяет произвести
такое выражение непосредственно, а значит, просто не поддреживает
технику ОО-проектирования/программирования.
create table A (id int, name text);
create table B (txt text) inherits A;
select id, name from A;
Выбраны все записи как из A, так и из B. Чего тут сложного-то? Никаких чрезмерных усилий :-)
Или это не о том?
Пример является надуманным. Даже имена выбраны так, что понять
их предназначение невозможно.
На практике же, когда анализ предметной области выявляет концепции
проекта, следующим шагом после установления связей между ними,
является определение операций над этими концепциями. И если две
концепции связаны наследованием, то последнее не очень полезно
без полиморфизма.
Так вот определить полиморфные операции непосредственно в
PostgreSQL (в том же PL/pgSQL) невозможно. Возможно только
прилагая большую сообразительность и мастерство.
Что касается понятия наследования, реализованного в
PostgreSQL (INHERITANCE clause). Принимая в расчёт ограничения,
указанные в
Разве что только для выборки из всех таблиц, олицетворяющих
производные классы, через таблицу, представляющую базовый класс
для них? Принимая
--
// Dmitriy.