Отсутствие множественного наследования

← →
Juice © (2005-08-03 22:41) [0]

Почему, или в чем смысл, или какое обьяснение этому факту?

← →
Гаврила © (2005-08-03 22:43) [1]

Есть мама, у нее женские половые признаки
Есть папа - у него мужские
У ребенка должны быть и те и другие?

← →
Alexander Panov © (2005-08-03 22:47) [2]

Интересно, а если есть у обоих предков свойство "зеленые глаза", от кого унаследуется это свойство?

← →
Джо © (2005-08-03 22:48) [3]

> Juice © (03.08.05 22:41)

Потому что слишком много с ним проблем, которые можно было разрешить только на уровне синтаксиса. А идеология Паскаля, по моему, тем и хороша, что ограничивается строгим синтаксисом. В отличие от С++, где сам Страуструп ногу сломает :)
П.С. Для указания того, что один объект может выступать в разных "ипостасях" очень удобно использовать COM-интерфейсы.

← →
Гаврила © (2005-08-03 22:48) [4]

> [2] Alexander Panov ©

Если оба предка одноглазые - то от обоих

← →
Джо © (2005-08-03 22:49) [5]

> [4] Гаврила © (03.08.05 22:48)
> Если оба предка одноглазые - то от обоих

Тогда придется вводить новое понятие - половина свойства. :0)

← →
Alexander Panov © (2005-08-03 22:50) [6]

Интересно, а если есть у обоих предков свойство "зеленые глаза", от кого унаследуется это свойство?

← →
Гаврила © (2005-08-03 22:50) [7]

> [3] Джо ©

> очень удобно использовать COM-интерфейсы

Тоько COM тут ни при чем. Просто интерфейсы

← →
Alexander Panov © (2005-08-03 22:51) [8]

Интересно, а если есть у обоих предков свойство "зеленые глаза", от кого унаследуется это свойство?

← →
Джо © (2005-08-03 22:54) [9]

> [6] Alexander Panov © (03.08.05 22:50)
> Интересно, а если есть у обоих предков свойство "зеленые
> глаза", от кого унаследуется это свойство?

Вот-вот. Придется вводить новые синтакс. формы для указания конкретного предка для конкретного свойства или метода. Собственно, при имплементации интерфейсов (interfaces) так и приходится поступать. Но тут реализация не наследуется, так что это пол-беды.

← →
Джо © (2005-08-03 22:58) [10]

> [7] Гаврила © (03.08.05 22:50)
> Тоько COM тут ни при чем.

?

← →
Джо © (2005-08-03 23:29) [11]

> [7] Гаврила © (03.08.05 22:50)

Проведи небольшой эксперимент.
Создаем вот такое приложение:
program Project1; {$APPTYPE CONSOLE} begin ReadLn end.
Как видим, никаких модулей, кроме стандартного System не подключаем.
Запускаем, дожидаемся, пока выполнение дойдет до ReadLn и нажимаем Alt+Ctrl+M (меню View/Debug windows/Modules). В окошке "Modules" наблюдаем следующую картину:
ntdll.dll
kernel32.dll
user32.dll
gdi32.dll
advapi32.dll
rpcrt4.dll.

Теперь добавляем в приложение объявление интерфейса и класс, его реализующий. В uses по-прежнему ничего не добавляем. Проект:
program Project2; {$APPTYPE CONSOLE} type ISample = interface end; TSample = class (TInterfacedObject, ISample) end; var Sample: ISample; begin Sample := TSample.Create; ReadLn end.
Опять смотрим модули - и о чудо! :) К нашим старым знакомцам добавилось:
OLEAUT32.dll
ole32.dll.
Вопрос: Ole-automation - имеет отношение к COM?
Так как реализована поддержка интерфейсов в Делфи? Неужто без участия технологии COM от Microsoft?

← →
Lamer@fools.ua © (2005-08-04 08:29) [12]

>Так как реализована поддержка интерфейсов в Делфи? Неужто без участия технологии COM от Microsoft?

AFAIK, без. Но интерфейсы Delphi совместимы с интерфейсами COM.

В System.pas есть только четыре функции, которые импортируются из oleaut32.dll (D6):

function SysAllocStringLen(P: PWideChar; Len: Integer): PWideChar; stdcall; external oleaut name "SysAllocStringLen"; function SysReAllocStringLen(var S: WideString; P: PWideChar; Len: Integer): LongBool; stdcall; external oleaut name "SysReAllocStringLen"; procedure SysFreeString(const S: WideString); stdcall; external oleaut name "SysFreeString"; function SysStringLen(const S: WideString): Integer; stdcall; external oleaut name "SysStringLen";

Как видно, ни одна из них к COM/OLE непосредственно не относится. Кстати, реально импортируется в данном случае (Project2) только SysFreeString.

Касательно ole32.dll: оная содержится в таблице импорта oleaut32.dll.

← →
evvcom © (2005-08-04 08:38) [13]

> Если оба предка одноглазые - то от обоих

Один глаз от одного, второй от другого. Получится полноценный ребенок! :-))

← →
tesseract © (2005-08-04 10:50) [14]

В Delphi используется RTTI которая может функционировать только с динамическими классами. А если заглянуть поглубже в механизм RTTI (RTFM),то множественное наследование оказывается совершенно либо невозможным, либо крайне проблематичным. Данный механизм в Delphi замещается другим - делегированием.

>>AFAIK, без. Но интерфейсы Delphi совместимы с интерфейсами COM.
Да Delphi COM использует по полной. Базовый класс Tobject содержит всё необходимое для работы с COM (или Cross-Platform Com). Любой VCL-компонент можно превратить в ActiveX за пару кликов мышкой.

