Ты сильно заблуждаешься.  Сейчас ты смешиваешь два понятия как абстракция и полиморфизм в одно... 



Можно ли написанный мною выше код назвать полиморфизмом??

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

Если будет ответ, мол нет "оболочки типа метод внутри класса", можно с легкостью обернуть мой код в класс.  Я просто не стал этого делать.

Более того, можно ли назвать полиморфизмом ситуацию, когда есть прародитель номер1, от него наследуется прародитель номер2 с переопределенными некоторыми методами, а от него наследуются третий класс, опять же с некоторыми переопределенными методами, а может и со всеми, а может частично и со старыми, и не дай Бог еще похожая ерунда с потомком четвертого уровня, и на каждом этапе переопределение, переопределение ... так что иной раз даже не до конца понятно, из какого прародителя вызывается метод в финальном потомке?? 



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

Чтобы это не было из приведенного мною примера ты можешь назвать имя класса, экземпляром которого является данный объект?? Ни как реализован, ни для чего он нужен, а просто имя класса??

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

ООП - имеет в своей основе "три кита", но лишь необходимость, но есть еще и достаточность...

Или говоря еще проще, либо старайся делать полностью правильно, либо не строй из себя умного чувака и делай проще 

Это сообщение отредактировал(а) Bulat - 25.11.2009, 13:50

Ну не могу я дождаться ответа )))

Опять же..

1) Не нужно цитировать что-то из книг или интернета не до конца понимая что это значит...

Если никто не против я малость пофилософствую )))

Пойдем к началу. Что было раньше? Курица или яйцо? ))) Так вот что было раньше, процедурное(модульное) программирование или объектно-ориентированное программирование?? Я думаю что процедурное(модульное). 

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

Дык вот, возможна ли абстракция при процедурном(модульном) программировании?? 
Я считаю, что ДА!  

А возможен ли полиморфизм при процедурном(модульном) программировании?? 
Я считаю, что ну никак, при всем желании. :(

Дык что было в начале??

И вот теперь, если вдуматься:

а) Полиморфизм позволяет писать абстрактный код
б) Или же абстракция позволяет нам использовать такой прием как полиморфизм??

И чтобы уже совсем отделиться от этой зазубренной фразы, я попробую привести еще пару примеров определений термина полиморфизм:

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

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

А теперь пойдем дальше. Есть такое понятие, как логика предметной области. Интересная штука.. Т.е. то, что может определить для нас некий свод, набор правил, внутри конкретного приложения, предназначенного для указанной предметной области, чаще всего бизнеса в каком-то конкретном направлении, но может быть и какая-то научная работа, исследование и не только...

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

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

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

Но любая предметная область имеет свою специфику. И вот для этой специфики было бы не плохо применять верные концепции. Событийно-ориентированное программирование, компонентно-ориентированное программирование, сервис-ориентированная архитектура и т.п. Их не так уж и много.

Дык вот к чему я это все...

Как-то я услышал такую фразу:

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

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

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

Хе-хе.. что-то меня сегодня на красноречие пробило     

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

Я считаю, что это хорошо и объяснил почему. 

Не используя так или иначе механизм полиморфизма писать алгоритмы которые не привязаны к конкретным типам данных труднее (хотя и возможно).

sir_nuf_nuf, ок...

Один вопрос, является ли полиморфизмом такой код:

Ты объявил класс 'А', определил в нем какой-то метод 'b'. Далее унаследовался от него - класс 'А1' и переопределил метод - 'b1', далее унаследовался от 'А1' - класс 'А2' и переопределил метод - 'b2', и т.д.

Дык может ли быть метод 'b2' - полиморфизмом в данном контексте??

Нет, для того, чтобы он стал полиморфизмом, должен быть объявлен абстрактный класс 'AA' с методом 'b', и вот объявляя каждый раз новый класс, возможно даже родитель-потомок, ты должен переопределять метод из класса 'AA', а не из родительского. 

И вот насколько я знаю, как такого полиморфизма в перле вообще не существует.. При желании его можно достигнуть, немного кудряво...

Я ни коим образом не оспариваю, что хорошо и правильно использовать полиморфизм.   

Но вот возвращаясь к моему конкретному коду, это не полиморфизм. Это лишь некая абстракция, которая так и не доросла до полиморфизма, оставшись на уровне абстракции...

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

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

Более того, если кто-то действительно пишет на перле в ОО стиле, я снимаю шляпу перед такими людьми 

А в классе A методы b1  и  b2  имелись ?   Или, учитывая специфику perl,  хотя бы предполагалось  их наличие  (в java в таком случае используют абстрактные методы,  а в перл документацию или заглушку) ?
Если да - то приведенный пример - это пример перекрытия методов родительского класса (overriding).
Вызов такого метода у объекта - это полиморфный вызов.


 
Очень спорное утверждение. На мой взгляд полиморфизм в perl примерно такой же как и в Java 1.4 (когда еще не было templates)

Cформулируйте плиз, как вы понимаете полиморфизм.  Строки в 3 желательно.

Bulat, если хотите посмотрите исходники Catalyst

http://x0.org.ua/perl/8/Parley-1.2.1/lib/ 
http://x0.org.ua/perl/8/Foorum-0.3.0/lib/


Это сообщение отредактировал(а) gcc - 1.12.2009, 09:58

Реализация общего абстрактного метода в зависимости от контекста. Т.е. у нас есть некое абстрактное определение, которое стоит во (!) главе иерархии, не по середине являясь уже чьим-то потомком..
Таким образом, если A1 для A - еще может быть полиморфизмом, но уже A2 для A1 - никак нет, так как A1 - не стоит во главе иерархии. Ибо сама философия полиморфизма и абстракции предполагает наличие в отношении двух классов одного абстрактного(который не является ни чьим потомком), а второго как раз потомка текущего. 

gcc, как-нить гляну 

Bulat, у нас просто расхождение в терминологии.

не исключено.   

Программирование это абстрактная наука, в которой всегда может быть не одно верно решение(не одно верное определение и не один верный термин).   

Полиморфизм - это использование наследника вместо родителя. для цепочки 
class1->class2->class3 полиморфизмом будет

sub func1{
  my $object = shift; # ожидается class1
  $object->sub1(); # вызов функции, для которой сработает полиморфизм
}

func1($class1); - полиморфизм
func1($class2); - полиморфизм
func1($class3); - полиморфизм


sub func2{
  my $object = shift; # ожидается class2
  $object->sub1(); # вызов функции, для которой сработает полиморфизм
}

func2($class1); - НЕ полиморфизм
func2($class2); - полиморфизм
func2($class3); - полиморфизм



Но так как указать какой именно параметр ожидается в func1() и func2() в перле нельзя, то полиморфизм становится сомнительным понятием для перла - когда в func1() передаётся какой-то объект какого-то класса, не потомка class1, но имеющего метод sub1(). То есть полиморфизм есть, но из-за упрощённой реализации ООП это побочный эффект с особенностями. Moose: это пытается исправить, но пока не очень успешно.
Кстати, этот эффект используется при написании классов типа CGI - так как от него нужен только метод param(), масса классов принимает любой объект с таким методом, своего рода полиморфизм.

Наверно, на чистом перле просто не надо писать длинные цнпочки наследования.

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

Добавлено через 11 минут и 54 секунды
Допустим

class1 - животные
class2 - млекопитающие
class3 - собака

казалось бы, все не плохо так как закон наследования class1 -> class2 -> class3 - хорошо срабатывает

и если в class1 - func1 - "издает звук" - то собака(class3) - лает(func1 - переопределенный), но вдруг у нас появился class4 - рыбы, который претендует на то, чтобы стать наследником class1 и быть на одном ряду в иерархии с class2, но что тогда делать с func1 - определенным еще в class1, т.е. животное. Получается, что рыбы(class4) тоже "издает звук" - что абсолютно не правильно. Или придется для рыб делать эту функцию deprecated или возвращающим undef ?? )) Но ведь это все равно не правильно, в рыбы(class4) вообще не должен вызываться метод "издает звук"(func1) 

Я даже сделаю еще интереснее, кроме "издает звук"(func1) - у нас есть "моргает"(func2) - т.е. движение век, и казалось бы все не плохо, что животное(class1) - моргает(func2), млекопитющее(class2) - моргает(func2) рыбы(class4) - моргает(func2), собака(class3) - моргает(func2)...

Но вдруг у нас появился крот(class5), который наследник млекопитающее(class2), и по закону наследования он без проблем должен был унаследовать моргает(func2) - но ведь это не правильно.  крот вообще не должен "моргать" даже если возвращает undef  так как у него нет глаз. 

Дело в том, что это слишком абстрактный пример, из-за этого возникает путаница.
Напомню, так называемый девиз, который знаком если не всем, то многим ООП программистам (особенно Java  )  - "Разделяй и влавствуй".
Моргание - это свойство глаза, обьекты которого может и не иметь млекопитающее, соответсвенно оно и не сможет моргать. Если быть более точным, то моргание - это свойство века, а не глаза, но даже если мы сделаем его свойством глаза, нас это устроит, так как мы уже дошли до нужного уровня абстракции. (Во я загнул  ). Тоже самое относится и к рыбам.

Так же хочу обрать внимание, что я назвал не случайно моргание или способоность воспроизвести звук именно свойством, а не методом. Здесь важно парвильно задать вопрос:

Имеет ли млекопитающее глаза? (true || false)?
Если да, то может ли глаз млекопитающего моргать (true || false)?

Имеет ли рыба голос (true || false)?
Если да, то может ли рыба издать звук (true || false)?

Наверняка найдётся млекопитающее, которое имеет глаза, но оно не моргает, так же и некоторые рыбы могут издавать звук. После, на основе этих свойств, можно построить метод, который к примеру будет визуализировать глаза если они есть, а так же их моргание, если он они способны это делать. Можно построить и класс Voice с методом play(), который будет воспроизводить издаваемый звук, возможно немой, в зависимости от способности его издавать.

Это сообщение отредактировал(а) korob2001 - 11.1.2010, 15:57

Это не будет ни полиморфизмом, ни абстракцией. Не надо путать общественность. Абстракция - это интерфейс, полиморфизм - это реализация интерфейса. К контексту ни то, ни другое не имеет отношения.




Я не хочу Вас огорчить, но придётся  рыбы говорят. http://otvet.mail.ru/question/14061301/

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

Я тебе приведу другой более интересный пример из русского языка.

Любое предложение делится на слова, т.е. любое предложение состоит из слов - "Меня зовут Вася"... 3 слова.

А теперь разберем такие интересные моменты, как с одной стороны, часть слов можно поделить на "глагол" и "существительное", ну еще и кроме них есть )) Но в тоже время, в зависимости от контекста(предложения) часть слов делится на "подлежащее" и "сказуемое"

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




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



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