Только у интерфейсах есть Полиморфизм?

kurzon, 
Полиморфизм есть только у классов, которые интерфейс реализуют (а могут и не реализовывать  )

Полиморфизм может быть у объектов в памяти.  Причем значит это, что они будут РЕАГИРОВАТЬ на определеные вызовы (методы) по своему, но имена этих вызовов - одинаковые

А сам интерфейс -  это набор абстрактных методов (и свойств)
невозможно создать объект интерфейса, нету реализации.

Э, нет.

[Зд. и далее не претендую на академическую точность. Изложение своими словами.]
Полиморфизм (poly - много, morphema - форма). Соединив эти два корня, можно предположить, что полиморфизмом обладает пара классов, удовлетворющих одинаковой спецификации (интерфейсу), но, имеющие, возможно разные реализации этого интерфейса. Так что полиморфизм выражается именно в классах, а интерфейсы - следствие этой возможности. Например, в C++ нет интерфейсов, но полиморфизм прекрасно себе живёт и действует.

Интерфейсы - такие же типы данных, как и классы. Просто они не содержат полей, но содержат таблицы методов, по которым и маршрутиризуется вызов метода. 

Создать объект интерфейса нельзя, ну и что? Создать объект абстрактного касса тоже нельзя, но через ссылку абстрактного типа (ссылающуюся на объект-наследник от этого абстрактного типа) как раз полиморфные вызовы и происходят. 
А абстрактный класс (как известно) - тоже нечто вроде интерфейса. Пока в .Net не ввели интерфейсы, только через абстрактные классы и можно было реализовать наследование интерфесов.

Явная реализация интерфейсов предусматривает вызов метода через интерфейс, через переменную интерфейса. Ремоутинг часто использует вызов через интерфейс. 

Одним словом, интерфейсы как раз и обеспечивают полиморфизм чистого вида. Идеальный полиморфизм.

tol05, не соглашусь. Вот в дотнете (как и в С++) есть такая штука как виртуальные методы, и можно её юзать в обычных не-абстрактных классах. Класс А объявляет виртуальный метод, класс-наследник Б его переопределяет, пользователь создаёт экземпляр либо А либо наследника и вызывает конкретную реализацию метод через ссылку на базовый класс А. Это что - не полиморфизм?

Полиморфизм. Но виртуальный метод можно переопределнить, а можно - не переопределить. 

Допустим, метод не переопределен. Тогда вызывается метод базового класса, так же, как если бы метод был не виртуальным (и не перекрытым с помощью new). Таким образом, полиморфизм условен. Скажем так, и не наследование, и не полиморфизм. 
Не зря же Керниган говорил (если не ошибаюсь), что visual C++ убил ООП своими многочисленными уступками и отступлениями от правил.

Интерфейсы обязывают переопределять методы - значит полиморфизм в чистом виде будет работать. Обязательный полиморфизм.

И смотря что понимать под полиморфизмом. Вызов поведения в зависимости не от типа объявленной ссылки, а от типа присвоенного ей объекта? Тогда только интерфейс это гарантирует. Потому что в наследнике класса можно просто забыть переопределить метод... и все, вызовется реализация базового класса и ... всем ожиданиям.

Интерфейс гарантирует, что для вызова метода объекта не нужно писать реализации в базовом классе (не всегда понятно какой ). И если в базовом типе нет никакой реализации, а что-то работает - это и есть полиморфизм.


Это сообщение отредактировал(а) tol05 - 6.10.2007, 23:30

Возможно, в некоторых аспектах интерфейсы призваны заменить множественное наследование. В этом смысле C# стал строже и специализированее плюсов с их
, но, увы, это сильно поубавило в том числе гибкости полиморфизма.

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

В общем, меняю интерфейсы на множественное наследование. Кто со мной?  


Это сообщение отредактировал(а) marcusmae - 7.10.2007, 00:11

marcusmae, 
Мдя... А это ж наследование реализации, а не интерфейсов: слишком сильная зависимость. А если нет исходных кодов? (это я про С++)

да нет, не в этом смысл интерфейсов. Я согласен с Kuvaldis и немного поясню его мысль.
Интерфейсы можно применять для множественного наследования, но только множественного наследования интерфейсов, но не для множественного наследования реализаций. Здесь есть разница. 
И эта возможность - не главная. Java и Delphi, как я помню, вообще множественное наследование отрицают, и это никак не влияет на их полиморфные возможности 

Интрефейс призван отделить реализацию от манифеста (объявления). Как в плюсах файлы декларации, как библиотеки типов COM. Вот в чем фича. Самый яркий пример - ремоутинг. 

Как известно, на стороне сервера нужна программа "сервер" и библиотека "RemObj.dll" с классом удаленного объекта (удаленный объект содержит в своих методах конкретную реализацию). На стороне клиента - программа клиент. Клиент должен создать прокси удаленного объекта и вызвать метод чтобы получить результат. И вот тут два момента. 
Во-первых, клиент должен иметь у себя библиотеку с манифестом удаленного объекта. Но для этого разработчик сервера должен всем клиентам рассылать "RemObj.dll". А это не очень хорошо, раскрывать код.
Во-вторых, разработчик сервера может заменить класс удаленного объекта другим, и тогда нужно изменять всех клиентов.

Для решения проблем используют интерфейсы. Создается интерфейс IRemObj, который должны реализовывать классы удаленных объектов. И все. Клиент создает у сетя прокси на IRemObj, а вместо него создастся прокси на тот из классов удаленных объектов, который в данный момент подключил разработчик на сервере. К тому же клиент имеет только библиотеку с описанием интерфейса и абсолютно не содержащей конкретной реализации.

Это сообщение отредактировал(а) tol05 - 7.10.2007, 11:31

Полиморфизм - значит есть некоторые объекты, на которые можно воздействовать одинакова...
Т.е. интерфейсы если у них если не идентичны, то очень схожи.. ((-

Это сообщение отредактировал(а) Deja_Vu - 8.10.2007, 16:03

Статья на википедии:

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