← →
DiamondShark © (2005-08-04 11:51) [15]

> Почему, или в чем смысл, или какое обьяснение этому факту?

Вы не стали алкоголиком. Какое объяснение этому факту?

← →
Гаврила © (2005-08-04 12:19) [16]

Ну да, совместимо, но это детали реализации ,а не концептуальный принцип.
COM предполагает наличие некоего COM - сервера (неважно, какого вида)
который для данного случая необязателен.
Поэтому, имхо, при реализации такой схемы ,как предлагает Джо в [3] корректнее его не упоминать, а говорить просто об интерфейсах

← →
Джо © (2005-08-04 13:55) [17]

Да, похоже, я был не прав насчет COM-интерфейсов. Из oleaut32.dll, действительно импортируются функции для работы с WideString... Как-то никогда не задумывался над реализацией интерфейсов в Делфи, а примелькавшееся в Справке, к месту и не к месту употребляемое COM-interfaces, создало ошибочное предстваление. Спасибо, что поправили.

← →
Juice © (2005-08-13 13:54) [18]

До версии Delphi 5 включительно базовым классом интерфейса был IUnknown, но в Delphi 6 ему дано новое имя, IInterface, более точно указывающее на тот факт, что эта функциональная возможность языка совершенно независима от COM-технологии компании Microsof(которая использует имя IUnknow как собственный базовый интерфейс). Интерфейсы Delphi также доступны и в Kylix. (Марко Кэнту - Delphi 7 для профессионалов)

← →
Juice © (2005-08-13 13:55) [19]

> Да Delphi COM использует по полной. Базовый класс Tobject
> содержит всё необходимое для работы с COM (или Cross-Platform
> Com).

А что есть такой ?

← →
Anatoly Podgoretsky © (2005-08-13 14:36) [20]

В современных языках отказались от этого.

← →
AlexWlad © (2005-08-13 15:11) [21]

Многие Си-шники говорят : если в твоей иерархии появилось множ. насл. - хреновый ты проектировщик.

← →
Anatoly Podgoretsky © (2005-08-13 15:14) [22]

Это умные люди, которые редко встречаются.

Juice>>>До версии Delphi 5 включительно базовым классом интерфейса был IUnknown, но в Delphi 6 ему дано новое имя, IInterface, более точно указывающее на тот факт, что эта функциональная возможность языка совершенно независима от COM-технологии компании Microsof(которая использует имя IUnknow как собственный базовый интерфейс). Интерфейсы Delphi также доступны и в Kylix. (Марко Кэнту - Delphi 7 для профессионалов)
Почитай-ка лучше теЁрию про IUnknown, Iinterface, COM и ActiveX.
>>> Да Delphi COM использует по полной. Базовый класс Tobject
> содержит всё необходимое для работы с COM (или Cross-Platform
> Com).

Cross-Platform COM - типа COM, только как CORBA. Используется Mozilla / OpenOffice и ТП.

> Почитай-ка лучше теЁрию про IUnknown, Iinterface, COM и
> ActiveX

Да вот уже начинаю потихоньку, однако кажется что рановато еще. Не зря кстати говорят что это самый сложный аспект программирования в Windows.
> Cross-Platform COM - типа COM, только как CORBA. Используется
> Mozilla / OpenOffice и ТП.

Это Microsoft"овская разработка или нет? И отличается ли он от обычного COM в плане подходов программирования ? В двух словах если можно...

> Anatoly Podgoretsky © (13.08.05 15:14) [22]
> Это умные люди, которые редко встречаются.

Вобще-то ООП изобретено для "точной" симуляции наших представлений в жизни, а множественное наследие у нас, то есть - в нашей жизни сплошь и рядом:)

wnew © (14.08.05 00:53) [26]

Не для "..."точной" симуляции наших представлений в жизни...", для облегчения проектирования решений сложных задач. И никто не запрещает использовать, если язык позволяет. Просто слишком много разработчиков парились с М.Н. и их опыт говорит о "нежелательности" его применения.

> Почему, или в чем смысл, или какое обьяснение этому факту?

Язык так устроен. Иногда его (множественного наследования) не хватает, приходится искать обходные пути. Реализовывать каждый раз методы какого-либо интерфейса - скучно.

Интересный факт, но как раз COM интерфейсы поддерживают множественное наследование.

пример из реального кода:

TCasLP = class(TAutoObject, ICasLP)
т.е. реально работает. где-то читал в какой то ли книге то ли книге про данный механизм. И работает он только для интерфейсов.

tesseract © (15.08.05 10:48) [30]

> Интересный факт, но как раз COM интерфейсы поддерживают
> множественное наследование.

Это не множественное наследование.

Иногда мн. наследования действительно не хватает, причем есно множественного наследования интерфейсов классов.

Множественное наследование реализации легко заменяется агрегацией, но как сказал ИШ, тоскливо для методов агрегируемых классов прописывать делегирующие методы.

Интерфейсы (ключевое слово interface) я тоже недолюбливаю (хотя и пользуюсь) - семантика подсчета ссылок не всегда для меня ясна. К тому же бывают проблемы, когда мешаешь объекты с интерфейсами.

Поэтому пользуюсь способом агрегации + создание делегирующих методов к методам агрегируемого класса или открытие доступа к агрегируемому классу.

ЗЫ. Эх, сделали бы в дельфи как в java - объект и интерфейс "живут" по одинаковым законам. Другая бы жизнь началась :)

Отсутствие множественного наследования Найти похожие ветки