» Delphi: Interface'ы

Как их описывать и как они выглядят я уже знаю - вычитал из хелпа, но возник у меня такой простой вопрос (может быть глупый) - ЗАЧЕМ? объясните кто-нибудь, зачем они нужны, чем они лучше обычных class'ов?

Интерфейс позволяет любой программе получить доступ к твоему компоненту. Сам по себе интерфейс - это набор общедоступных функций процедур и т.д, которые предоствляет компонент для использования другими программами. Это всё относится к COM оринтированым технологиям. Если интересует более глубокое обьяснение смотри MSDN.

Попробуй почитать Дона Бокса
Наталью Елманову "Использование технологии СОМ в Делфи"
etc...

Добавлено
Еще есть такой автор как Бин Ли - в инете валом переводов

Спасиба, пойду искать Бина Ли ..

c0r0ner
Хм, а что интерфейсы только с COM связаны. Если я напишу в дельфи
[code]
ISomeInterface = interface
end;
[code]
то здесь будет что-то относящееся к COM?

Цитата:

Интерфейс позволяет любой программе получить доступ к твоему компоненту. Сам по себе интерфейс - это набор общедоступных функций процедур

Они ничего не позволяют и ничего не содержат, они просто регламентируют.

CHiF
Фактически, интерфейс дает тебе представление об объекте безотносительно его реализации. Таким образом, класс, реализующий некоторый интерфейс, как бы берет на себя контрактные обязательства по выполнению определенных функций, регламентированных реализованным интерфейсом. Иногда, интерфейс может вообще не содержать никаких методов, так называемый marker-interface. Тоже бывает полезно. Весьма красиво используется, например, в связке с фабрикой объектов. Более менее понятно? Или лучше на примерах?

Цитата:

Хм, а что интерфейсы только с COM связаны. Если я напишу в дельфи
[code]
ISomeInterface = interface
end;
[code]
то здесь будет что-то относящееся к COM?

Ну это вабще странное замечание.
COM (Component Object Model) — модель объектных компонентов — одна из основных технологий, на которых основывается Windows. Более того, все новые технологии в Windows (Shell, Scripting, поддержка HTML и т.п.) реализуют свои API именно в виде COM-интерфейсов.

Реализация интерфейса предоставляет доступ к COM-объекту. И создав интерфейс и реализовав его ты автоматически создаешь COM-объект.


Цитата:

Программист обязуется реализовать все методы, описанные в интерфейсе, и следовать требованиям, предъявляемым к реализации некоторых их них.

Компилятор обязуется создать в программе внутренние структуры, позволяющие обращаться к методам этого интерфейса из любого поддерживающего те же соглашения средства программирования. Таким образом, COM является языково-независимой технологией и может использоваться в качестве «клея», соединяющего программы, написанные на разных языках.

c0r0ner
Вот тут ты немного неправ! В отличии от Guderian
Интерфейсы действительно не являються неотемлимой частью СОМ технологии.
Их действительно можно создать без СОМ обьекта и использовать!

Только смисла в етом с гулькин хвост!

c0r0ner

Цитата:

Ну это вабще странное замечание.

Что странного? И не надо мне рассказывать про com и смежные технологии. На заданный вопрос лучше ответь. И если ты считаешь, что ISomeInterface в приведенном примере имеет что-то общее с COM, тогда приведи его GUID. Я же пытался объяснить, что всякий com-объект имеет интерфейс(ы), но не всякий интерфейс связан с com-моделью, как впрочем он может быть совершенно не связан с windows вообще. Например, интерфейсы в java. Таким образом, само понятие интерфейса, столпом ооп, конечно, не является, но одним из основных понятий, входящих в его парадигму - да.


Цитата:

Реализация интерфейса предоставляет доступ к COM-объекту.

Реализация интерфейса - это конечный класс, экземпляры которого ты можешь создавать. Никакого доступа никуда оно не предоставляет.


Цитата:

И создав интерфейс и реализовав его ты автоматически создаешь COM-объект.

Возьмем базовый интерфейс COM-модели, например, IUnknown или IDispatch. Какие объекты были автоматически созданы при их создании?


