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



Ну как передавать параметры можно в пустой метод? Никак нельзя. С ним вообще кроме переопределения или определения ничего нельзя сделать.



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

В Перле контекст - понятие вполне конкретное, это способ использования. "2" может использоваться как строка, а может как число - это контекст, к полиморфизму не имеет отношения.

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

Абстрагируясь, все это можно назвать волнами, колебаниями, частотами, однако часть этих волн - световые, часть звуковые.. а есть еще ультразвук - но это уже совсем не те "звуки"




Ваша основная ошибка в том, что вы интерпретируете ООП через реализацию конкретного языка программирования... Поэтому такое упертое убеждение что полиморфизм относится к классам или объектам.... 

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

Нужно понимать, что как некая концепция "полиморфизм" сформировался именно при ООП, но это совсем не значит, что он не возможен уже не в рамках ООП или не в рамках объектов или классов...

Perl как раз один из тех языков, который позволяет делать разную реализацию, сохраняя основную философию таких понятий.. Лично мне например совсем необязательно использовать функцию bless и определять конструктор new - для того чтобы создать объект и написать класс в перле. И это будет вполне полноценный класс ООП, правда выглядеть он будет малость по иному.

И раз уж есть немного флуда, сам термин полиморфизм - он тоже не случаен. Из чего он состоит?? Из двух слов "морфа" и "поли"



подитожив - как самостоятельная концепция, полиморфизм появился именно при ООП, но это совсем не означает что он не возможен без классов и объектов. и при использовании полиморфизма не в рамках ООП, скорее придется называть это все же неким аналогом полиморфизма




  Представь себе, что у тебя есть 2 Mb свободной памяти("пустое место") на жестком диске.. Причем самому жесткому диску абсолютно все равно что будет хранится на этих 2 Mb, текст или изображение, музыка или видео, по большому счету ему даже все равно в каком файловом формате все это будет.

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

Возьмем более простой пример... Допустим у меня есть два демона, которые прослушивают какие-то конкретные порты.. Для обоих демонов мне нужен метод, который обрабатывал бы(ну или хотя бы получал на первом этапе) то, что приходит по сокету. Причем, если для одного демона у меня приходят просто текстовые сообщения, то для другого какие-то конкретные пакеты конкретного протокола.. Но ведь логика-то все равно для них общая.. И если я напишу этот метод сначала для одного, реализовав в нем прием обработку текстовых сообщений, а потом унаследуюсь и переопределю для пакетов какого-то протокола - то это вообще не будет ни полиморфизмом, ни абстракцией. Вот тут нам и помогает абстракция, с пустым методом, и реализация (через переопределение метода) для каждого конкретного случая. А потом этот же самый абстрактный метод можно применить и для третьего и для четвертого демона и т.д. при этом у меня нет необходимости создавать многоуровневую("сложную") иерархию, т.е. таким образом мы и приходим к моему любимому принципу KISS - keep it simple, stupid.



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


Перл вообще не ОО язык, и в нем нет таких понятий как интерфейс вообще. 

Еще раз, лично я могу типично перловым синтаксисом создавать вполне полноценные объекты и классы, в них будут некоторые отличия вплоть до уровня представления от привычных C-ных классов, но это совсем не означает что это уже не объекты.. Мне счас вспоминается фраза из одного учебника



Не нужно привязывать ОО, к реализации конкретного языка. Это лишь интерпретация самой теории ОО. 

Попробуй почитать допустим про Object Pascal



Это сообщение отредактировал(а) Bulat - 12.1.2010, 11:28

  
товарищи, предлагаю все читать книжки и завершать флейм.

А никто и не сказал, что рыбы должны издавать звук так же как и человек.

Что касается полиморфизма, полностью согласен с mvsgt.

Bulat - не знаю почему, но вы напрочь отказываетесь понять, что вы пишите совершенно о другом, о том, что не имеет никакого отношения к полиморфизму, даже приблизительно. Не обижайтесь, я не преследовал цели кого-то здесь обидеть, просто вижу, что вы не верно понимаете о чём пишите. Так как нет ничего хуже ложных знаний, постараюсь пояснить на примере, что из себя представляет полиморфизм.

Вот есть абстрактный класс Shape.java

По большому счёту нас здесь интересует только абстрактный метод draw(). Так как фигура понятие очень абстрактное, мы не можем реализовать метод draw() прямо в нём, точнее можем, но это уже будет танец с бубном, а не полиморфизм. Например, можно было бы передавать этому методу параметр, который подсказывал бы, какую именно фигуру он должен нарисовать в данный момент времени. Для этой цели прекрасно подошла бы константа. Допустим мы решили, что наш класс Shape будет рисовать только круг и квадрат, можно было бы определить класс Shape так:

И это работало бы, до тех пор пока нам не понадобилось добавить новую фигуру. И всё бы ничего, можно было бы поправить класс Shape напрямую, слава богу компиляторы нынче работаю быстро, но проблема в другом - это не решение ООП. А если бы класс Shape писал бы кто-то другой и исходника у вас под рукой нет? Что тогда?
Можно было бы прийти к ещё одному не верному решению: Унаследовать от класса Shape и создать фигуру, которая  умеет рисовать новую фигуру, пусть это будет четырёхугольник.

И опять же, а если нам понадобится нарисовать ещё и ромб? Опять множить всякого рода классы Shape?

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

Здесь опять же обращаем внимание только на метод draw(), который будет выводить на системную консоль информацию о том, что он отработал, как положено.
Далее для определим класс Circle.

Он так же релизует метод draw(), который на системной консоле выдаст соответствующее сообщение.
Создадим так же класс Square, но наследовать будем уже не от класса Shape, а от класса Rectangle, так как квадрат является четырёхугольником, с небольшими отличиями, у него все стороны равны.

