Конференция "Начинающим" » Чем интерфейс отличается от класса?
 
  • 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
 
Конференция "Начинающим" » Чем интерфейс отличается от класса?
Есть новые Нет новых   [88577   +11][b:0.001][p:0.006]