Цитата:

Более того, все новые технологии в Windows (Shell, Scripting, поддержка HTML и т.п.) реализуют свои API именно в виде COM-интерфейсов.

HTML не имеет API, это язык разметки, а не программирования. Наверное, ты имел ввиду DOM, DHTML, HTML Applications, etc...

Guderian
И долго ты сочинял эту лекцию?

Mamay

Цитата:

Только смисла в етом с гулькин хвост!

Почему же? Точнее так, при использовании COM это вдвойне полезно. Без него полезность ровно на том уровне для которого их выдумывали. Некоторые особо одаренные пишут исключительно на интерфейсах. В этом есть определенные преимущества, но до такого экстремализма я не доходил. Весьма активно используются и в жабе и в .net. Да и приведенные мною примеры с интерфейсом-маркером и фабриками объектов очень часто имеют место быть.

Добавлено
Mamay

Цитата:

И долго ты сочинял эту лекцию?

Не понял этого наезда?!

Guderian

Цитата:

Некоторые особо одаренные пишут исключительно на интерфейсах

Ну это уже не одарение - а издевательство над собой! Так сказать суициидальные наклоности! :о) В СОМ они используются действительно замечательно - а без кома их юзать -
Цитата:

Только смисла в етом с гулькин хвост!

Mamay

интерфейсы можно замечательно использовать и без кома
это, например, замечательный способ изобразить что-то подобное множественному наследованию

например ты можешь сделать


Код:
IEnumerable = interface
property CurrentElement: IUnknown;
procedure Next;
end;

TMyObjectList = class (TObjectList, IEnumerable)
TMyCollection = class (TCollection, IEnumerable)

aero
Чем-то мне это .NET напоминает :)

Guderian

ну автор .NET бывший разработчик Borlanda

И еще, (немного оффтопик, но все же), надеюсь все поймут что я пытаюсь сказать-
кто-нибудь знает как динамически в рунтайме получать поинтеры на поля/методы класса по заданному имени. К published методам есть такая функция у TObject -
MethodName / MethodAddress. А как получить поинтер не только к published методам?
+, там есть функция FieldAddress - возвращает поинтер на published поле, на каким макаром??? поля немогут быть published вроде бы??

CHiF

насчет первого не знаю
попробуй посмотреть JCL там были средства для работы с RTTI

насчет второго стало интересно, посмотрел доку

The $M switch directive controls generation of runtime type information (RTTI). When a class is declared in the {$M+} state, or is derived from a class that was declared in the {$M+} state, the compiler generates runtime type information for fields, methods, and properties that are declared in a published section. If a class is declared in the {$M-} state, and is not derived from a class that was declared in the {$M+} state, published sections are not allowed in the class.

Цитата:

fields, methods, and properties that are declared in a published section

это я видел в хелпе, и именно это мне и непонятно, ведь в published нельзя объявлять поля. [Error] Unit1.pas(21): Published field 'pub_int' not a class nor interface type

Интерфейсы нужны чтобы запускать Excel из IExplorer. Это конечно круто, но для Delphi большее значение имеет среда дезигна (всякие ПропертяЕдитуры и ДезигнВиндувы).
Кстати очень мощно используются при соотв. знаниях Source\ToolsAPI. Технология COM действительно вошла в стандарт, поэтому Borland не стала изобретать велосипеда.