Так как у квадрата, стороны равны, нам нужно лишь переопределить методы унаследованные от класса Rectangle, устанавливающие размеры. Рисовать квадрат вполне сможет и метод draw() из класса Rectangle, потому здесь переопределять его нет смысла.

Ну и наконец создадим файл, который продемонстрирует нам полиморфный вызов методов.

Для начала, создаём массив типа Shape и помещаем в него различные фигуры, в данном случае это - Circle, Rectangle, Square и опять Circle. Затем в цикле, проходим по всем элементам массива и выводим на консоль имя класса, к которому относится текущий обьект и вызываем его метод draw().
Здесь обращу ваше внимание на то, что массив у нас типа Shape, но так как все наши фигуры являются его наследниками, мы можем их поместить в него.

Если запустить этот код на выполнение, то вы увидите явно, что какждый вызов метода draw(), нарисовал именно ту фигуру, которую представляет текущий обьект. Вот это и есть полиморфизм.

PS: Я извиняюсь за код Java, в разделе Perl. Показать нужно было, что из себя представляет полиморфизм, а лучше способа, чем сделать это на Java или C# я не нашёл.

Это сообщение отредактировал(а) korob2001 - 12.1.2010, 13:47

Нисколько обрати внимание на структуру которую ты создал

1. Shape -> (Rectangle, Circle)

2. Rectangle -> Square.

Попробую уйти на уровень математических терминов...

У нас есть некое пространство Shape... Создавая Rectangle и Circle ты создаешь новые пространства(множества), за счет того что переопределяешь метод, естественно множество Shape пересекается с множеством Rectangle, так же как пересекаются Shape и Circle

Но создав класс Square ты всего лишь навсего обособил некое подмножество которое само полностью(!) содержится в множестве Rectangle.



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

И тогда у меня к тебе вопрос? Что именно не имеет отношения к полиморфизму? Вот для интереса я достал маленький пример с Object Pascal то бишь Delphi.

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

Добавлено через 6 минут и 11 секунд
korob2001, и раз уж на то пошло, было бы интересно еще посмотреть на реализацию полиморфизма при множественном наследовании.   

Это сообщение отредактировал(а) Bulat - 12.1.2010, 14:24

korob2001, Или даже еще интереснее, хочешь я тебя подловлю в рамках твоего же приведенного примера с shape, rectangle и т.д.

при этом всего навсего за 2 шага ))

Почти  правильно. Но в корне неверно. Полиморфизм проявляется не в момент переопределения методов, а в момент использования объектов. И не обязательно переопределения пустых методов.




Это станет полиморфизмом, как только будет использован объект вместо своего родителя. Но использующая процедура будет с объектом работать как с его родителем, не принимая во внимание новых свойств объекта. 




Суть здесь - в слове "форма". 



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

Оно то содержится, но квадрат - всё же это не совсем четырёхугольник. Я понимаю, что можно было создать обьект который бы смог нарисовать нам квадрат, с помощью класса Rectangle. Square, в данном случае гарантирует, в отличае от Rectangle, что размеры старон у квадрата будут одинаковы, так как он переопределяет методы доступа класса Rectangle.

По хорошему, нужно было унаследовать от класса Rectangle и класс Oval, который можно описать четырёхугольником.  В последствии создать класс Circle, который бы наследовал от класса Oval, так как окружность является овалом, опять же с небольшими отличиями. 

Я этого понять не могу. Вот иерархия, которую я создал выше.

Где здесь класс Square пересекается с Shape?
Здесь Shape является прародителем класса Square, так как квадрат тоже является фигурой,  который так же наследуте все методы которые предоставляет, класс Shape, квадрат так же ялвляется и четырёхугольником, потому ему так же доступны методы предоставленные его непосредтсвенным родителем, т.е. классом Rectangle.



Ту структуру которую я создал, я нарисовал выше.


Это сделано скорее для инкапсуляции, так как класс Square переопределяет методы доступа класса Rectangle так, что они не позволяют создать квадрат с разной динной сторон. К полиморфизму это вообще не относится.

К сожалению ни Java, ни C# не поддерживают множественного наследования, а может к счастью. 

Давай

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




а если я пишу портал, то термин "интерфейс" я могу использовать применяя совсем не к командам объекта. 


korob2001, 

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



Более или менее привычного нет, но в Java есть интерфейсы взамен множественного наследования

файл Invoke.pm:


Полиморфизм - это свойство языка (в данном случае perl) автоматически определять класс (пакет) объекта (obj) и вызывать метод (do_method) из этого класса (пакета). 
Это позволяет работать с объектами не зная их класса, но зная что у них есть определенные методы (т.е. что объект реализует интерфейс)

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

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

Булат, ситуация прояснилась ?

А смысл выносить её в отдельную ветку? Речь ведь идёт об ООП.

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

Это сообщение отредактировал(а) Bulat - 12.1.2010, 16:25

Вы считает что цвет - это свойство фигуры ?
Обычно в таких случаях в метод draw передают объект типа Canvas - то на чем происходит рисование.
А вот уже у Canvas устанавливается текущий цвет.


Поэтому в том месте где вы хотите окружность определенного цвет - вы делаете


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


Но это никакого отношения к полиморфизму не имеет

Это сообщение отредактировал(а) sir_nuf_nuf - 12.1.2010, 16:51

От оно как... Это Вы серьёзно написали, или в порядке разгрузки против трудового дня ?   Посмотрите определение термина, например,в Википедии - http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%...%BD%D0%B8%D1%8F. 



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




Ну так надо унаследовать от Прямоугольник ЗелёныйПрямоугольник 

Это сообщение отредактировал(а) mvsgt - 12.1.2010, 16:54