Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск |
Поиск по лучшим сайтам о Delphi
FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи |
Подборка статей на самые разные темы. Все о DELPHI
Книги |
Новинки книжного рынка
Новости VCL
Обзор свежих компонент со всего мира, по-русски!
|
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник
Коллекция курьезных вопросов из форумов
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.org

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »
Страницы: 1 2

Чем интерфейс отличается от класса?


KSergey ©   (06.01.17 09:45[20]

> Игорь Шевченко ©   (05.01.17 21:09) [17]
> А вообще в справке все написано, кто
> ее ленится читать, тому и на форуме не ответить.

Умник Игорь, который прочитал все справки.
Скажи, что в них написано за пределами пунктов 1..3 поста, предшествующего твоему очень полезному?

> Удобно, знаете ли

Вот бы ты сумел привести при мер удобства.
Но не трудись, я знаю, что ты не сумеешь.


Rouse_ ©   (06.01.17 10:11[21]


> KSergey ©   (05.01.17 15:28) [14]
> Ну ведь тоже самое абсолютно получится, так зачем интерфейсы
> приплетают? что они дают?

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


Rouse_ ©   (06.01.17 10:31[22]

Я опробую еще немного шире обьяснить.
Вот смотри есть у нас некие наборы данных - они пошифрованы, их декрипт происходит одинаково, не важно INI файл, XML или еще что-то наше внутреннее.

Потом есть к примеру два класса которые читают XML - один читает как есть, а второй должен читать его из криптоконтейнета.

Второму мы объявляем интерфейс, к примеру IDecrypt и на перекрытом методе DoLoad просто вызываем метод Decrypt интерфейса.

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


Rouse_ ©   (06.01.17 10:31[23]

И опять-же тут уже абстрактный класс никак не поможет.


Игорь Шевченко ©   (06.01.17 10:39[24]

KSergey ©   (06.01.17 09:45) [20]

Это все платные услуги, дружище.


ухты_х ©   (06.01.17 10:46[25]


> К примеру, не знаю, почему никто не упомянул - реализация
> кода может быть совершенно не в твоей программе,
про СОМ упомянули, к примеру )


Rouse_ ©   (06.01.17 10:58[26]


> ухты_х ©   (06.01.17 10:46) [25]
> про СОМ упомянули, к примеру )

Да, действительно - немножко пропустил читая, сори :)


KSergey ©   (06.01.17 11:20[27]

> Внук ©   (05.01.17 17:11) [15]
> 2. Автоматическое управление временем жизни переменных,
> основанное на подсчете ссылок.
.....
> И тем более, слово interface не всегда означает включение
> механизма подсчета этих самых ссылок.

Вот-вот. В первых строках все пишут про подсчет ссылок. Но дальнейшее чтение сотен страниц столько нюансов внезапно выявляет - что "нафик-нафик" это ваше волшебство.
Это так, не к вам лично. Впечатление от всех эти интерфейсов.

Хорошо, взаимодействие нескольких DLL одного процесса.
Может тут в самом деле удастся найти много пользы?

Вот есть такого плана проблема: имеем DLL, она должна вернуть список структур. Список - переменной длины. (т.е. грубо говоря нужно вернуть массив переменной длины, каждый элемент - некая структура.)
Если делать обычным интерфейсом "на функциях", то получается довольно коряво одним из 2-х вариантов:
1.
а) Делаем функцию, возвращающую количество элементов, которые хотим вернуть
б) Далее вызывающий модуль выделяет память и передаёт указатель на выделенный блок памяти во вторую функцию, которая уже заполняет переданный ей буфер и возвращает количество фактически заполненных элементов.
Пункты а) и б) можно как-то объединять в одну функцию, но это уже детали. Основная проблема в том, что фактически приходится одно и тоже действие (иногда сложное) выполнять фактически дважды, чтобы выходной буфер сформировать.
2.
Делаем функцию, которая внутри себя выделяет нужный размер памяти, заполняет и возвращает указатель на неё.
И делаем функцию, которая освобождает выделенную память в надежде, что пользователь нашей DLL не забудет вызвать освобождение памяти.

Вот как бы это всё сделать более удобно и волшебно в использовании?

Да, это всё не про Delphi. В том смысле, что нужен универсальный интерфейс, от того и разговор про буферы памяти, а не динамические массивы.


KSergey ©   (06.01.17 11:23[28]

> Игорь Шевченко ©   (06.01.17 10:39) [24]
> Это все платные услуги, дружище.

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


Rouse_ ©   (06.01.17 11:25[29]


> б) Далее вызывающий модуль выделяет память и передаёт указатель
> на выделенный блок памяти во вторую функцию

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


KSergey ©   (06.01.17 11:26[30]

> ухты_х ©   (06.01.17 10:46) [25]
> про СОМ упомянули, к примеру )

Про СОМ понятно.
Когда я хочу задействовать этот механизм по каким-то причинам - то вариантов нет: интерфейсы и всё такое.
Но интерфейсы существуют и вне СОМ механизма, вот и пытаюсь понять куда их приткнуть. Не зря же Тенцер пишет такие толстые книжки, наверное, вот только так и не нашел я куда всё это приткнуть за несколько лет по прочтении.


KSergey ©   (06.01.17 11:27[31]

> Rouse_ ©   (06.01.17 11:25) [29]
> > б) Далее вызывающий модуль выделяет память и передаёт
> указатель
> > на выделенный блок памяти во вторую функцию
>
> Ну это один из вариантов, к примеру NetAPI - там память
> выделяет уже вызываемая библиотека, только я тут не вижу никакой связи с интерфейсами

Скорее всего связи и нет, просто надежда: вдруг умные слова как-то помогут.


KSergey ©   (06.01.17 11:28[32]

>Rouse_ ©   (06.01.17 10:11) [21]
>Rouse_ ©   (06.01.17 10:31) [22]


Спасибо, попробую поразмыслить.


Внук ©   (06.01.17 20:06[33]


> KSergey ©

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

Что касается той пользы, которую увидел лично я (если не брать в расчет разработку кода в коллективе, где интерфейсы служат именно что контрактами), то я назову тестирование. Точнее, написание автоматизированных тестов. Интерфейсы позволяют писать тесты ДО написания тестируемого кода, не прибегая к заглушкам. Не говоря о том, что такой подход к тестам является православным, это на ранних стадиях позволяет увидеть косяки архитектуры и дешево их исправить.


Германн ©   (07.01.17 02:11[34]


> KSergey ©   (06.01.17 09:45) [20]
>
> > Игорь Шевченко ©   (05.01.17 21:09) [17]
> > А вообще в справке все написано, кто
> > ее ленится читать, тому и на форуме не ответить.

Тут есть сложность с определениями что такое форум по Дельфи, чем он может быть полезен, и нафига он вообще нужен?
ИШ об этом молчит.


Юрий Зотов ©   (07.01.17 11:28[35]

> KSergey ©   (05.01.17 15:28) [14]

> Юрий Зотов ©   (04.01.17 17:19) [6]
>
> Сколько читаю про интерфейсы - никак не могу взять в толк
> вот что: что изменится от того, если в вашем примере IMyInterface
> = Interface заменить на класс с виртуальным методом?  и
> сделать 2 класса, его наследующих?
> Ну ведь тоже самое абсолютно получится, так зачем интерфейсы
> приплетают? что они дают?


Вся фишка в том, что эти два класса могут иметь совершенно разные ветви наследования. Например:

TMyClass1 = class(TGraphicControl, IMyInterface)
TMyClass2 = class(TDataset, IMyInterface)

С интерфейсами все просто - в интерфейсе декларируем метод Proc и реализуем этот метод в обоих классах.

А без интерфейсов возникает проблема - где взять общего предка для этих двух классов, чтобы в этом предке объявить абстрактный метод Proc ?


KSergey ©   (10.01.17 13:44[36]

Юрий Зотов ©   (07.01.17 11:28) [35]
Внук ©   (06.01.17 20:06) [33]

Спасибо, интересны в самом деле именно реальные примеры.
Буду думать куда бы всё же приткнуть хоть раз в жизни, а то завидно.


stas ©   (10.01.17 14:12[37]


> Юрий Зотов ©   (07.01.17 11:28) [35]


Немного добавлю.
И есть еще
TMySuperClass = class (TObject)

у него метод:
procedure MySuperProcedure (obj:IMyInterface)
begin
   obj.Proc()
end


Этому классу ничего не нужно знать о TGraphicControl, TDataset, а только о интерфейсе.
Но в метод примет и правильно обработает классы TMyClass1, TMyClass2


KSergey ©   (11.01.17 14:36[38]

> stas ©   (10.01.17 14:12) [37]

А вот это толково, кстати.
В самом деле: наследования вынуждают все пихать в единое дерево с общими предками, что бывает противоестественно, а тут всё как надо делается.

Спасибо. Проникся.


DVM ©   (11.01.17 15:04[39]


> KSergey ©   (11.01.17 14:36) [38]
> > stas ©   (10.01.17 14:12) [37]
>
> А вот это толково, кстати.

Это и есть IoC отчасти. https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F


Страницы: 1 2 версия для печати

Написать ответ

Ваше имя (регистрация  E-mail 







Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i> <u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо