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

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

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

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

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

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

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

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

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

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

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

KSergey ©   (06.01.17 09:45) [20]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> KSergey ©

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

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

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

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

> 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 ?

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

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

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


Немного добавлю.
И есть еще



у него метод:



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

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

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

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

> 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