-
Собственно сабж (на примере Delphi)
-
Интерфейс не содержит реализации.
-
можно наследоваться от нескольких интерфейсов.
-
> Kerk © (04.01.17 14:22) [1]
>
> Интерфейс не содержит реализации.
А что это дает интерфейсу?
-
Класс лучше интерфейса.
-
> Belkin © (04.01.17 16:02) [3]
Интерфейсу это ничего не дает и давать не может, т.к интерфейс это лишь описание, а вот тому кто интерфейс использует или реализует при правильном применении может давать массу удобств:
1) Подобие множественного наследования
2) IoC
3) Счетчик ссылок (в Delphi, не обязательно)
-
> Belkin © (04.01.17 16:02) [3]
> > Kerk © (04.01.17 14:22) [1]
> > Интерфейс не содержит реализации.
> А что это дает интерфейсу?
interface
type
IMyInterface = Interface
procedure Proc;
end;
TMyClass1 = class(TSomeClass, IMyInterface)
procedure Proc;
end;
TMyClass2 = class(TAnotherClass, IMyInterface)
procedure Proc;
end;
// TMyClass1 и TMyClass2 имеют разные ветви наследования
procedure CallProc(intr: IMyInterface);
implementation
procedure TMyClass1.Proc;
begin
// Звонок другу
end;
procedure TMyClass2.Proc;
begin
// Печать на принтере в Австралии
end;
pocedure CallProc(intr: IMyInterface)
begin
intr.Proc // Код один и тот же, а результат - разный
end;
-
Интерфейс - это контракт, который обязуется выполнять класс, который реализует этот интерфейс. То есть этот класс обязан предоставить реализацию методов, описанных в интерфейсе, либо делегировать реализацию этих методов другим классам.
Это дает определенную гибкость при стыковке того кода, который использует интерфейс и того кода, который его реализует.
Можно подойти и с другой стороны - это дает возможность заранее (до разработки кода, реализующего интерфейс) договориться о том, что от него вправе требовать тот, кто собирается использовать этот интерфейс.
-
еще это дает возможность работать над одним и тем же количеством(по функциональности) кода в пять раз большему количеству программистов. Т.о. интерфейсы обеспечивают рабочими местами ит-шников. Справедливости ради, надо сказать, что интерфейсы в этом обеспечении лишь вершина айсберга.
-
Спасибо всем за ответы, вроде стало понятно.
> картман © (04.01.17 19:13) [8]
>
> Справедливости ради, надо сказать, что интерфейсы в этом
> обеспечении лишь вершина айсберга.
А что еще?
-
Основной его плюс - это то, что можно сделать закрытый код (например DLL, dcu или другой пакет), а интерфейс отдать другому программисту.
И он будет знать как работать с этим классом\dll.
> DVM © (04.01.17 17:04) [5]
>
> 3) Счетчик ссылок (в Delphi, не обязательно)
Уже обязательно. Причем на моб. компиляторах счетчик ссылок уже на обычных классах (TObject). Т.е. TObject.Free на моб. компиляторах уже не работает, нужно или обнулять или FreeAndNil или DisposeOf (этот метод всегда 100% уничтожает класс, независимо от ref count).
-
-
> Кто б сомневался ©
> Точнее он работает, только деструктор не вызывается
и как же деструктор вызвать?
-
DVM © (05.01.17 00:46) [12]
DisposeOf
-
> Юрий Зотов © (04.01.17 17:19) [6]
Сколько читаю про интерфейсы - никак не могу взять в толк вот что: что изменится от того, если в вашем примере IMyInterface = Interface заменить на класс с виртуальным методом? и сделать 2 класса, его наследующих?
Ну ведь тоже самое абсолютно получится, так зачем интерфейсы приплетают? что они дают?
-
> Ну ведь тоже самое абсолютно получится, так зачем интерфейсы
> приплетают? что они дают?
Можно сказать, что интерфейс ничем не отличается от абстрактного класса в стиле С++. Но это будет не совсем правда по причинам, частично отмеченным выше:
1. Возможность "наследовать" несколько интерфейсов одновременно
2. Автоматическое управление временем жизни переменных, основанное на подсчете ссылок. С этим надо аккуратно. Как ни странно, вводимый для уменьшения ошибок работы с памятью подсчет ссылок их не сильно уменьшил, скорее заменил одни ошибки другими.
И тем более, слово interface не всегда означает включение механизма подсчета этих самых ссылок.
3. Возможность сопоставить с интерфейсом GUID позволяет уникально идентифицировать этот интерфейс по всему мировому программному коду, а также задействовать возможность получения через интерфейсную переменную другого интерфейса, реализуемого тем же классом.
Ну и COM, конечно, который в том числе базируется на пунктах 2 и 3.
-
Я тож непонимаю необходимости интерфейсов, учитывая, что я работаю один, какие-то заумные наследования в конечном продукте не предусматриваются в виду скромности этого продукта (работаю ведь один). А вышеприведенный пример с длл вообще мне непонятен, так как предпочитаю в длл засовывать функции.
-
> Ну ведь тоже самое абсолютно получится, так зачем интерфейсы
> приплетают? что они дают?
Удобно, знаете ли. А вообще в справке все написано, кто ее ленится читать, тому и на форуме не ответить.
-
Возможно пример далекий, но наглядный.
Возьмем телевизор у которого есть вход scart и rgb.
Так вот телевизор это класс TTelevizor, а входы это интерфейсы IScart, IRgb, которые содержат описание какой контакт где находится и форма самого разъема.
Так вот класс TTelevizor наследуется от TTelevizorBase и реализует интерфейсы IScart и IRgb.
Как он их реализует это его дело, но есть договоренность что в итоге он должен из полученного сигнала показать изображение.
При этом все понимают что если у него есть RGB вход значит, на этот вход можно подключить видеоплеер и получить картинку.
-
А телевизор, который на 100 баксов дешевле реализует всего 1 интерфейс, а наследуется от того же базового класса.
|
Есть новые 
Нет новых [118448 +36][b:0][p:0.001]