Подскажите пожайлуста чем интерфейс в C# отличается от абстрактного класса в C++. Можно ли сказать, что итерфейс — подмножежтво абстрактного класса C++.
ША>Подскажите пожайлуста чем интерфейс в C# отличается от абстрактного класса в C++. Можно ли сказать, что итерфейс — подмножежтво абстрактного класса C++.
Пожалуй, нет. Интерфейс в .NET похож на интерфейс в СОМ, а с абстрактным классом тут есть пара серьезных отличий. Во-первых, все методы интерфейса — абстрактные. А во-вторых — в назначении. Интерфейс — это, прежде всего, контракт. Именно благодаря интерфейсам мы сейчас имеем кучу технологий, основанных на СОМ — ActiveX, OLE DB, Automation и т.п. В .NET — то же самое.
Здравствуйте Ярослав Говорунов, вы писали:
ЯГ>Пожалуй, нет. Интерфейс в .NET похож на интерфейс в СОМ, а с абстрактным классом тут есть пара серьезных отличий. Во-первых, все методы интерфейса — абстрактные. А во-вторых — в назначении. Интерфейс — это, прежде всего, контракт. Именно благодаря интерфейсам мы сейчас имеем кучу технологий, основанных на СОМ — ActiveX, OLE DB, Automation и т.п. В .NET — то же самое.
Если мои абстрактные классы содержат только абстрактные методы и есть договоренность называть их, предположим с I (IFoo, например), и не измененять с момента опубликования (т.е. контракт) мы и получим ИНТЕРФЕЙС?
Если так, то не совсем понятно зачем эта игра слов и зачем вводить в язык (C#) дублирующие понятия. Ведь ЛЮБОЙ класс имеет ИНТЕРФЕЙС, а точнее несколько интерфейсов (сам класс и его друзья видят один интерфейс, производные классы другой и т.п.).
Здравствуйте Шестаков Александр, вы писали:
ША>Здравствуйте Ярослав Говорунов, вы писали:
ЯГ>>Пожалуй, нет. Интерфейс в .NET похож на интерфейс в СОМ, а с абстрактным классом тут есть пара серьезных отличий. Во-первых, все методы интерфейса — абстрактные. А во-вторых — в назначении. Интерфейс — это, прежде всего, контракт. Именно благодаря интерфейсам мы сейчас имеем кучу технологий, основанных на СОМ — ActiveX, OLE DB, Automation и т.п. В .NET — то же самое.
ША>Если мои абстрактные классы содержат только абстрактные методы и есть договоренность называть их, предположим с I (IFoo, например), и не измененять с момента опубликования (т.е. контракт) мы и получим ИНТЕРФЕЙС? ША>Если так, то не совсем понятно зачем эта игра слов и зачем вводить в язык (C#) дублирующие понятия. Ведь ЛЮБОЙ класс имеет ИНТЕРФЕЙС, а точнее несколько интерфейсов (сам класс и его друзья видят один интерфейс, производные классы другой и т.п.).
Есть много книг в которых доходчиво описано зачем нужна эта "игра слов"
например "Технологии ActiveX и OLE" Дэвида Чеппела, или "Inside OLE" Kraig Brockschmidt'а
имхо не стоит браться изучать .NET не изучив хотя бы основных положений COM
Здравствуйте Edward, вы писали:
E>Есть много книг в которых доходчиво описано зачем нужна эта "игра слов" E>например "Технологии ActiveX и OLE" Дэвида Чеппела, или "Inside OLE" Kraig Brockschmidt'а E>имхо не стоит браться изучать .NET не изучив хотя бы основных положений COM
Книги действительно замечательные я их читал некоторое время назад, но давайте разделим понятия.
Есть технологии в которых используется понятие интерфейса для простоты восприятия (хотя в глубине все интерфейсы и IUnknown в частности — это обычный чисто абстрактный клас С++) и есть язык программирования (С#) в который это понятие введено синтаксически.
Прочитав спецификацию языка мне вдруг стало интересно:
1. зачем это (interface) нужно, если есть абстрактные классы
2. если интерфейс это контракт — почему нет встроенного контроля версий интерфейсов (или я не нашел ссылки что он есть?)
3. почему множественное наследование возможно только для интерфейсов
Здравствуйте Шестаков Александр, вы писали:
ША>Прочитав спецификацию языка мне вдруг стало интересно: ША>1. зачем это (interface) нужно, если есть абстрактные классы
инрефейс может быть реализован на VB, FoxPro, Java, Delphi и т.д. Там -то с какого бока абстрактные классы C++?
ША>2. если интерфейс это контракт — почему нет встроенного контроля версий интерфейсов (или я не нашел ссылки что он есть?)
Здравствуйте Odissey, вы писали:
O>Здравствуйте Шестаков Александр, вы писали:
ША>>Прочитав спецификацию языка мне вдруг стало интересно: ША>>1. зачем это (interface) нужно, если есть абстрактные классы
O>инрефейс может быть реализован на VB, FoxPro, Java, Delphi и т.д. Там -то с какого бока абстрактные классы C++?
ША>>2. если интерфейс это контракт — почему нет встроенного контроля версий интерфейсов (или я не нашел ссылки что он есть?)
O>он вроде как есть — см. http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/midl/mi-laref_1df2.htm O>но нифига не работает, не понятно, где тут собака порылась.
O>А вообще в книжках по основам COM пишут, что никаких версий у интерфейса нет, что-то поменял, меняй GUID и это уже другой интерфейс
Спасибо, но я говорил о понятии интерфейса в языке C#.
interface iFoo
{
void Method1();
void Method2();
} и т.п.
Должен ли разрботчик на этом языке догадываться о механизмах работы VB или FoxPro?
Здравствуйте Шестаков Александр, вы писали:
O>>А вообще в книжках по основам COM пишут, что никаких версий у интерфейса нет, что-то поменял, меняй GUID и это уже другой интерфейс
Ага! Вот только с GUID-ми в шарпе туго :).
По делу же могу сказать, что читайте описания в первоисточника...
Интерфейс (в COM) есть некая абстракция (для человека) и бинарный стандарт, гарантирующий местоположение методов и описывающий стандарт укладки параметров в стек (или регистры).
Абстрактный класс есть класс, все методы которого не определены. Физически для реализации интерфейсов была взята MS-ная реализация VTbl-а то есть абстрактный класс может использоваться для реализации COM-интерфейсов а может и не являться. Улавливаете?
Стандарт C++ не гарантирует ни то, что методы в VTbl будут расположены в соответствии с их расположением в описании класс ни саму реализацию виртуальных функций через VTbl. C++ — это не бинарный стандарт, а Interface в COM бинарный. То что большинство современных компиляторов похоже на VC, это уж следствие лидерства MS и популярности COM
Идея интерфейсов вообще не подразумевает ни классов, ни наследования (они поддерживаются даже в голом C).
.Net пока что не поддерживает множественного наследования. А по мне, чем замораживаться с абстрактными классами, лучше использовать простую и понятную концепцию интерфейса. Причем интерфейса как абстракции, а не как конкретной реализации.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, вы писали:
VD>Здравствуйте Шестаков Александр, вы писали:
O>>>А вообще в книжках по основам COM пишут, что никаких версий у интерфейса нет, что-то поменял, меняй GUID и это уже другой интерфейс
VD>Ага! Вот только с GUID-ми в шарпе туго :).
VD>По делу же могу сказать, что читайте описания в первоисточника... VD>Интерфейс (в COM) есть некая абстракция (для человека) и бинарный стандарт, гарантирующий местоположение методов и описывающий стандарт укладки параметров в стек (или регистры).
VD>Абстрактный класс есть класс, все методы которого не определены. Физически для реализации интерфейсов была взята MS-ная реализация VTbl-а то есть абстрактный класс может использоваться для реализации COM-интерфейсов а может и не являться. Улавливаете?
VD>Стандарт C++ не гарантирует ни то, что методы в VTbl будут расположены в соответствии с их расположением в описании класс ни саму реализацию виртуальных функций через VTbl. C++ — это не бинарный стандарт, а Interface в COM бинарный. То что большинство современных компиляторов похоже на VC, это уж следствие лидерства MS и популярности COM
Привет всем! Я могу сказать что имеено это написанно в такой книжечке как "Основы COM" [Дейл Роджерсон].
Она не толстая и понятная, хотя не новая.
VD>Идея интерфейсов вообще не подразумевает ни классов, ни наследования (они поддерживаются даже в голом C).
VD>.Net пока что не поддерживает множественного наследования. А по мне, чем замораживаться с абстрактными классами, лучше использовать простую и понятную концепцию интерфейса. Причем интерфейса как абстракции, а не как конкретной реализации.