Задача в том, что DLL не имеет виртуальных методов объектов. Процедуры DLL имеющие префикс XXClass1_(@self можно сгруппировать в таблицу адресов и считать их виртуальными. Но тогда как системе идентифицировать эти таблицы? Вот именно таблица со своим GUID и является интерфейсом. Естественно в Win9x Вы можете залесть в память DLL и даже не заметите, однако в WinNT такое не пройдёт, значит следует выбирать механизм предоставленный системой. Если нужно приложение в Win9x то можно и не париться с интерфейсами - обьекты и так видны, но нужно помнить что RTTI у DLL и EXE разные. Естественно, что Borland пишет не только Win9x

aero
Воздадим должное Хейлсбергу. Его стараниями гораздо проще оказалось переползание на .NET

CHiF
Дело в том, что все методы в Delphi, для которых не указан virtual, являются статическими, и в rtti, соответственно не хранятся. Но в этом случае указатель на них получить гораздо проще. Он будет всегда одним и тем же для любого экземпляра. например,


Код:
var proc: procedure obj object;
..
proc := AnyClass.MyMethod;
ShowMessage(IntToStr(Integer(@proc)));

Цитата:

попробуй посмотреть JCL там были средства для работы с RTTI

Пока ничего нужного там не нашел...

Так как все-таки работать с TObject.FieldAddress?


Цитата:

Они-то как раз чаще всего и выступаю в published. Что ты обычно редактируешь через object inspector?

Разве? Может я определения путаю... в published обычно property, а переменные разве в published записываются.

Уконкрентизирую вопрос: Мне надо по заданному имени достать какой-то var из класса- как это сделать?

чем дальше тем интереснее

Published members
.....
All methods are publishable, but a class cannot publish two or more overloaded methods with the same name. Fields can be published only if they are of a class or interface type.
.....


вот и нашлось и еще одно применение интерфейсам

aero
Да блин создайте наконец ActiveX и не партесь. - Зачем нужны интерфейсы. Ну давай я кину на сервер страницу с OCX-овским CAB-ом. И перейду на программирование под С++. Главное увидеть, что это всё очень просто.
В Delphi очень просто рабортать с библиотекой типов TLB. Разреши быструю кнопку TypeLibrary. И тогда работа в Delphi у тебя поменяется коренным образом.

CHiF

Цитата:

Так как все-таки работать с TObject.FieldAddress?

Так что именно ты от него хочешь? Вроде уже все объяснил...


Цитата:

Разве? Может я определения путаю...

Да, маленькая несогласованность в определениях получилась

Pinocchio
Что значит "создайте" ActiveX? Их всяких activex-ов валом. Судя по фразе "ocx-овским cab-ом", речь идет об ActiveX From. Каждый раз, когда нужен воспользоваться интерфейсами создавать оные формы?! Причем, ActiveX From в Delphi сделан как-раз таки похабненько. В общем, совершенно не понял сказанного в связи с обсуждаемой темой. Или ты про QueryInterface как альтернативу rtti?

Pinocchio
я что то не очень понял смысл сообщения , увы
ты предлагаешь юзать IDispatch для вызова метода по его имени?

тут, вообщем, как бы 2 темы
со следующими вопросами

1.1. subj Зачем нужна конструкция языка Interface.
а) для связи с COM
б) для реализации подобия множественного наследования, не знаю как сказать это точнее
в) для использования механизма автоматического уничтожения объектов

1.2. subj Чем она лучше конструкции языка class
а) возможна реализации подобия множественного наследования
б) возможно использование автоматического уничтожения объектов

2.1 offtopic Как использовать TObject.FieldAddress
не знаю, ни разу не работал

2.2 offtopic Могут ли быть published поля (fields, не properties)
могут, если они классового или интерфейсного типа

Guderian
Мне кажется, что тема надумана. То, что существует в системе необходимо потдерживать. Вы хотите Delphi без возможностей повлиять на ATL? Я не имел в виду, что каждый раз нужны формы FormX, но Delphi делает их как раз великолепно, по сравнению в скорости дизайнерской работы. На данный момент я сотрудничаю с автором производственного пакета, и он пишет на сях. А я ему поставляю ActiveX. Я хочу обратить внимание на то, что интерфейсы это стандартная автоматизированная технология завоевавшая своё место - что тут придумывать?

aero

Цитата:

я что то не очень понял смысл сообщения , увы
ты предлагаешь юзать IDispatch для вызова метода по его имени?

А ты, что предлагаешь для внешнего наследования всегда использовать BPL. Даже если я знаю, что у меня будет новая версия Дельфы через ниделю и мне всё придётся перекомпилить? Интерфейс - (INTER - снаружи). Методы IDispatch при грамотном написании вызываются исключительно снаружи, внутри они не используются.


Цитата:

1.2. subj Чем она лучше конструкции языка class

Ну чем велосипед лучше дрели? Это разные вещи. Формы Дельфы это очень скоростной формат текстово-двоичной информации. Это офигительная технология, которую ничем не заменишь. Когда поименованный компонент формы загружается, класс TParser использует метод FieldAddress для вычисления того места в памяти, куда он положит ссылку на загружаемый по имени компонент. Вся магия дизайнерской части дельфы построена на очень гибкой описательной части PUBLISHED. Если их продублировать в IDispatch, то получишь замедление сравнимое с MS Office.

Pinocchio

да я и не спорю просто не понял смысл

но тут по-моему ты смешиваешь интерфейсы в кучу, точнее имеешь ввиду только COM
да, если мне нужен автономный модуль, то лучше его сделать через ком,
но применять интерфейсы внутри программы тоже иногда стоит,
а иногда просто приходится, не зря Borland разделила с D6
IInterface и IUnknown.

так что насчет INTER это снаружи не согласен

Pinocchio

Цитата:

Мне кажется, что тема надумана.

Тема-то как раз очень интересная и полезная, только интерпретировал ты ее по своему и неправильно. Еще раз поясняю. Из самой парадигмы интерфейсов следует COM, но обратное утверждение НЕ ВЕРНО. Посмотри на заданный вопрос. Там где-нибудь спрашивалось про ActiveX? Возьми любую книжку по Rational Rose, Together ControlCenter и т.д. Про интерфейсы там будет многое, про ActiveX - вряд ли. Давайте отделим "мух от котлет". Мы говорим об интерфейсах как составляющей ооп-концепта или интерфейсах как основе com-ориентированных разработок.


Цитата:

Вы хотите Delphi без возможностей повлиять на ATL?

Каким образом Delphi влияет на Active Template Library? Или в эту аббревиатуру вложен другой, секретный смысл?


Цитата:

Delphi делает их как раз великолепно

Не рассматривал пристально, что произошло в семерке, но в предыдущих версиях у них была куча проблем by design. Оставались инстансы, когда контейнер умирал, ошибки в реализации IViewObject (умел отображать только на экране, стоит только распечатать и хрен), Apartment формы давали AV (например, когда браузер не в separate process, ты запускаешь второй экземпляр, потом первый убиваешь, а второй рефрешишь), глупый message handling и частые catastrophic failure (брал, например, DHTML control, комбинации клавиш не работали, execcommand вызывал упомянутую ошибку), короче много чего можно порассказать.


Цитата:

На данный момент я сотрудничаю с автором производственного пакета

Это тянет на вымпел и значок без обид. Только бравады думаю излишни. У меня самого этих исов, кисов, erp,mrp и crm несколько ведер.


Цитата:

Я хочу обратить внимание на то, что интерфейсы это стандартная автоматизированная технология

Либо учим матчасть, либо пишем "COM-интерфейсы". Потому как классические интерфейсы никакой "автоматизированной технологией" не являются.


Цитата:

Методы IDispatch при грамотном написании вызываются исключительно снаружи, внутри они не используются.

Можно поинтересоваться, что значит вызов метода "снаружи" и "изнутри". Если например моя софтина является контейнером или наоборот, например, com-addin для Office. Это откуда же будет методы вызываться? Справа или слева ?

Господа, давайте все-таки определимся, о чем мы?

ИМХО речь должна ити о COM-интерфейсах, которые имеют наиболее широкое применение.

c0r0ner
Возьми к примеру Java или .NET. Интерфейсов там валом. COM? Нет. Interop в расчет не берем. А то так можно сказать, что Java это COM через JNI. Сама по себе тема com-интерфейсов безынтересна. А вот интерфейсы методологически - совершенно другое дело. тут есть масса закавык. Вон, люди целые техники программирования на интерфейсах разрабатывают. А эти знания уже пригодились бы и для com и для .net и java и т.д.

Guderian

Цитата:

Сама по себе тема com-интерфейсов безынтересна.

А как же использование интерфейсов в разарботке сетевых БД, создание языконезависимых платформ, системное програмирование в конце концов.