|
Модераторы: korob2001, ginnie |
|
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
А по теме, поднятой мной.
(см. http://forum.vingrad.ru/topic-132126.html ) Статья меня откровенно повеселила, Рад, что вас повеселила тоже. ИМХО, только две вещи автор отметил правильно. Все остальное - от (скорее всего) природной злобы автора и непонимания собственно Perl, его (Perl) назначения и места в мире языков программирования. Итак, две вещи: 1. Отсутствие нормальной (с точки зрения классического определения) поддержки ООП - объектно ориентированного программирования. Конечно, вы можете возразить, что на Perl все можно написать. Однако хочется, чтобы все это уже было внутри языка. Это лично меня приводит к некоторому внутренниему дискомфорту, когда пишешь на perl. А это, собственно, основной язык, которым я пользуюсь. 2. Неочевидность некоторых конструкций для (особенно) начинающего программиста-читателя. Неоднократно было подмечено. "Старт" проходит достаточно тяжело. Зато затем - почти все нормально. Из забавных фактов по этому поводу, хочется отметить, что одна моя знакомая, чтобы облегчить понимание приема параметров в процедуру, предложила назвать переменную @_ "собака с хвостом". Типа "а сейчас к нам пришла собака с хвостом". Вот так. Это сообщение отредактировал(а) Zuzu - 26.1.2007, 13:16 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Zuzu, а какую-такую "нормальную" поддрежку ООП ты хотел?
В Perl можно создавать пакеты, классы, собственно, объекты, есть множественное наследование, делигирование, возможность обращения к структуре класса-предка, можно использовать локальные переменные, есть механизм связывания (tie). Вообще, чего нет изначально в интерпретаторе-компиляторе, давно уже написано в модулях и прагмах или можно написать. Чего ещё требуется? Добавлено @ 10:46 Я тут вот начал-таки читать "статью" и уже с самого начала она мне стала нравиться, большую роль в это проишествии сыграла первая же фраза "Статья посвящена популярному языку программирования PERL". Ну, коли он популярный, значит, его много кто использует, а он решил выявить и представить какие-то недостатки, которые, фактически, если даже есть, то те, кто пользуется языком (а он "популярный"), готовы с этими недостатками смириться и продолжают пользоваться плохим языком Perl. |
|||
|
||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
Еще раз повторю, руками можно написать все. Речь идет о поддержке именно на уровне языка. 1. Нет на уровне самого языка самого такого понятия как "свойство" класса и объекта. Приходится для этого создавать свою структуру типа хэш ("по классике") или массив (как сказано в Advanced Perl Programming), причем, все писать руками. Следствие - нарушение такого понятия как инкапсуляция. А именно, инкапсуляцию нарушает возможность обратится к свойству объекта напрямую, а не через интерфейс объекта. Также возникает гемморой с множественным наследованием "свойств". СкАжите: хочешь строгости - используй use fields Отвечу - не работает это в случае множественного наследования. В документации об этом написано (собственно, и так понятно, почему не работает). Понятно, что вы (как собственно, и классики, типа Гаммы (одна из книг отсюда: http://ooad.asf.ru/Files.aspx)) можите возразить: не используй множественное наследование (а лучше и наследование вообще) - а используй композицию (или, если быть более точным, агрегацию (aggregation)). Отвечу: иногда хочется. Т.к. проектировать и читать такие программы приятнее и проще. Приведу пример из своих последних новогодних экспериментов (на уровне посленовогоднего бреда): (абстрактное) животное (есть имя и цвет) -> кошка (есть имя и цвет, умеет мяукать) (абстрактное) животное (есть имя и цвет) -> рыба (есть имя и цвет, умеет плавать) кошка + рыба -> кошкарыба (есть имя и цвет, умеет и плавать и мяукать) Ну и по мелочи. На уровне мелкого дискомфорта. 2. Следствие отсутсвия типизации - отстутсвие такого типа данных, как "объект определенного класса". То, по поводу чего автор статьи аж весь изошелся. Видете-ли (пред)компилятор не проверяет наличие/отсутсвие описанных методов (и процедур, собственно), и ошибка возникает на этапе выполнения. Собственно, понятно. Нет типизации - сам за всем следи. Плата за гибкость. 3. Отсуствие внутренних (используемых только внутри объекта) методов. Все можно вызвать снаружи. Опять - нарушение инкапсуляции. Решается административными действиями, путем описания, что все, что начинается с _ (подчеркивания) - внутренний метод. И, дополнительно, на уровне контроллера приложения (Aplication Controller см: http://ooad.asf.ru/Patterns_title.aspx?IdKat=9), чтобы обеспечить внешнюю безопасность, чтобы любой пользователь (не программист!) не смог вызвать внутренний метод объекта. Это сообщение отредактировал(а) Zuzu - 18.1.2007, 14:39 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
nitr |
|
|||
Эксперт Профиль Группа: Участник Клуба Сообщений: 2543 Регистрация: 10.2.2006 Где: Россия :) Репутация: 37 Всего: 84 |
Zuzu, ждём Perl6 можно и тут глянуть, с чем предстоит... думаю тебе понравится ;)
Добавлено @ 18:26 тут |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Zuzu, давай в приват, что ли. Поговорим на тему ООП.
Мне не понятно, почему ты говоришь, что у объекта в Perl нет свойств, т.к. свойства обычно хранятся в хэш-массиве, а если ты под свойствами имеешь в виду синтаксическое их написание без фигурных скобок, так это всего-то особенность языка (может, скажешь, что тебя и $ или % тяготит?). Таак, ну в Delphi, там можно указывать методы обработки работы со свойствами типа getter и setter. Это в Perl решается с помощью встроенной функции tie. Какой-такой геморрой со множественным наследованием? На счёт инкапсуляции. Таак. Ну, вот её-то и нету. Да, только, принципиально, она нужна? Объявление типа private беспокоит тех, кто борется за свои авторские права, а Perl создан как Free и OpenSource - идеология такая. Я принципиально-против типов данных в Perl - тоже нарушает идеологию, т.к. Perl создавался для манипуляции структурами данных, а про типы думать не надо. Не, ну ты мне приведи задачу, которую не возможно решить с помощью языка. [hr] nitr, про Perl6 уже обсуждали в другой теме. Это сообщение отредактировал(а) tishaishii - 18.1.2007, 20:07 |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Zuzu, к стати, я вспомнил. Функции и свойства вроде private можно организовать с помощью встроенной функции caller и при определённом методе AUTOLOAD в классе.
|
|||
|
||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
tishaishii, отвечу лучше здесь. Про tie ты ведь мне идею подсказал, спасибо. Может еще у кого какие мысли будут.
1. Под свойством объекта я понимаю не конструкцию (на самом деле, вообще неважно, какого) языка типа "что-то там с фигурными скобочками", а вполне определенную вещь - некую область для хранения данных, принадлежащих объекту. При этом совокупная целостность (непротиворечивость) данных объекта должна быть реализована на уровне объекта. Простой пример - поле (строки) таблицы базы данных, для которого определено NOT NULL, а ему пытаются присвоить значение NULL. Что произойдет? DBMS выругается и неверного значения (в общем случае, строке) не присвоит! 2. За идею про tie и связывание свойств почитаю, спасибо. Но, ИМХО, очень уж тяжелая конструкция получается. 3. Privte методы реально упростили бы жизнь с точки зрения внешней безопасности приложения (см. п. 3 моего предыдущего топика). Напрягает больше не то, что нужно описывать (на уровне if или в самом объекте), какие из его методов можно вызывать снаружи (из web-интерфейса, например), а то, что потом все это нужно проверять. Объект-то про свою целостность должен знать сам! А если этот объект участвует во множественном наследовании - всех "родителей" приходится обходить "вручную", чтобы все это выяснить. Так что по поводу Private не нужно путать теплое с мягким! К авторским правам оно имеет такое же отношение, как морская свинка к морю. 4. Нет инкапсуляции - нет поддержки ООП (ООП есть инкапсуляция, наследование, полиморфизм). Извини, элементарная математическая логика. Все выражение истино тогда и только тогда, когда все его "слагаемые" истины. У Вирта, кажется это есть. Может у кого ссылка есть на библиотеку с книжками Вирта? Поделитесь ссылочкой. 5. Про AUTOLOD и "автоматическую генерацию методов", если ты внимательно почитаешь Advanced Perl Programming (и в Cookbook, кажется, написано тоже), там есть один прикол. До вызова AUTOLOAD необходимо определить (присвоить значение) элементу хэша. При отсутствии элемента инициируется исключение (die). И, собственно, понятно, почему. Нечего всякую ерунду для для объекта вызывать! При обычном наследовании еще можно определить (инициировать) значения элементов хэша путем обращения к процедуре инициализации своего суперкласса ($self->SUPER::_init() - как вариант). При множественном наследовании это не прокатит - нужно обходить всех "вручную". 6. Про типы данных - ты зря! Но это мое личное мнение. Я бы не отказался. 7. Написать можно что угодно и на чем угодно. Хоть в машинных кодах наколбасить. Особенно если воспользоваться "абстракцией потенциальной осуществимости" из математики (типа если все живем вечно и кормить никого не нужно - тогда напишем любую программу). Я не хочу "хаять Перл". Он меня кормит! Просто есть вещи, которых "жалко что в Перл нет". Вообще, сам на досуге "поиграйся" с поддержкой ООП в перле и попробуй реализовать классические вещи (хотя бы на уровне модели, когда результатом $aCat->speak просто является print "Meauuuu!!!\n"), которые описаны в литературе по ОО программированию (а лучше по ОО проектированию). Хотя бы с наследованием свойств и методов и их, (свойств и методов) полиморфизмом - раз уж выяснили, что инкапсуляции нет Лично мне это упражнение доставило в свое время истинное удовольствие. P.S. Господа модераторы! Подскажите тему, куда это все перенести! Извиняюсь за offtopic. --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Короче, прошу прощения, у меня не много времени на ответ.
Вот ты мне приведи задачу, которую не возможно решить на Perl. |
|||
|
||||
korob2001 |
|
|||
Эксперт Профиль Группа: Комодератор Сообщений: 2871 Регистрация: 29.12.2002 Репутация: 31 Всего: 61 |
Вынес всё, что касается ООП в отдельную тему. Здесь можно продолжить обсуждение. -------------------- "Время проходит", - привыкли говорить вы по неверному пониманию. "Время стоит - проходите вы". |
|||
|
||||
tishaishii |
|
||||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Zuzu, ну у меня реальные вещи в голове не укладываются пока без ООП. Так что играюсь уже с этим ООП в Perl года 2-2,5 и говорил тебе всё это не по-наслышке.
А что сложного там в tie - это не в курсе. На худой конец есть уже готовые модули (типа Tie::Hash... - http://search.cpan.org/search?query=Tie%3A...mp;mode=module). Ну вот тебе готовый код, например, для скаляра (можно использовать как свойство в классе):
а вот пример его применения:
Если есть вопросы как работает - пиши. Это сообщение отредактировал(а) tishaishii - 24.1.2007, 17:20 |
||||
|
|||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
tishaishii, спасибо за пример. Посмотрел код. Забавно.
Лично я фразы типа +$${$_[0]}{-setter}(@_) понимаю только после вдумчивого второго прочтения... Наверно, возраст, сказывается... Но все-таки понимаю, что радует! Спорить о том, как прогрммировать (и как не нужно программировать) считаю абсолютно бесполезным. Каждый, особенно если работает самостоятельно , а не в команде, волен выбирать это для себя сам. И собственно, "мысли по коду". Во-первых, лично я считаю, что класс (Class) должен сам знать о свойствах объектов, которые от него порождены и переписывать их (свойства) во время создания экземпляра (объекта) не считаю правильным. Нарушается идея "представления объекта, как черного ящика". Как следствие, если ты вдруг нашел ошибку в коде какого-то setter-а, например, то тебе придется его выискивать и исправлять ошибку во всем своем коде, а не "просто поменять в классе". А если твой класс используется в качестве компонента другой системы? Радости от такого программирования и дальнейшей поддержки кода очень мало. И еще, ИМХО. В нотации UML (по крайней мере UML 1.4) принято обозначать "закрытые" свойства с - в начале (-privateName), а "открытые" с + (+publicName). Т.к. в perl нет такого понятия как "закрытое свойство" на уровне языка, лично я предпочитаю на "смешивать понятия", а использовать принятые в Perl соглашения. А именно, если имя начинается с _ - это "внутренняя штучка" объекта (_name) . Иначе - "открытая штучка" (name). Это сообщение отредактировал(а) Zuzu - 25.1.2007, 15:27 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
tishaishii |
|
||||||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Ну, пользуясь таким Class, ты можешь породить класс Child:
Использование:
Добавлено @ 19:27 Если хочешь обрабатывать аргументы в Child::new:
Это сообщение отредактировал(а) tishaishii - 25.1.2007, 19:24 |
||||||
|
|||||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Короче, ты уж определись, нужен тебе Perl 5.8, али - нет?
Он помогает легко решать многие проблемы, которые не так легко решить в друших языках (кроме Refal и Prolog, наверное). Но есть куча модулей на search.cpan.org, которые тебе чрезвычайно помогут. Возможно переписывание операторов (как в Ц). Возможно подключение АктивИкс-объектов - а их ты можешь создать сам, а вот такой простой язык с ними использовать очень удобно. Какие ещё-там проблемы с ООП - говори - предложу подходящее решение. Добавлено @ 23:07 Таак, ещё, про private тебе надо приводить пример про caller, AUTOLOAD и @AUTOLOAD? Это, как всегда, просто. При вызове метода, всего-то, надо распознать модуль, вызывающий метод. Для Perl 5.8 - это СЛОЖНЕЙШАЯ ЗАДАЧА. )))) |
|||
|
||||
Zuzu |
|
||||||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
Спасибо, конечно. Если будут толковые вопросы - задам.
Опять-двадцать пять! Мы, видимо, просто говорим на разных языках и тебя сбило с толку замечание о том, что необходимо будет менять код в разных местах при нахождении ошибки... И чем твой код концептуально отличается от того, что было в предыдущем варианте? Да ничем! Ты определяешь (инициализируешь) структуру данных (вместе с getterom!) на этапе выполнения а не на этапе описания. Да еще через связывание с использованием tie, да еще передав ее (структуру) SUPER-классу... Что по мне, то я готов смириться с тем, что "хэш объекта" - вещь, которую "руками не трогать" (на уровне административных мер, как вариант, при работе в команде), а для определения (читай - "описания", которое можно понять даже не запуская программу, прочитав при этом код самого класса, а не "шарашась по всему коду") использовать что-то полегче типа трививального, рекомендованного в стандартной документаци по Perl.
При этом, по крайней мере, возникает иллюзия, что мы обращаемся к свойству объекта через интерфейс объекта (т.е. "как положено"). Как бесплатное приложение - можно проектировать задачу с помощью стандартных средств, понимающих UML (жалко, для перла нет автоматической генерации кода классов из них! собственно, понятно, почему). И реализация получается "тупее". Читай: - Через год можно будет ее понять, даже не вникая в суть проблемы. - Реализовывать и поддерживать можно будет отдать программисту, который "с неба звезд не хватает". - Вообще меньше загружен мозг при реализации, если пишешь код сам. Нужно просто "тюкать по клавишам" или, как вариант, сконцентрироваться на аспектах реализации, решая при этом одну частную проблему, а про общую логику "всего комплекса" можно просто на время забыть. Обо всем этом позаботились раньше при проектировании, тестировании и проверке модели на этапе проектирования. Можно даже попытаться доказать правильность алгоритма аналитически (т.е. без реализации, не запуская) - сам алгоритм-то меньше получается! Что-то стало смахивать на "религиозные войны"... А так вообще (скажу, наверно, банальную мысль) я придерживаюсь мнения, что каждый может все писать так, как ему удобнее. С учетом "административных требований" команды, в которой работаещь, конечно. --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
||||||
|
|||||||
tishaishii |
|
||||||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Я указал параметры на этапе описания и с чего ты там взял про "выполнение", когда при описании модуля я использовал другой модуль и описал первый.
Ты вообще в курсе, что такое "SUPER::new"? Это аналог "super" в Java. И ты хочешь ещё бороться с тем, что ООП в Java плохое? И что означает восклицание
По-моему, ты просто не до конца понимаешь примера, что я написал. Чувствую, у тебя есть психологическая проблема: ты озлоблен, причём на вещь, которая существует только в твоём воображении - на язык программирования. |
||||||
|
|||||||
tishaishii |
|
||||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Чем тебе не угодил хэш-массив? Думаю, просто для тебя это что-то новое и не знакомое, на самом деле логически он присутствует в любом языке программирования. Ну ты же можешь описать класс так:
Это сообщение отредактировал(а) tishaishii - 2.2.2007, 04:17 |
||||
|
|||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Короче, вот тебе тот же пример, но в файлах и с некоторыми комментариями.
Чтобы испытать надо выполнить команду (в командной строке):
Это сообщение отредактировал(а) tishaishii - 2.2.2007, 04:13 Присоединённый файл ( Кол-во скачиваний: 23 ) Class.zip 1,57 Kb |
|||
|
||||
tishaishii |
|
||||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Тут ты что-то загнул. На заборе "В. Цой" написано, а за ним ничего нет. Вот тебе пример с AUTOLOAD, чтоб ты поразбирался с "истинным удовольствием".
И где тут какая-то дребедень, которая там, у тебя в книжке написана? Плохая книжка. Это сообщение отредактировал(а) tishaishii - 2.2.2007, 05:00 |
||||
|
|||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
Хэш-таблица* - это элемент языка программирования, являющийся особенностью реализации на конкретном языке программирования. Где написано, что использовать напрямую Ээлементы реализации" не рекомендуется - да в любой книжке, что посвящена объектно ориентированному программированию, а лучше, объектно-ориентированному проектированию Очень логично, на самом деле. И авторы приводят массу доводов для этого.
Приходит на ум книжка Ф.Брукса "Мифический человеко-месяц", который в качестве правильного метода проектирования рекомендует работать отдельно с сущностью объектов, вне зависимоти от акциденции (реализации на конкретном языке). И вот, в частности, та, что лежит у меня сейчас на столе ближе всего ко мне Дж.Рамбо. М.Блахо UML 2.0 Объектно ориентированное моделирование и разработка. 2-е изд. - СПб.: Питер, 2007. -- 544 с. ил. Про твой пример: (я про AUTOLOAD) И где здесь класс? Какова его концептуальная сущность? Где его методы? Каков его интерфейс? Вообще интересно, как ты трактуешь понятие "полиморфизм" на своем классе. Элемент программной реализации, который делает что-то "непонятно как" - это далеко не класс! Представляешь, ты просишь собаку замяукать (вызвать метод, про который объект, порожденный от класса "собака", просто не знает)! Не знаю как у кого, а моя собака посмотрит при этом на меня, как на идиота. Заставить собаку мяукать - это абсурд, правда? Зачем же тогда так поступать со своими объектами? А предстваляешь удивленные глаза начинающего программиста, которому этот код будет отдан в поддержку! Как говорит один мой знакомый: "Так объясни мне! Не могут же все быть такими умными как ты!".
Кстати, про AUTOLOD (и про "начальное определение свойств") написано в Advanced Perl Programming, Cookbook, perldoc perltoot - источники для тебя авторитетные? Для меня - да. Предпринимается некоторая попытка достичь хотя бы иллюзии инкапсуляции для класса в Perl. --- * В перле, кстати, не хэш-массив, а именно хэш-таблица. Т.е. элементы хэша хранятся не "друг за другом", а "каждый сам по себе". Или, по-другому, механизм, который определяет способ задания адреса элемента для массива и адреса элемента для хэша - совершенно различен! Для массиива - последовательное хранение адресов, когда, адрес каждого элемента можно однозначно вычислить по номеру в массиве. Для хэша - некая функция, которая вычисляет адрес элемента по значению ключа. Именно поэтому хэши медленнее работают. Достаточно давно об этом где-то читал. Конкретно где, к сожалению не помню. Это сообщение отредактировал(а) Zuzu - 2.2.2007, 11:59 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
Shaggie |
|
|||
Опытный Профиль Группа: Завсегдатай Сообщений: 570 Регистрация: 21.12.2006 Где: outer space Репутация: нет Всего: 72 |
Массивы предпочтительнее использовать там, где требуется последовательный перебор значений, хэши - для поиска конкретного значения (с этим они справляются гораздо быстрее) Согласен с Zuzu. Объектная модель в Перле напоминает постоянно отпадающие при ходьбе костыли. Перл 6 будет объектно-ориентированным языком. Собственно, из-за проблем с реализацией объектности при сохранении работоспособности более ранних программ мы ждем так долго А пока я почти не использую объекты в Перл. |
|||
|
||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
Shaggie, я бы не был столь категоричным! Можно их (объекты в Perl) использовать. Естественно с некотрыми допущениями (Попробуй, кстати, это прикольно! Если что - можно обсудить либо в форуме либо в ЛС). Проблема в том, что эти "допущения" несколько нервируют, когда переходишь от проектирования к реализации - просто не получается математически точная реализация модели (математически точная - значит реализация должна делать то, что должна делать и не должна делать, то, что делать не должна - именно так)! Не удержусь, приведу цитату из Дж.Рамбо:
"Реализация. ... Никаких усложнений на этом этапе быть не должно, потому что все ответственные решения уже были приняты на на предыдущих этапах. ... соответсвие кода проекту должно быть очевидным, а система гибкой и расширяемой. ..." А про хэши и массивы - естественно разговор про "примерно однотипные задачи", например, скорость последовательного выбора всех элементов. Хороший пример - реализация свойств (если более более корректно - данных) объекта на в виде "приведенного" (blessed) хэша, а в виде "приведенного" массива, есть в Advanced Perl Programming. Это сообщение отредактировал(а) Zuzu - 2.2.2007, 10:41 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
Shaggie |
|
|||
Опытный Профиль Группа: Завсегдатай Сообщений: 570 Регистрация: 21.12.2006 Где: outer space Репутация: нет Всего: 72 |
А я не категоричен Объекты в Перл я не ипользую по той простой причине, что работаю в PHP. Перл - это мое большое увлечение. За пару дней до нового года купил кэмел бук (Programming Perl), просто так, для себя. Прочитал дважды, теперь всю работу в системе оптимизирую с помощью скриптов. Собираюсь бросать PHP, он уже кажется мне ограниченным и надуманным. Но до серьезных проектов не доходило, увы.
Такой вывод я делаю на основании прочитанного материала в вышеупомянутой книге, комментариев Ларри и содержании сайта perl6.ru Необходимость насильно закрывать внутренние поля и методы, трудности с export, многозначность @ISA, постоянный контроль обращений к твоему пакету... Перечитал тему... Я, похоже, и в самом деле чересчур категоричен Это от недостатка опыта, прошу извинить. |
|||
|
||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
Давай другими словами напишу, что ты делаешь. Ты меняешь поведение (метод) наследника путем изменения структуры данных (свойств) суперкласса. Пичем происходит это наэтапе выполнения. Извини, уж не знаю, зачем для такой простой задачи нужна такая, мягко говоря, громозкая реализация. Если тебе это реально надо что-то подобное (пример просто в голову не приходит - уж не знаю, в каких случаях это можно применить) - есть нормальные и формализованные решения, описанные, например, в книжке Гаммы про шаблоны (patterns) проектирования. Это сообщение отредактировал(а) Zuzu - 2.2.2007, 12:58 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
amg |
|
||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1145 Регистрация: 3.8.2006 Где: Новосибирск Репутация: 38 Всего: 50 |
Я бы сказал, что если пытаться реализовать через массивы задачу, которую можно сделать через хэш, то (значительного) выигрыша по времени не будет (см. тесты).
А вот в памяти один хэш заметно больше места занимает, чем два массива. Зато достут к элементу хэша по ключу мгновенный вне зависимости от размера хэша. |
||||
|
|||||
Nab |
|
|||
Опытный Профиль Группа: Участник Сообщений: 582 Регистрация: 25.3.2006 Где: Kiev Репутация: 26 Всего: 37 |
Zuzu, я боюсь ты все таки не верно понял, о чем говорит tishaishii
Он предложил вполне законченное решение суперкласса, которым вполне можно заменить UNIVERSAL И при создании любого собственного класса, использовать ту конструкцию что он привел.... не для конкретного екземпляра, а именно для описания поведения класса, объекты создаются как всегда, и внешний интерфейс ничем не измениться, кроме того, что это будут свойства очень похожие к примеру на Delphi... То что он привел пример где свойство описывается для объекта, то имхо не удачный пример, в присоединенном файлике как раз наоборот, все очень правильно, и красиво... Хотя в другом я с тобой согласен, нету однотипности Если этот тип описания использовали изначально и как базовый класс для всех остальных, то да, очень елегантное решение, но реальность такова, что его конструкция в действительности немного громоздкая, хотя не лишена некоторых прелестей... Я когда познакомился с tie тоже очень загорелся созданием своих типов, которые бы вели себя так, как мне нужно, даже создал регистронезависимый хеш и массив был у меня который при undef элементу удалял его, то есть всегда имел определенные значения, много чего было, но оно както не прижилось, вполне хватает сейчас стандартных возможностей языка... А в плане свойств недавно сделал такую вещь, у меня в конфигураторе было так $config->param('fff') - возвращает значение $config->param('fff, 'new') - возвращает старое значение, присваивает новое но вспомнив про левосторонние функции сделал так в определении param
все больше не менял ничего теперь можно вызыыать конфигуратор и так $config->param('fff) = 'new'; все очень даж приятно выглядит... конечно остается возможность напрямую обратиться к внутренностям $config, но я считаю что вполне достаточно педальки перед внутренним методом Ну а если нужно, то пускай человек лезет, это его проблема... я честно предупредил "НЕ НАДО" -------------------- Чтобы правильно задать вопрос нужно знать больше половины ответа... Perl Community FREESCO in Ukraine |
|||
|
||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
amg, если мне память не изменяет, минимальный размер свертки для хэша в перле составляет 8 элементов. В теории, по технологии создания хэша, адрес в свертке определяется по ключу (есть некоторая функция, которая ставит в соответсвие ключу адрес пары ключ-значение в памяти). Попробуй увеличить размер массива и хэша, например, по 1500 элементов и в качестве ключа хэша использовать что-то типа random(9999) x 5 для ключа, чтобы ключ был слегка подлинее. Подозреваю, что возрастет кол-во коллизий при определению адреса элемента по ключу в хэше.
Кстати, чтобы больше "напрячь" хэш по премени, можно попытаться извлекать элементы из него в порядке вставки (или в случайном порядке), а не в том порядке, который он, хэш, сам возвращает. Можно случайным образом выбирать несколько элементов n ключей и n номеров и сравнить время их выбора из массива и хэша. По документации - должно быть до 30% разницы в скорости выбора. Хотя лично сам такими проблемами не заморачивался. Стараюсь по возможности минимизировать структуры данных в памяти. Там где нужен хэш (в частности для хранения неупорядоченного множества) исползьую хэш, там где важен порядок - массив. Наверно, банальную вещь сказал.. Nab, в приведенном примере (даже если он работает - проверить просто не было времени, а при прочтении, что он работает, для меня лично неочевидно), без переписывании Child, очень затруднено наследование свойств от класса Child (добавлене новых свойств, переопределение текущих свойств, например в классе SmallChild - наследник Child (да простят меня знатоки UML за текстовую, а не визуальную запись!): Class () <|--- Child (+p2, +p3) <|--- SmallChild(+p2, +p4) Т.е. в классе SmallChild должно быть три свойства: p2, p3, p4. Скорее всего, достаточно просто решается путем небольшой корректировки кода класса Child. А вот с множественным неследованием от класса Child возникают серьезные проблемы. Там кода наколбасить придется очень много, чтобы все это работало нормально. Причем именно в конструкторах классах-потомков. Про lvalue - спасибо, попробую. В каком Perl, это кстати, появилось? Это сообщение отредактировал(а) Zuzu - 5.2.2007, 11:01 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
amg |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1145 Регистрация: 3.8.2006 Где: Новосибирск Репутация: 38 Всего: 50 |
Действительно, при увеличении длины ключей с 16 до 160 символов доступ к элементам хэша по ключам замедляется (примерно в 2 раза) и становится в 2-3 раза медленне, чем доступ к элементам массива по индексам (который, кстати, практически не замедляется при увеличении размера элементов). Проверил и это. Документация не врет Кстати, доступ к случайным элементам массива тоже раза в 2 медленнее, чем по-порядку. Добавлено @ 15:26
Это сообщение отредактировал(а) amg - 5.2.2007, 16:00 |
|||
|
||||
tishaishii |
|
||||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Zuzu, а если сделать такой хэш, который не поместится на все твою оперативку, винты, флэшки, DVDшки и всё прочее, что тогда делать? А нечего тогда такой хэш делать, реально для этого есть СУБД или искать способы оптимизации или писать в машинных кодах. Что-то это, по-моему, перегиб уже пошёл.
А я создал ради прикола или лени с помощью String::Approx и Text::Soundex класс с AUTLOAD со свойствами и методами, причём имя свойства или метода можно задавать при использовании как угодно, т.к. находится самое похожее по названию из имеющихся, это чтобы для разгильдяев, чтобы в именах методов и свойств можно было ошибаться. Ну это ни куда не годится, просто можно программировать и обезьяне чтобы можно было. Ну вроде как:
Это сообщение отредактировал(а) tishaishii - 5.2.2007, 17:51 |
||||
|
|||||
Zuzu |
|
||||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
tishaishii, пожалуйста, давай останемся в рамках темы, т.е. обсуждать именно аспекты ООП и его реализации а Перл. Про tie - то подсказал, спасибо. Может я чего не понимаю. Не сочти за труд, покажи, пожалуйста, как на твоем классе реализовать такую простейшую модель, как та, что изображена на рисунке. Там изображено множественное наследование свойств. Класс Child должен наследовать свойства p1, p2, p3, p4. Если воспользоваться рекомендациями из документации по Перл, решается примерно так:
Извините, если что не так - набивал код прамо в форум. Это сообщение отредактировал(а) Zuzu - 5.2.2007, 18:26 Присоединённый файл ( Кол-во скачиваний: 17 ) simple.gif 1,47 Kb --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
||||
|
|||||
Nab |
|
||||||
Опытный Профиль Группа: Участник Сообщений: 582 Регистрация: 25.3.2006 Где: Kiev Репутация: 26 Всего: 37 |
Ну так и супер.... Я такой состряпал для имен модулей, у меня теперь есть: use_similar 'DATA_Dumper'; подгрузка модуля... на ходу... аналогична таким use_similar 'DATA::Dumper'; use_similar 'DataDumper'; .... там несколько режимов совпадения и работает вполне корректно... Есть более строгий режим, там условия поиска жестче... Вопрос производительности еще не решен, но заглушки для кеширования поиска по диску сделаны, так что дойдут руки и до него кстати мой конфиг тоже имеет AUTOLOAD и тоже левосторонний так что и $config->fff = 'new'; тоже катит А вообще это уже не в тему, точно Zuzu заметил
Zuzu, множественное наследование вообще гадость редкостная, в особенности в связке с AUTOLOAD у родителей Возможно ктото его и использует активно, но я стараюсь держаться от него подальше, хотя и использую несколько маодулей со CPAN в которых оно используется... Насколько я знаю красивого решения оно не имеет ни в каком мне известном языке... (могу ошибаться). Ну а в перл, думаю лучше всего использовать агрегацию... -------------------- Чтобы правильно задать вопрос нужно знать больше половины ответа... Perl Community FREESCO in Ukraine |
||||||
|
|||||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Не знаю, на каком языке ты говоришь, Nab, но множественное наследование - вполне ясная вещьчь: кто последний, тот и прав.
|
|||
|
||||
Zuzu |
|
||||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
Т.е. ты утверждаешь, что если есть метод m1() в классе Father и Mather, Child - их наследник (от Father Mother), то выполнится код от Mother? Или приведенный ниже код выдаст результат "M1 from Mother", так?
Ты заблуждаешься! В перле - другие правила поиска методов. Описаны правила, в частности, в Cookbook. Будет "M1 from Father". Или в записи use base qw/Father Mother/ ты считаешь Father последним? Это сообщение отредактировал(а) Zuzu - 7.2.2007, 09:49 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
||||
|
|||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Я ту книжку частично для справки читал, а лучше читать художественную литературу или газету иногда, а языком программирования надо пользоваться. Ну я в параметры base::import в Child местами попереставлял, получил, что работает "кто первый, тот и прав". Ну так и что же в этом мудрёного? |
|||
|
||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
tishaishii. То, что я описал - очевидно. И следует непосредственно из оригинальной документации по Perl. Там написано все очень четко.
Правило "Кто первый, тот и прав" - тоже не катит. Ниже - простейший код. Какой метод m1 снаследует Child в этом случае? По твоему предположению - выходит от Mother - это неверно.
Спросишь, к чему это я? Во-первых, лично я привык понимать, что делает программа без ее запуска на выполнение. Очень часто это спасало, когда нужно было быстро исправить ошибку на "живом" проекте, который реально работает. А на "исправление по всем правилам" - перенос всего кода и данных на площадку поддержки, исправление и отладка там, перенос отлаженного кода обратно на "реальный проект" - просто заказчик не дает времени. А во-вторых, просто хочется увидеть код твоего класса с геттерами-сеттерами через tie для моей простейшей модели с множественным наследованием. Той, что я рисовал в виде диаграмки. Я свой код написал прямо в форум буквально за пару минут. Это сообщение отредактировал(а) Zuzu - 8.2.2007, 10:56 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
Nab, я посмотрел lvalue применительно к методам класса (как к setter'ам для свойств объекта). Мне не понравилось. Ожидал чуда, а они работают именно как lvalue Т.е. меняют значение переменной, указанной в return процедуры.
Соответсвенно, никакой радости в виде проверки корректности данных (внутри процедуры-метода) мы не получаем - работаем-то внутри процедуры со старыми, предыдущими значениями. Короче, скорее всего, использовать не буду. Смысла не вижу. Несколько сумбурно получилось. Если что непонятно написал - говори, приведу пример кода. Это сообщение отредактировал(а) Zuzu - 8.2.2007, 12:01 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
nitr |
|
||||||||
Эксперт Профиль Группа: Участник Клуба Сообщений: 2543 Регистрация: 10.2.2006 Где: Россия :) Репутация: 37 Всего: 84 |
Zuzu, я думаю тут видно...
тут первый Father меняем и получаем )
tishaishii, прав с этим правилом ;) |
||||||||
|
|||||||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
nitr, вопрос был не в том, как сделать, чтобы вызвался "M1 form Mother", а в том, какой метод реально вызовется без внесения изменения в код.
Если (для моего последнего примера кода) пользоваться правилом "Кто первый, то прав", должет вызваться "M1 from Mother", а это не так. Думаю, не открою тайну, если скажу, что результат будет "M1 from Class" т.е. Child при такой записи наследует метод от своего "самого базового" класса. Это, с какой-то стороны, логично, но без прочтения документации неочевидно. Это сообщение отредактировал(а) Zuzu - 8.2.2007, 12:17 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
Все, до меня наконец-то дошло, почему концептуально все работает именно так.
tishaishii, ты абсолютно прав! Работает правило "Кто первый тот и прав". Все абсолютно логично. Просто нужно рассматривать классы, как некую "конечную сущность". Действует правило, аналогичное правилу написния UML-диаграмм, которое, если просто, гласит: что если чего-то не написано, это еще не значит, что его нет. В моем примере у класса Father уже есть метод m1(), несмотря, на то, что в самом классе его нет. Father его снаследовал от Class! По правилу "Кто первый, тот и прав" - первый Father. У него есть снаследованный метод m1(). Именно он и наследуется. Это сообщение отредактировал(а) Zuzu - 8.2.2007, 12:48 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
Nab |
|
|||
Опытный Профиль Группа: Участник Сообщений: 582 Регистрация: 25.3.2006 Где: Kiev Репутация: 26 Всего: 37 |
приводи -------------------- Чтобы правильно задать вопрос нужно знать больше половины ответа... Perl Community FREESCO in Ukraine |
|||
|
||||
Zuzu |
|
||||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
Nab, пример кода с lvalue
Результат:
--------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
||||
|
|||||
Nab |
|
|||
Опытный Профиль Группа: Участник Сообщений: 582 Регистрация: 25.3.2006 Где: Kiev Репутация: 26 Всего: 37 |
Стыдно мне, таки нифига оно не работает
Плохо проверял однако И не до конца разобрался Приношу всем извенения, за то что ввел в заблуждение народ.... -------------------- Чтобы правильно задать вопрос нужно знать больше половины ответа... Perl Community FREESCO in Ukraine |
|||
|
||||
Shaggie |
|
|||
Опытный Профиль Группа: Завсегдатай Сообщений: 570 Регистрация: 21.12.2006 Где: outer space Репутация: нет Всего: 72 |
Zuzu, по-моему, то как раз то, чего можно ожидать от использования lvalue. WYSIWYG кажется это называется... Nab, за что извиняешься? Мне вот кажется, что ты прав. |
|||
|
||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
Shaggie, я ожидал от lvalue чуда в том смысле, что надеялся, что оно сначала (грубо говоря, перед первой строкой кода процедуры) присвоит значение переменной, а уже внутри процедуры-метода можно будет использоваться именно это, новое значение. По аналогии с передачей параметров внутрь процедуры.
При проверке выяснилось, что не так (см. пример кода). Это сообщение отредактировал(а) Zuzu - 9.2.2007, 10:58 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Т.е. ты нарочно схимичил и не переписал метод m1 для Father, чтобы с первого взгляда казалось, что вызывается не Father::m1, а Class::m1? Не получилось у тебя запутать:)))
И чего такого "чудесного" от lvalue ты ожидал? Механизм как механизм, а ты ждал "чудесный" механизм? Ну и используй значение, кто не даёт? Вобщем, что-то мне уже эта тема надоела, в основном приходится доказывать, что 1=1, а 0=0 - тавтология. Это сообщение отредактировал(а) tishaishii - 11.2.2007, 08:30 |
|||
|
||||
Shaggie |
|
||||||||||||||
Опытный Профиль Группа: Завсегдатай Сообщений: 570 Регистрация: 21.12.2006 Где: outer space Репутация: нет Всего: 72 |
Мои пять копеек.
Zuzu где-то отметил трудности с созданием закрытых методов класса (по типу private). Рискуя изобрести очередную вариацию велосипеда, я все же решился провести некоторые опыты и на личном примере убедиться в истинности либо ложности данного утверждения. Для примера Zuzu предлагал создать класс Кошка и объявить в нем метод Говорить... Ок, так и поступим.
У нас есть кошка Тася, которая говорит "Мяу". Вопрос - метод закрытый? Ну, как сказать... Например, имеет силу такой вот код:
То есть объект не создан, память не выделена. Мяукает какая-то совсем другая кошка, не та, которую я позвал... Была недавно тема о том, как определить, объект ли передан в функцию. Самый простой способ:
И теперь некая безымянная кошка мяукать не может. Однако... say - это просто функция по большому счету. То есть имеет смысл такой вот код:
И если не будет той проверочной строчки в say, то любой волк в кошачьей шкуре сможет сказать "Мяу". А теперь вылезает ошибка, так как параметры в функцию не передаются, и shift ругается на unitialized value. Исправляем:
И только потом до меня дошло, что проверка на "=" сработает на ЛЮБОМ объекте, передаваемом в функцию! Для проверки я создал пакет Dog, в нем метод call, совершенно аналогичный такому же в Cat. И теперь:
И пес Пират мяукает по-кошачьи! Прелестно... но надо править.
Вот это получилось похоже на закрытый метод. Как видим, в Перл возможность создания закрытого метода класса не поддерживается на уровне языка, но легко осуществляется его же возможностями. Это мой первый опыт объектного программирования в Перл, поэтому просьба комментировать если оказался не прав. И наверняка существуют модули под это дело... |
||||||||||||||
|
|||||||||||||||
nitr |
|
|||
Эксперт Профиль Группа: Участник Клуба Сообщений: 2543 Регистрация: 10.2.2006 Где: Россия :) Репутация: 37 Всего: 84 |
Shaggie,
для этого есть Class::ISA(::self_and_super_path как пример) там можно и смотреть... может кто скажет, что тут имеете ввиду под "закрытыми методами класса (по типу private)"? А то неувязочка в моей голове... |
|||
|
||||
Nab |
|
||||||
Опытный Профиль Группа: Участник Сообщений: 582 Регистрация: 25.3.2006 Где: Kiev Репутация: 26 Всего: 37 |
С этого и начнем проверка на принадлежность определенному классу делается проще всего:
А я искал способ определить приведена ли ссылка. Второе, private метод это метод который в принципе не виден и не может быть вызван, ВООБЩЕ. А реализовывается он при необходимости таким способом:
все , метод say может быть вызван только внутри ФАЙЛА, содержащего пакет и нигде более... даж потомки не смогут, если они определены в другом файле. Если как в Вашем примере, то они могут звать друг друга как угодно... Это сообщение отредактировал(а) Nab - 12.2.2007, 13:46 -------------------- Чтобы правильно задать вопрос нужно знать больше половины ответа... Perl Community FREESCO in Ukraine |
||||||
|
|||||||
Nab |
|
|||
Опытный Профиль Группа: Участник Сообщений: 582 Регистрация: 25.3.2006 Где: Kiev Репутация: 26 Всего: 37 |
А если файл Dog.pm
сделать таким:
то отраютают и gav и gav_gav. но во втором случае собака всеже залает -------------------- Чтобы правильно задать вопрос нужно знать больше половины ответа... Perl Community FREESCO in Ukraine |
|||
|
||||
Shaggie |
|
|||
Опытный Профиль Группа: Завсегдатай Сообщений: 570 Регистрация: 21.12.2006 Где: outer space Репутация: нет Всего: 72 |
Nab, спасибо.
Проверка на принадлежность определенному классу - действительно удобно. То, что мне и было нужно. Восстанавливаю затертое. Да, появилось замыкание. Да, метод say теперь является ссылкой на функцию, вызываемой из метода gav, и теперь никто не может обратиться к методу say... Но работает такой код:
В результате к ЗАКРЫТОМУ методу say можно обратиться через ОТКРЫТЫЙ метод gav. То есть в любом случае закрытость методов от использования потомками/простым кодом не обеспечивается. Это сообщение отредактировал(а) Shaggie - 13.2.2007, 08:17 |
|||
|
||||
Nab |
|
|||
Опытный Профиль Группа: Участник Сообщений: 582 Регистрация: 25.3.2006 Где: Kiev Репутация: 26 Всего: 37 |
Shaggie, не верный вывод....
gav сделан как обертка, только для демонстрации. Не обязательно он нужен, зато метод сохраненный в преременной $say не доступен нигде кроме пакета в котором он определен, то есть если не делать gav, то это реально приватный метод получается... А изменилось то что метод say в вашем варианте вызвать можно, но будет ошибка при выполнении, а вызвать мой заключенный в переменную метод вам не даст компилятор еще на стадии компиляции сказав что метода то такого и нет... И переопределить такой метод в потомке не получиться, а только можно создать свой с таким же именем... Так что разница есть и существенная... -------------------- Чтобы правильно задать вопрос нужно знать больше половины ответа... Perl Community FREESCO in Ukraine |
|||
|
||||
Shaggie |
|
|||
Опытный Профиль Группа: Завсегдатай Сообщений: 570 Регистрация: 21.12.2006 Где: outer space Репутация: нет Всего: 72 |
Nab, не понимаю:
|
|||
|
||||
Nab |
|
||||||||
Опытный Профиль Группа: Участник Сообщений: 582 Регистрация: 25.3.2006 Где: Kiev Репутация: 26 Всего: 37 |
Да уж , это называеться найди 10 отличий...
Это не просто определение функции после которой не нужно ставить точку с запятой, это операция присваивания... И верно будет так:
И вообще Shaggie, боюсь нас не верно поймут, потому как эта теме вынесена в прикрепленные, именно для обсуждения тонкостей и нюансов, а также некоторых неочевидных вещей. А те вопросы которые мы сейчас обсуждаем описаны в большинстве учебников по Перл. Может стоит задавать непонятные вопросы в обычном форуме, а эту тему оставить для всяких "извращенцев от перла" -------------------- Чтобы правильно задать вопрос нужно знать больше половины ответа... Perl Community FREESCO in Ukraine |
||||||||
|
|||||||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
||||
|
||||
Shaggie |
|
|||
Опытный Профиль Группа: Завсегдатай Сообщений: 570 Регистрация: 21.12.2006 Где: outer space Репутация: нет Всего: 72 |
tishaishii, спасибо. Насколько я понял, модуль private применяет в качестве основы обеспечения закрытости доступа модули Class::Fields::Attribs (обеспечивающий имена констант) и Class::Fields::Fuxor (обеспечивающий функции установки и проверки прав доступа), а от себя проверяет наличие подчеркивания перед именем закрытого метода. Этакий use strict для объектного программирования
Nab, код скопирован из твоего примера Насчет отличий - понятно объяснил, спасибо. Действительно глупая ошибка, я мог бы и сам заметить Насчет закрытости методов - увы, остаюсь при своем мнении: этого нет в языке, но несложно реализовать его возможностями (что демонстрируют имеющиеся модули. Рекомендую к изучению, они действительно могут обеспечить поддержку объектов в Перл). Всем спасибо! |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Это сообщение отредактировал(а) tishaishii - 15.2.2007, 07:23 |
|||
|
||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
Нашел книжку, что давно хотел почитать.
Damian Conway: Object Oriented Perl Отсюда: http://www.progteam.com/liter/?teh=Perl Книжка на английском языке. Статус ее (бесплатная, платная, ворованная) - непонятен. По крайней мере, я нигде не нашел описания статуса. Господа модераторы, решите, пожалуйста, что делать с этой ссылкой и насколько "пправильно" (со всех точек зрения) размещение этой ссылки здесь и вообще размещение этой ссылки. --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
stan777 |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 145 Регистрация: 29.1.2007 Репутация: нет Всего: нет |
Чесно говоря недавно сталкнулся с ООП в перле, более сложной и непонятной схемы не видел (я сравниваю с С++ и С#). Хотя возможно это и к лучшему...
Это сообщение отредактировал(а) stan777 - 19.2.2007, 00:07 |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Что, собственно, не понятно было?
Удивило bless? Ну так new, в принципе, по же самое делает. |
|||
|
||||
Zuzu |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 140 Регистрация: 19.10.2006 Где: Екатеринбург Репутация: 3 Всего: 4 |
stan777, было бы интересно сравнить на простых примерах, например реализацию парадигм ОО Программирования в C# и perl. Если тебе интересно, конечно, приведи простенькие примеры.
А еще лучше - подготовь маленькую диаграмку (в UML, например) того механизма, который ты хотел бы видеть в Perl и реализацию этого на C#. Я думаю, не мне одному будет интересно поразбираться. Это сообщение отредактировал(а) Zuzu - 19.2.2007, 10:06 --------------------
Проводить эксперименты на живом сервере опасно, а на мертвом - бесполезно. |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
А что там сравнивать-то? 1:1.
ООП, по-моему, имеет единую идеологию. В конце-концов, я не в полне понимаю выражения "на уровне компилляции" и "на уровне выполнения". Всё равно, в итоге, происходит сравнение и всякие "если", даже, если это не было скомпилировано. Другое дело - скорость работы. |
|||
|
||||
shootnix |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 108 Регистрация: 3.9.2005 Где: Казахстан Репутация: 2 Всего: 2 |
Довольно интересная разработка наших зарубежных товарищей — Moose
это, конечно, если пользоваться не "читсым" Perl, а уже доп. модулями, чем, с позволения сказать, Perl и силен... |
|||
|
||||
nitr |
|
|||
Эксперт Профиль Группа: Участник Клуба Сообщений: 2543 Регистрация: 10.2.2006 Где: Россия :) Репутация: 37 Всего: 84 |
Да что-то интересное, но необходимо ли это? В большинстве случаев - создают "велосипеды", или используют что-то очень "конструктивное, понятное"...
Многим проектам вообще приходится писать с "нуля". А Moose ещё надопоковырять, вдруг есть "затыки" , которые ну во многих поектах существуют... |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Этоть Moose делается за 2 минуты. И никакого особого смысла в реальном проекте делать эти 2 минуты смысла не вижу.
Вообще, тема private, public и protected противоречит идеологии Perl. Perl - проект opensource, а private и protected - это предрассудки. |
|||
|
||||
Shaggie |
|
|||
Опытный Профиль Группа: Завсегдатай Сообщений: 570 Регистрация: 21.12.2006 Где: outer space Репутация: нет Всего: 72 |
Private и protected - не предрассудки, и уж тем более они никоим образом не противоречат идеологии свободного ПО. Это гигантское подспорье при проектировании и реализации крупного проекта. То, что перл не рассчитан на их использование, ещё не значит, что такие полезные концепции программированя можно объявлять первородным злом. У приверженцев PHP до 5 версии, вон, пространств имён не было, так они же не стремились откреститься от них, как от чумы, а признали несовершенность используемого языка. Более того, постепенно латают погрешность. Кстати, 6 перл потому и творят так долго, что пытаются сделать совершенно объектным языком. А где объекты - там и права доступа. Посмотрим, насколько это будет противоречить духу opensource... |
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Если тебе не охота, то и не вызывай private и protected функции, а если сильно нада, то бери что хош. private и protected нужны только, чтобы защитить авторские права. При чём здесь "крупный" или "мелкий" проект? Ты не в полне понимает идеологию opensource. |
|||
|
||||
Shaggie |
|
|||
Опытный Профиль Группа: Завсегдатай Сообщений: 570 Регистрация: 21.12.2006 Где: outer space Репутация: нет Всего: 72 |
Private и protected - средство защиты авторских прав? Это что-то новенькое...
|
|||
|
||||
tishaishii |
|
|||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
А для чего оно ещё надо?
Поступил модуль, ну так пользуй его как тебе вздумается. |
|||
|
||||
everyone |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 218 Регистрация: 24.3.2004 Репутация: 1 Всего: 4 |
И каким же образом можно защитить с помощью Private и protected авторские права? Нарушение авторских прав- это использование чужого кода с нарушением лицензии на него. В Perl это совершенно неуместно, и невозможно, по идеологии, собственно, самого Perl, какими бы закрытыми методы/переменные здесь ни были.
В Perl рекомендуют называть внутренние подпрограммы, начиная с символа подчёркивания "_". Это конечно до невозможности простой вариант, но отчасти довольно приемлимый, этот язык ведь призван облегчать жизнь программистам, в отличие от многих других) С переменными дела не очень, ну... у всех свои недостатки (© из к/ф "В джазе только девушки") Внутренние переменные должны быть использованы для целостности данных, для этого и нужна инкапсуляция... Да и какое нам должно быть дело до приватных методов - разработчику (в некоторых случаях даже нам самим)) виднее, что в API лучше не вызывать напрямую. Shaqqie прав на счёт концепции программированя - переопределение и наследование не всех методов приводит к хорошим последсвиям. Это сообщение отредактировал(а) everyone - 8.9.2007, 11:17 --------------------
Что написал, то написал (Пилат) |
|||
|
||||
kaaz |
|
||||
Новичок Профиль Группа: Участник Сообщений: 4 Регистрация: 9.11.2008 Репутация: нет Всего: нет |
Про какие авторские права вы говорите? По вашему мнению я могу объявить класс с private членами и мой код будет защищён авторским правом? Класс для пользователя выступает как черный ящик и ему совершенно необязательно знать что у него внутри, вот что бы не было никаких недоразумений и вмешательства во внутреннюю работу, всё что нужно для успешной работы я дам к нему доступ, то к чему не нужно я скрою(объявлю как private или protected) |
||||
|
|||||
everyone |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 218 Регистрация: 24.3.2004 Репутация: 1 Всего: 4 |
авторские права должны защищаться законом, и только им. Где-то этот момент и правда работает.
что касается private и protected - они нужны! для проектирования. В языке с ООП должны быть приватные функции, если он претендует на универсальность. А пользоваться им или нет должен решать тот, кто применяет его. Часто ситуация решает это за разработчика - необходимость хорошего, читаемого кода. В perl хорошее ООП не помешало бы, по крайней мере тогда я рассмотрел бы его, как язык, на которм действительно можно написать большой и сложный проект.(надеюсь из-за этого предложения не начнётся полемика опять, спустя полтора года после открытия темы) чем сложнее украсть функцию private, чем public... мне сложно сообразить. Если это кому-то понадобиться, то ничего не поделаешь) --------------------
Что написал, то написал (Пилат) |
|||
|
||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: 1 Всего: 17 |
интересно бь узнать что это за программа была с таким ООП, что показал, уважаемый tishaishii
а где еще такие примеры найти которых нету в книгах ? кстате, в Catalyste такого тоже не ту вроде бы встроенного... Это сообщение отредактировал(а) gcc - 23.1.2009, 23:40 |
|||
|
||||
tishaishii |
|
||||
Создатель Профиль Группа: Завсегдатай Сообщений: 1262 Регистрация: 14.2.2006 Где: Москва Репутация: 4 Всего: 8 |
Ну вот ты и поспешил.... А меня сегодня через PM по поводу этой темы ProFTP разбудил. Так я пример твой посмотрел-посмотрел... И думаю, ну не стоит так. Ну явно же в твоём коде уловка есть (это я по инерции мышления). У класса Father не обозначено собственного метода m1, а есть только наследованный из Class. Ну не указан в описании модуля и всё (чтоб других проверить и дело запустать). А противорячия принципу наследования "Кто первый - тот и прав", я пока не нашёл. Из твоего примера, в пакете main я вызываю Child->new->m1 и получаю вызов изначального метода Class::m1, за неимением другого в классе Father. А вызывается именно Class::m1, т.к. Father в списке родителей был указан первым. ISA(Child=>Father, Mother(m1), Neighbour(m1)); ISA(Father=>Class(m1)); Child::SUPER::SUPER::m1; Не прошёл твой номер. Это сообщение отредактировал(а) tishaishii - 27.1.2009, 18:42 |
||||
|
|||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: 1 Всего: 17 |
1) может кто-то объяснить про tie в OOP? не понял я в этом топике примеры... смысл? как понять архитектуру этого интерфейса которые делается на tie?
я в perl почти все понял но кроме tie.... 2) а как сделать Child::SUPER::SUPER::SUPER::m1 ? |
|||
|
||||
everyone |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 218 Регистрация: 24.3.2004 Репутация: 1 Всего: 4 |
tie связывает структуру Perl с какими-то данными. С помощью tie можно связать структуру с классом и таким образом изменнить функциональность структуры. мне это видится так Добавлено через 2 минуты и 23 секунды Здесь можно найти ответы на многие вопросы, касающиеся tie и OOP. --------------------
Что написал, то написал (Пилат) |
|||
|
||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: 1 Всего: 17 |
этот пример я читал, я "связал", а что дальше делать? где приемущество?
как построить архитектуру программы с tie, я не вижу сымсл? где есть большая прогармма с tie чтобы посмотреть исходники, ради интереса? |
|||
|
||||
everyone |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 218 Регистрация: 24.3.2004 Репутация: 1 Всего: 4 |
в этом вопросе я теоретик, и давно не пишу на Perl. Но судят по той странице
смысл tie в том, что с помощью стандартных методов EXISTS, FIRSTKEY, NEXTKEY... мы создаём расширенный хэш, который ведёт себя так, как мы его запрограммируем. Хэш очень удобная и интуитивно понятная структура. Вы работаете с ним, а обращения к нему латентно делают сколько угодно сложные действия. Вот, по-моему, и всё колдовство. При разработке это, возможно, неудобно и громоздко, но при многократном использовании алгоритма можно сэкономить много времени в написании кода и понимании детального механизма того, что мы делаем(оно отпадает, ведь вы просто работаете с хэшем, а это урок номер один, или два... или, может быть, три). Реализация нам не важна, так что это похоже на разновидность инкапсуляции преимущества всегда относительны --------------------
Что написал, то написал (Пилат) |
|||
|
||||
mvsgt |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
||||
|
||||
DaemonSuw |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 155 Регистрация: 11.3.2008 Репутация: 3 Всего: 3 |
mvsgt, да вот мне интересно кто нибудь его использует? даже топик создал http://forum.vingrad.ru/forum/topic-259920.html ... 3 человека насчиталось =) кто юзает
Это сообщение отредактировал(а) DaemonSuw - 3.6.2009, 16:11 |
|||
|
||||
gcc |
|
||||||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: 1 Всего: 17 |
гугло бот вот выдал не много
http://simon-cozens.org/programmer/articles/rubyisms.pod это если есть Wibble::Simple:: do_it и нужно перейти в Wibble:: do_it ?
http://www.oreillynet.com/onlamp/blog/2006...ing_day_19.html
http://search.cpan.org/~chromatic/SUPER-1.16/lib/SUPER.pm
а по последней ссыле что это за super, что-то не понятно, то же самое? Это сообщение отредактировал(а) gcc - 3.6.2009, 16:45 |
||||||
|
|||||||
mvsgt |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
gcc, непонятно что Вы написали про гугл.
|
|||
|
||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: 1 Всего: 17 |
гугл не много нашел... мало информации про это
|
|||
|
||||
klem4 |
|
||||||
Шустрый Профиль Группа: Участник Сообщений: 100 Регистрация: 27.7.2008 Репутация: 2 Всего: 2 |
В дурдоме можно все:
При желании можно реализовать метод, вызывающий определенные метод у i-го родительского класса вверх по дереву. |
||||||
|
|||||||
mvsgt |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
Гугл не нашёл, потому что в перле (в чистом) в принципе нет классов, а значит и суперклассов нет. Наследования нет -> значит не может быть и родительского класса. use Moose и похожие модули, они эмулируют классы. Добавлено через 1 минуту и 48 секунд klem4, в перле нет классов и нет наследования его можно только эмулировать. @ISA - это не средство породить подкласс, это только путь поиска отсутствующих в модуле функций. |
|||
|
||||
ginnie |
|
|||
Эксперт Профиль Группа: Комодератор Сообщений: 1287 Регистрация: 6.1.2008 Где: Москва Репутация: 38 Всего: 49 |
mvsgt, если в Perl нет классов, почему я их могу использовать? Если нет наследования, почему я могу вызвать родительский метод?
Т.е. в других языках наследование как-то принципиально иначе реализовано? -------------------- Написать код, понятный компьютеру, может каждый, но только хорошие программисты пишут код, понятный людям. (Мартин Фаулер. Рефакторинг) |
|||
|
||||
mvsgt |
|
||||||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
Родительских методов тоже нет! Есть правила поиска методов, но назвать какой-либо класс родительским нельзя, разве что при соблюдении каких-то соглашений.
Конечно иначе. Особенно если учесть, что в Перле наследование вообще никак не реализовано. НИКАК! Вы, например, можете взять да и поменять "наследование" на лету. Попробуйте такой фокус провернуть в Java или С++.
Это сообщение отредактировал(а) mvsgt - 3.6.2009, 19:10 |
||||||
|
|||||||
ginnie |
|
|||
Эксперт Профиль Группа: Комодератор Сообщений: 1287 Регистрация: 6.1.2008 Где: Москва Репутация: 38 Всего: 49 |
mvsgt, почему $self->SUPER::method() не вызов родительского метода?
Зачем смешивать механизмы и их реализацию, тем более указывать как недостаток возможность изменять работу механизмов? Не хочу ввязываться в спор. Если для Вас в Perl нет ООП, классов, наследования - значит так оно и есть. К счастью, многие успешно пользуются этими, отсутствующими в Perl, элементами. Да, пусть они работают не так, как в других языках, но это не повод ими пренебрегать. -------------------- Написать код, понятный компьютеру, может каждый, но только хорошие программисты пишут код, понятный людям. (Мартин Фаулер. Рефакторинг) |
|||
|
||||
KSURi |
|
|||
Опытный Профиль Группа: Участник Сообщений: 887 Регистрация: 8.6.2006 Где: Russia Репутация: 20 Всего: 27 |
С терминологической точки зрения mvsgt пожалуй все-таки прав.
В языках типа С++ или Java такие вещи реализованы на уровне примитивов, а в Perl чистая эмуляция. В голову сразу приходит такая параллель для сравнения: Moose, там вроде как появляется система контроля типов данных. Но нельзя ведь сказать, что перл теперь перестал быть нетипизированным языком. При желании этот контроль можно обойти.
А вот здесь несогласен. MRO - общее понятие для всех ООП языков, оно никак не связано с тем, можно ли называть класс родительским или нет. -------------------- Died at Life.pl line 21 |
|||
|
||||
mvsgt |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
Ну разумеется не повод. Просто ими пользуются не так, как в других языках. Например, SUPER используется в <10% модулей CPAN , о чём-то это говорит. OOP в перле - и больше, и меньше чем в других языках, это скорее не законченная реализация, а конструктор, и это надо понимать. |
|||
|
||||
KSURi |
|
|||
Опытный Профиль Группа: Участник Сообщений: 887 Регистрация: 8.6.2006 Где: Russia Репутация: 20 Всего: 27 |
Но, кстати, с помощью эмуляции ООП в Perl можно добиться практически всего, что могут языки типа С++ и Java. Так что может и не так важно ;)
-------------------- Died at Life.pl line 21 |
|||
|
||||
mvsgt |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
||||
|
||||
everyone |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 218 Регистрация: 24.3.2004 Репутация: 1 Всего: 4 |
какой ещё компиляции? мне бы и в голову не пришло проверять типы на этапе компиляции, и почему бы такими вещами не заниматься именно компиляторам. В жизни этого не делал! И зачем это нужно? (пожалуйста, не отвечайте на этот вопрос) perl в принципе "другой", это лингвистическое изобретение, очень особенное и эффективное, если его правильно понимать, а не бросаться в критике странными фразами Это сообщение отредактировал(а) everyone - 3.6.2009, 23:15 --------------------
Что написал, то написал (Пилат) |
|||
|
||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: 1 Всего: 17 |
в книге написано, что в С++ компилятор дописан на Си, дописано ООП, точно так же как и на perl (какая разница не чем оно написано на Си или на perl?) в smaltalk в его архитетуре есть ООП! и java наверное так же... разве сама суть сильно отличатеся во всех языках ООП? там как правило играют роль дополнительные возможности (или модули) которые управляют всем этим, шаболоны и т.д.? |
|||
|
||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: 1 Всего: 17 |
там еще есть видел на атрибутах http://search.cpan.org/~jjordan/Attribute-...hod/Typeable.pm http://search.cpan.org/search?query=CLASS%...ER&mode=all Это сообщение отредактировал(а) gcc - 4.6.2009, 06:37 |
|||
|
||||
KSURi |
|
|||
Опытный Профиль Группа: Участник Сообщений: 887 Регистрация: 8.6.2006 Где: Russia Репутация: 20 Всего: 27 |
Каких типов? Вы мое первое сообщение читали? Perl - нетипизированный язык, так что вопрос некорректен. Если конечно не считать за типы хэши, скаляры и списки, что вообще-то неправильно. Тем не менее для них можно сделать проверку на этапе компиляции. -------------------- Died at Life.pl line 21 |
|||
|
||||
KSURi |
|
|||
Опытный Профиль Группа: Участник Сообщений: 887 Регистрация: 8.6.2006 Где: Russia Репутация: 20 Всего: 27 |
Не уверен, что понял правильно то, что вы хотели мне сказать... Кажется вы неявно согласились со мной?) Очевидно, на мой взгляд, что способность языка эмулировать различные парадигмы, не меняет изначально задуманную. -------------------- Died at Life.pl line 21 |
|||
|
||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: 1 Всего: 17 |
вот нашел еще
Clone::Fast - Natively copying Perl data structures Moose - A postmodern object system for Perl 5. Mouse - Moose minus the antlers Class::Prototyped - Fast prototype-based OO programming in Perl Class::Closure - Encapsulated, declarative class style Class::Spiffy - Spiffy Framework with No Source Filtering это наверное для больших как-то проектов?
Оригинал: http://laziness-impatience-hubris.blogspot.../blog-post.html |
|||
|
||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: 1 Всего: 17 |
||||
|
||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: 1 Всего: 17 |
TOPH, а какой язык есть не простой? этот тот у которого мало возможностей?
|
|||
|
||||
mvsgt |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
Moose позволяет слелать надстройку над перлом, после чего перл становится вполне типизированным языком, хотя и с некоторыми особенностями. Например, можно написать
но ошибка будет обнаружена только при выполнении, что неприятно. Так что типизированный перл или нет - а типы на нём сделать можно, запрет на неправильное присвоение типов сделать можно, но только на время выполнения, не компиляции. Это сообщение отредактировал(а) mvsgt - 3.7.2009, 16:41 |
|||
|
||||
KSURi |
|
|||
Опытный Профиль Группа: Участник Сообщений: 887 Регистрация: 8.6.2006 Где: Russia Репутация: 20 Всего: 27 |
Я вам даже больше скажу: MooseX::Declare позволяет выполнять проверки на этапе компиляции (с помощью сигнатур методов). Тем не менее Perl не становится от этого типизированным языком. Мы говорим о разных вещах. Я о языке, а вы о надстройке (тем более, что она работает в рантайме). Типизация должна быть реализована на уровне примитивов. Это сообщение отредактировал(а) KSURi - 3.7.2009, 17:32 -------------------- Died at Life.pl line 21 |
|||
|
||||
KSURi |
|
|||
Опытный Профиль Группа: Участник Сообщений: 887 Регистрация: 8.6.2006 Где: Russia Репутация: 20 Всего: 27 |
Прошу прощения, я ошибся по поводу MooseX: (вернее будет сказать MooseX::Types) и проверки типов на этапе компиляции. На самом деле все делается в рантайме. Вобщем-то это только укрепило мое мнение).
UPD: если совсем точно, то стоит упомянуть, что использование вообще не существующих типов все-таки ловится на этапе компиляции Это сообщение отредактировал(а) KSURi - 16.7.2009, 12:33 -------------------- Died at Life.pl line 21 |
|||
|
||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: 1 Всего: 17 |
KSURi, а eval не проверит на этапе компиляции?
eval выполняет код на этапе компиляции если используется mod_perl на какой компиляции оно будет проверять? moose тоже грузиться в mod_perl в память, написано moose быстрее работает в режиме mod_perl потому что выполняется один раз... |
|||
|
||||
Bulat |
|
||||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
Не хочу вмешиваться в ваш спор, ибо для меня самый лучший перл - процедурный перл
Но не могу не вставить свои три копейки, собственно в пользу процедурного.... Я даже не буду уходить в инкапсуляцию и т.п. А пойду проще.. Вот я недавно сменил работу, на пердыдущей писал на процедурном перле и малость на ООП Java. Сейчас ООП Perl... Сталкиваюсь с подобным кодом
И почти весь проект состоит из подобного.. Хотя я конечно погорячился насчет ООП Perl'а. Стараюсь конечно держать себя в руках, ибо я человек новый в фирме, но иной раз так и хотса надавать некоторым по одному месту И это далеко не в первый раз когда я вижу такое(т.е. не только в этой фирме). Лично я в теории тоже могу много порассказать и написать о том, что и как нужно писать и через какие инструменты языка реализовывать, но на практике не всегда все получается так как нужно.. И по объективным и по субъективным причинам. Поэтому мой принцип - делай проще... Умное процедурное программирование гораздо лучше глупого ООП. Вот в том примере, в котором привел я - самое ужасное - что не понятно, что именно за объект должен был вернуться в $step. Понимаете, если в Java мне приходится писать
Дык вот, я четко знаю какой объект мне приходит, и могу с легкостью разобраться... А в перловом примере, мне сначала приходится искать то место, где в поле присвоили искомый объект $step, а это еще не факт, что легко и быстро... А потом еще разбираться и с методом, а он мож вообще "прародительский" Хотя, меня как разработчика, проблемы с которыми я сталкиваюсь в перле при ОО стиле - не должны были бы интересовать... Иногда, бывает иногда, я прибегаю к некоторым возможностям ОО стиля программируя на перле, но очень редко и только там где это необходимо, на мой взгляд... Да и мое мнение, не важно процедурно или ОО, главное чтобы грамотно... но к сожалению, многие кто пытается писать на ОО стиле и выдает свой код за оный - далеки от этого, а вот писать на процедурном не многие стремятся.. не знаю, мож потому что типа "не модно"... Типа гнем пальцы и пишем на ООП.. А я видел очень хороший и грамотный код на процедурном стиле, не без изъянов конечно, но очень достойный.... не многие даж на процедурном смогут так писать. -------------------- менеджер по кодеврайтингу |
||||
|
|||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: 1 Всего: 17 |
предложите MVC Catalyst использовать
есть причины: иногда просят писать качественный код, а иногда не качественный можно, и можно специально так писать чтобы только то что тебе нравиться и на всех остальных забить, и даже комментарии к готовым программам не пишут (замечал такое), хотя может просто никто не просили писать комментарии... и еще можно писать парадигму которая максим. подходит под данную программу... Это сообщение отредактировал(а) gcc - 19.11.2009, 07:52 |
|||
|
||||
sir_nuf_nuf |
|
|||
Опытный Профиль Группа: Участник Сообщений: 920 Регистрация: 6.1.2008 Репутация: 14 Всего: 31 |
Это полиморфизм. И это прекрасно. Это дает вам возможность писать абстрактные алгоритмы. Тут необходимо уточнить два момента: - в языках с динамической типизацией - это опасно, т.к. у вас нет гарантий что полученный "объект реализует нужный интерфейс" - полиморфизм начинает помогать в Больших системах. Если программный комплекс не очень большой, или разбит на отдельные сервисы, то это просто усложняет код. |
|||
|
||||
Bulat |
|
||||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
Ты сильно заблуждаешься. Сейчас ты смешиваешь два понятия как абстракция и полиморфизм в одно...
Можно ли написанный мною выше код назвать полиморфизмом?? Ну может не очень сильно. ) Но для полного разнообразия и в дополнение, можно ли вышеприведенный мною код назвать абстрактным?? Если будет ответ, мол нет "оболочки типа метод внутри класса", можно с легкостью обернуть мой код в класс. Я просто не стал этого делать. Более того, можно ли назвать полиморфизмом ситуацию, когда есть прародитель номер1, от него наследуется прародитель номер2 с переопределенными некоторыми методами, а от него наследуются третий класс, опять же с некоторыми переопределенными методами, а может и со всеми, а может частично и со старыми, и не дай Бог еще похожая ерунда с потомком четвертого уровня, и на каждом этапе переопределение, переопределение ... так что иной раз даже не до конца понятно, из какого прародителя вызывается метод в финальном потомке?? Извини, но я очень не люблю, когда не понимая о чем я говорю, мне начинают пересказывать лекции по программированию... Но и здесь ты допускаешь неточности, ибо объекту совсем необязательно всегда реализовать какой-то интерфейс.. Так что давай не будем Чтобы это не было из приведенного мною примера ты можешь назвать имя класса, экземпляром которого является данный объект?? Ни как реализован, ни для чего он нужен, а просто имя класса?? Моя основная мысль заключается в том, что это и так всегда получается, что в написанному) тобою коде, стороннему разработчику всегда тяжело разбираться, а если ты еще не хочешь делать его читабельным, извини, вряд ли кто-то захочет разбираться в нем кроме тебя - и это плохо... ООП - имеет в своей основе "три кита", но лишь необходимость, но есть еще и достаточность... Или говоря еще проще, либо старайся делать полностью правильно, либо не строй из себя умного чувака и делай проще Это сообщение отредактировал(а) Bulat - 25.11.2009, 13:50 -------------------- менеджер по кодеврайтингу |
||||
|
|||||
Bulat |
|
|||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
Ну не могу я дождаться ответа )))
Опять же.. 1) Не нужно цитировать что-то из книг или интернета не до конца понимая что это значит... Если никто не против я малость пофилософствую ))) Пойдем к началу. Что было раньше? Курица или яйцо? ))) Так вот что было раньше, процедурное(модульное) программирование или объектно-ориентированное программирование?? Я думаю что процедурное(модульное). В рамках данного поста я буду использовать как единый термин - процедурное(модульное), хотя можно отдельно рассматривать процедурное и модульное программирование. Дык вот, возможна ли абстракция при процедурном(модульном) программировании?? Я считаю, что ДА! А возможен ли полиморфизм при процедурном(модульном) программировании?? Я считаю, что ну никак, при всем желании. :( Дык что было в начале?? И вот теперь, если вдуматься: а) Полиморфизм позволяет писать абстрактный код б) Или же абстракция позволяет нам использовать такой прием как полиморфизм?? И чтобы уже совсем отделиться от этой зазубренной фразы, я попробую привести еще пару примеров определений термина полиморфизм: Полиморфизм -- это свойство программного объекта менять свою форму, в зависимости от контекста его использования. Полиморфизм -- это свойство языка программирования обрабатывать объекты по-разному, в зависимости от их типа данных или класса Но это я на гуглил.. В этом нет ничего такого, но чтобы понять что-то всегда нужно попытаться взглянуть с разных точек зрения, и разными(чужими) глазами. Да и просто эти определения мне очень понравились, человек писавший их знает хорошо и главное хорошо понимает, что такое полиморфизм. А теперь пойдем дальше. Есть такое понятие, как логика предметной области. Интересная штука.. Т.е. то, что может определить для нас некий свод, набор правил, внутри конкретного приложения, предназначенного для указанной предметной области, чаще всего бизнеса в каком-то конкретном направлении, но может быть и какая-то научная работа, исследование и не только... Дык вот, если ты хорошо знаешь логику предметной области, ну мож лет 10 занимался этим, конечно у тебя должен быть достаточный опыт для того, чтобы изначально спроектировать, определить некие абстрактные методы... Не думаю... Не нужно обижаться, я лично себя-то тоже не считаю каким-то там пупер-профессионалом Себя я мог бы характеризовать как человека, который уже начал перерастать книго-шаблонное программирование, но еще не дорос до ..... Дорасту скажу что это ))) Объектно-ориентированное программирование - это некий шаблон, для больших систем, реализующих широкий спектр функциональных возможностей логики какой-то конкретной предметной области. Воощем сам не до конца понял чего сказал )) Надеюсь вы лучше меня поймете )))) Но любая предметная область имеет свою специфику. И вот для этой специфики было бы не плохо применять верные концепции. Событийно-ориентированное программирование, компонентно-ориентированное программирование, сервис-ориентированная архитектура и т.п. Их не так уж и много. Дык вот к чему я это все... Как-то я услышал такую фразу: "Порой программистские решения как карточный домик, если ты всерху еще можешь положить карту или две.. Но убрать - очень рискованно и страшно, даже если это комментарий". Дык вот я уже встречался пару раз, когда отсутствие необходимого опыта, но наличие излишнего желания писать программы по последнему писку моды программирования, приводило к избытку объектов, классов и вообще большой путанице. Т.е как раз тот карточный домик, где страшно, рискованно, а может и невозможно убрать лишнюю карту. Толковый программист, это не только тот кто умеет писать и применять, но и тот кто понимает всю логику и сам задает какие-то правила для поведения объектов, а не только использует какую-то аналогию. И вот это вот все, и не только это и есть достаточность и не только ООП Хе-хе.. что-то меня сегодня на красноречие пробило -------------------- менеджер по кодеврайтингу |
|||
|
||||
sir_nuf_nuf |
|
|||
Опытный Профиль Группа: Участник Сообщений: 920 Регистрация: 6.1.2008 Репутация: 14 Всего: 31 |
Ээхх.. я еле дочитал. На самом деле я имел в виду имено то, что написал в предыдущем посте.
Полиморфизм (в узком смысле, в контексте ООП) - это возможность языка программирования выбирать нужную реализацию метода в зависимости от класса объекта у которого этот метод был вызван. Это не лекция по информатике, это мое представление о полиморфизме. Я считаю, что это хорошо и объяснил почему. Не используя так или иначе механизм полиморфизма писать алгоритмы которые не привязаны к конкретным типам данных труднее (хотя и возможно). |
|||
|
||||
Bulat |
|
|||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
sir_nuf_nuf, ок...
Один вопрос, является ли полиморфизмом такой код: Ты объявил класс 'А', определил в нем какой-то метод 'b'. Далее унаследовался от него - класс 'А1' и переопределил метод - 'b1', далее унаследовался от 'А1' - класс 'А2' и переопределил метод - 'b2', и т.д. Дык может ли быть метод 'b2' - полиморфизмом в данном контексте?? Нет, для того, чтобы он стал полиморфизмом, должен быть объявлен абстрактный класс 'AA' с методом 'b', и вот объявляя каждый раз новый класс, возможно даже родитель-потомок, ты должен переопределять метод из класса 'AA', а не из родительского. И вот насколько я знаю, как такого полиморфизма в перле вообще не существует.. При желании его можно достигнуть, немного кудряво... Я ни коим образом не оспариваю, что хорошо и правильно использовать полиморфизм. Но вот возвращаясь к моему конкретному коду, это не полиморфизм. Это лишь некая абстракция, которая так и не доросла до полиморфизма, оставшись на уровне абстракции... Но моя изначальная мысль как была так и остается, что редко встретишь код написанный на перле, в большинстве своем удовлетворяющий канонам ООП... Потому как в перле приходится очень многие вещи реализовывать "в ручную", в то время как ОО - языки, поддерживают это уже "внутри"... Но далеко не все в ручную реализовывают все каноны ООП... И вот тут стороннему разработчику очень тяжело разобраться в чужой каше... В конце концов, программирование нужно чтобы облегчать жизнь другим людям, в том числе и тем, кто придет дописывать твой код после тебя. Более того, если кто-то действительно пишет на перле в ОО стиле, я снимаю шляпу перед такими людьми -------------------- менеджер по кодеврайтингу |
|||
|
||||
sir_nuf_nuf |
|
|||
Опытный Профиль Группа: Участник Сообщений: 920 Регистрация: 6.1.2008 Репутация: 14 Всего: 31 |
А в классе A методы b1 и b2 имелись ? Или, учитывая специфику perl, хотя бы предполагалось их наличие (в java в таком случае используют абстрактные методы, а в перл документацию или заглушку) ? Если да - то приведенный пример - это пример перекрытия методов родительского класса (overriding). Вызов такого метода у объекта - это полиморфный вызов.
Очень спорное утверждение. На мой взгляд полиморфизм в perl примерно такой же как и в Java 1.4 (когда еще не было templates) Cформулируйте плиз, как вы понимаете полиморфизм. Строки в 3 желательно. |
|||
|
||||
gcc |
|
|||
Агент алкомафии Профиль Группа: Участник Сообщений: 2691 Регистрация: 25.4.2008 Где: %&й Репутация: 1 Всего: 17 |
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 |
|||
|
||||
Bulat |
|
|||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
Реализация общего абстрактного метода в зависимости от контекста. Т.е. у нас есть некое абстрактное определение, которое стоит во (!) главе иерархии, не по середине являясь уже чьим-то потомком.. Таким образом, если A1 для A - еще может быть полиморфизмом, но уже A2 для A1 - никак нет, так как A1 - не стоит во главе иерархии. Ибо сама философия полиморфизма и абстракции предполагает наличие в отношении двух классов одного абстрактного(который не является ни чьим потомком), а второго как раз потомка текущего. gcc, как-нить гляну -------------------- менеджер по кодеврайтингу |
|||
|
||||
sir_nuf_nuf |
|
|||
Опытный Профиль Группа: Участник Сообщений: 920 Регистрация: 6.1.2008 Репутация: 14 Всего: 31 |
Bulat, у нас просто расхождение в терминологии.
|
|||
|
||||
Bulat |
|
|||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
не исключено. Программирование это абстрактная наука, в которой всегда может быть не одно верно решение(не одно верное определение и не один верный термин). -------------------- менеджер по кодеврайтингу |
|||
|
||||
mvsgt |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
Полиморфизм - это использование наследника вместо родителя. для цепочки
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(), масса классов принимает любой объект с таким методом, своего рода полиморфизм. Наверно, на чистом перле просто не надо писать длинные цнпочки наследования. |
|||
|
||||
Bulat |
|
|||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
как раз таки отсутствие указания явного параметра - ни коим образом не противоречить самой философии полиморфизма. Наоборот, в этом и суть полиморфизма - когда реализация зависит именно от вызываемого контекста, т.е. в func1 может передаться какой-то объект какого-то класса, не потомка class1 - и это будет самым явным полиморфизмом, то бишь абстракцией. Добавлено через 11 минут и 54 секунды Допустим class1 - животные class2 - млекопитающие class3 - собака казалось бы, все не плохо так как закон наследования class1 -> class2 -> class3 - хорошо срабатывает и если в class1 - func1 - "издает звук" - то собака(class3) - лает(func1 - переопределенный), но вдруг у нас появился class4 - рыбы, который претендует на то, чтобы стать наследником class1 и быть на одном ряду в иерархии с class2, но что тогда делать с func1 - определенным еще в class1, т.е. животное. Получается, что рыбы(class4) тоже "издает звук" - что абсолютно не правильно. Или придется для рыб делать эту функцию deprecated или возвращающим undef ?? )) Но ведь это все равно не правильно, в рыбы(class4) вообще не должен вызываться метод "издает звук"(func1) -------------------- менеджер по кодеврайтингу |
|||
|
||||
Bulat |
|
|||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
Я даже сделаю еще интереснее, кроме "издает звук"(func1) - у нас есть "моргает"(func2) - т.е. движение век, и казалось бы все не плохо, что животное(class1) - моргает(func2), млекопитющее(class2) - моргает(func2) рыбы(class4) - моргает(func2), собака(class3) - моргает(func2)...
Но вдруг у нас появился крот(class5), который наследник млекопитающее(class2), и по закону наследования он без проблем должен был унаследовать моргает(func2) - но ведь это не правильно. крот вообще не должен "моргать" даже если возвращает undef так как у него нет глаз. -------------------- менеджер по кодеврайтингу |
|||
|
||||
korob2001 |
|
|||
Эксперт Профиль Группа: Комодератор Сообщений: 2871 Регистрация: 29.12.2002 Репутация: 31 Всего: 61 |
Дело в том, что это слишком абстрактный пример, из-за этого возникает путаница. Напомню, так называемый девиз, который знаком если не всем, то многим ООП программистам (особенно Java ) - "Разделяй и влавствуй". Моргание - это свойство глаза, обьекты которого может и не иметь млекопитающее, соответсвенно оно и не сможет моргать. Если быть более точным, то моргание - это свойство века, а не глаза, но даже если мы сделаем его свойством глаза, нас это устроит, так как мы уже дошли до нужного уровня абстракции. (Во я загнул ). Тоже самое относится и к рыбам. Так же хочу обрать внимание, что я назвал не случайно моргание или способоность воспроизвести звук именно свойством, а не методом. Здесь важно парвильно задать вопрос: Имеет ли млекопитающее глаза? (true || false)? Если да, то может ли глаз млекопитающего моргать (true || false)? Имеет ли рыба голос (true || false)? Если да, то может ли рыба издать звук (true || false)? Наверняка найдётся млекопитающее, которое имеет глаза, но оно не моргает, так же и некоторые рыбы могут издавать звук. После, на основе этих свойств, можно построить метод, который к примеру будет визуализировать глаза если они есть, а так же их моргание, если он они способны это делать. Можно построить и класс Voice с методом play(), который будет воспроизводить издаваемый звук, возможно немой, в зависимости от способности его издавать. Это сообщение отредактировал(а) korob2001 - 11.1.2010, 15:57 -------------------- "Время проходит", - привыкли говорить вы по неверному пониманию. "Время стоит - проходите вы". |
|||
|
||||
mvsgt |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
Это не будет ни полиморфизмом, ни абстракцией. Не надо путать общественность. Абстракция - это интерфейс, полиморфизм - это реализация интерфейса. К контексту ни то, ни другое не имеет отношения. Я не хочу Вас огорчить, но придётся рыбы говорят. http://otvet.mail.ru/question/14061301/ |
|||
|
||||
Bulat |
|
|||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
И да, и нет )) Все зависит от контекста задачи(логики предметной области, бизнес-логики и пр.) Ведь задача программиста не только владеть синтаксисом и уметь применять парадигмы, паттерны и т.п., но еще и уметь делать это именно там где это нужно, а не "пихать" более простое везде и всюду или все и всегда решать за счет наследования и переопределения Хотя не скрою, что иногда я и сам так хачу, потому как "дешевле" обходится, чем полностью делать правильно. Я тебе приведу другой более интересный пример из русского языка. Любое предложение делится на слова, т.е. любое предложение состоит из слов - "Меня зовут Вася"... 3 слова. А теперь разберем такие интересные моменты, как с одной стороны, часть слов можно поделить на "глагол" и "существительное", ну еще и кроме них есть )) Но в тоже время, в зависимости от контекста(предложения) часть слов делится на "подлежащее" и "сказуемое" В предложении "Красивая девочка рисует", слово "девочка" - существительное, подлежащее Но в предложениее "Женя - девочка", слово "девочка"(о! чудо! ) вдруг "наследует" все свойства уже "сказуемого", в то же время оставаясь "существительным".. Более того, все же "сказуемое" это как правило "глагол" в общих случаях Нет, нет и еще раз нет Абстракция - "пустой метод", без реализации, без ничего.... А вот когда ты передаешь в него какие-то параметры, причем абсолютно не важно какие и кто родитель/потомок этих параметров - это и есть полиморфизм..... И абстракция - это не интерфейс.. Абстракция, как понятие, появилось в программировании за долго до того, как появилось понятие "интерфейс". Вообще все парадигмы - стоят выше реализации какого-то конкретного языка программирования. Реализация ООП в каком-то конкретном языке программирования - не более чем интерпретация, а не есть само ООП.
"Пусть говорят" (с), вот если ты еще найдешь в моем предыдущем посте слово "говорит" У меня есть "издает звук", но это не одно и то же с "говорить" ведь бывает "мычать" - тоже подмножество множества "издавать звук", рычать - "издавать звук"... Нужно уметь правильно абстрагироваться, а рыбы, как ни крути издавать звуков не умеют. -------------------- менеджер по кодеврайтингу |
|||
|
||||
mvsgt |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
Умеют издавать звуки рыбы. Вот какой же Вы упёртый Так и с терминологией - я Вам говорю, что полиморфизм - это не свойство контекста использования, а свойство объектов и классов, а вы никак этого не замечаете. Ну как передавать параметры можно в пустой метод? Никак нельзя. С ним вообще кроме переопределения или определения ничего нельзя сделать. Что такое абстракция применительно к ООП ? Это абстрактные методы, то есть то, что можно сделать с объектом. А это и есть интерфейс - вы ему говорите что надо сделать, а объект уже знает как сделать. Вот это "как" и есть полиморфизм, изменчивость. В Перле контекст - понятие вполне конкретное, это способ использования. "2" может использоваться как строка, а может как число - это контекст, к полиморфизму не имеет отношения. |
|||
|
||||
Bulat |
|
||||||||||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
во-первых уходим во флуд, во вторых все высокочастотные якобы "звуки" издающие рыбы - называются звуками, лишь потому что ученые это так интерпретируют. Если они начнут более четко и в своих же терминах объяснять что именно из себя представляют эти "звуки" - то это будет совсем другое... Абстрагируясь, все это можно назвать волнами, колебаниями, частотами, однако часть этих волн - световые, часть звуковые.. а есть еще ультразвук - но это уже совсем не те "звуки"
Ваша основная ошибка в том, что вы интерпретируете ООП через реализацию конкретного языка программирования... Поэтому такое упертое убеждение что полиморфизм относится к классам или объектам.... да и кроме того, не нужно изменять мои слова и вообще быть очень внимательным... То я вдруг использую слово "говорить", хотя в моем посте такого не было, то вы вдруг приписываете мне словосочетание "свойство контекста". В нашей дискуссии вы любитель использовать слово "свойство", а я его по-моему ни разу даже еще не написал. Полиморфизм явным образом необходим при реализации ООП, но можно с легкостью создавать аналоги полиморфизма и не в ООП.. Нужно понимать, что как некая концепция "полиморфизм" сформировался именно при ООП, но это совсем не значит, что он не возможен уже не в рамках ООП или не в рамках объектов или классов... Perl как раз один из тех языков, который позволяет делать разную реализацию, сохраняя основную философию таких понятий.. Лично мне например совсем необязательно использовать функцию bless и определять конструктор new - для того чтобы создать объект и написать класс в перле. И это будет вполне полноценный класс ООП, правда выглядеть он будет малость по иному. И раз уж есть немного флуда, сам термин полиморфизм - он тоже не случаен. Из чего он состоит?? Из двух слов "морфа" и "поли"
подитожив - как самостоятельная концепция, полиморфизм появился именно при ООП, но это совсем не означает что он не возможен без классов и объектов. и при использовании полиморфизма не в рамках ООП, скорее придется называть это все же неким аналогом полиморфизма
Представь себе, что у тебя есть 2 Mb свободной памяти("пустое место") на жестком диске.. Причем самому жесткому диску абсолютно все равно что будет хранится на этих 2 Mb, текст или изображение, музыка или видео, по большому счету ему даже все равно в каком файловом формате все это будет. Вот в этом-то и заключается смысл полиморфизма, когда ты переопределяешь пустой метод в зависимости от того что требуется в контексте данной задачи, в зависимости от того какие параметры нужно обрабатывать. Логика не должна зависеть от того что у тебя приходит в параметрах... Возьмем более простой пример... Допустим у меня есть два демона, которые прослушивают какие-то конкретные порты.. Для обоих демонов мне нужен метод, который обрабатывал бы(ну или хотя бы получал на первом этапе) то, что приходит по сокету. Причем, если для одного демона у меня приходят просто текстовые сообщения, то для другого какие-то конкретные пакеты конкретного протокола.. Но ведь логика-то все равно для них общая.. И если я напишу этот метод сначала для одного, реализовав в нем прием обработку текстовых сообщений, а потом унаследуюсь и переопределю для пакетов какого-то протокола - то это вообще не будет ни полиморфизмом, ни абстракцией. Вот тут нам и помогает абстракция, с пустым методом, и реализация (через переопределение метода) для каждого конкретного случая. А потом этот же самый абстрактный метод можно применить и для третьего и для четвертого демона и т.д. при этом у меня нет необходимости создавать многоуровневую("сложную") иерархию, т.е. таким образом мы и приходим к моему любимому принципу KISS - keep it simple, stupid. Прям какое-то зацикливание на объектах и классах... Абстракция даже применительно к ООП не обязательно связана только с объектом... И даже если уходить в рамки твоих терминов - интерфейсу не нужно говорить что делать, он уже должен сам знать что ему делать и для чего он предназначен. А объект - то как это сделать, с чем это делать. Объекту в принципе может быть все равно что с ним будет делаться. Перл вообще не ОО язык, и в нем нет таких понятий как интерфейс вообще. Еще раз, лично я могу типично перловым синтаксисом создавать вполне полноценные объекты и классы, в них будут некоторые отличия вплоть до уровня представления от привычных C-ных классов, но это совсем не означает что это уже не объекты.. Мне счас вспоминается фраза из одного учебника
Не нужно привязывать ОО, к реализации конкретного языка. Это лишь интерпретация самой теории ОО. Попробуй почитать допустим про Object Pascal
Это сообщение отредактировал(а) Bulat - 12.1.2010, 11:28 -------------------- менеджер по кодеврайтингу |
||||||||||
|
|||||||||||
sir_nuf_nuf |
|
|||
Опытный Профиль Группа: Участник Сообщений: 920 Регистрация: 6.1.2008 Репутация: 14 Всего: 31 |
товарищи, предлагаю все читать книжки и завершать флейм. |
|||
|
||||
korob2001 |
|
||||||||||||||
Эксперт Профиль Группа: Комодератор Сообщений: 2871 Регистрация: 29.12.2002 Репутация: 31 Всего: 61 |
А никто и не сказал, что рыбы должны издавать звук так же как и человек. Что касается полиморфизма, полностью согласен с 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 -------------------- "Время проходит", - привыкли говорить вы по неверному пониманию. "Время стоит - проходите вы". |
||||||||||||||
|
|||||||||||||||
Bulat |
|
|||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
Нисколько обрати внимание на структуру которую ты создал 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 -------------------- менеджер по кодеврайтингу |
|||
|
||||
Bulat |
|
|||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
korob2001, Или даже еще интереснее, хочешь я тебя подловлю в рамках твоего же приведенного примера с shape, rectangle и т.д.
при этом всего навсего за 2 шага )) -------------------- менеджер по кодеврайтингу |
|||
|
||||
mvsgt |
|
||||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
Почти правильно. Но в корне неверно. Полиморфизм проявляется не в момент переопределения методов, а в момент использования объектов. И не обязательно переопределения пустых методов. Это станет полиморфизмом, как только будет использован объект вместо своего родителя. Но использующая процедура будет с объектом работать как с его родителем, не принимая во внимание новых свойств объекта.
Суть здесь - в слове "форма".
Ну приехали. Объекты есть , классы есть, наследование, полиморфизм... В принципе всё есть. Но это вопрос терминологии. А вот насчёт интерфейса Вы не правы. Интерфейс - это команды, которые может исполнять объект. Некоторые языки считают, что интерфейс должен быть выполнен абстрактными процедурами, но по сути это не обязательно. К примеру, модуль CGI имеет интерфейс param(). |
||||
|
|||||
korob2001 |
|
||||||||
Эксперт Профиль Группа: Комодератор Сообщений: 2871 Регистрация: 29.12.2002 Репутация: 31 Всего: 61 |
Оно то содержится, но квадрат - всё же это не совсем четырёхугольник. Я понимаю, что можно было создать обьект который бы смог нарисовать нам квадрат, с помощью класса Rectangle. Square, в данном случае гарантирует, в отличае от Rectangle, что размеры старон у квадрата будут одинаковы, так как он переопределяет методы доступа класса Rectangle. По хорошему, нужно было унаследовать от класса Rectangle и класс Oval, который можно описать четырёхугольником. В последствии создать класс Circle, который бы наследовал от класса Oval, так как окружность является овалом, опять же с небольшими отличиями.
Я этого понять не могу. Вот иерархия, которую я создал выше.
Где здесь класс Square пересекается с Shape? Здесь Shape является прародителем класса Square, так как квадрат тоже является фигурой, который так же наследуте все методы которые предоставляет, класс Shape, квадрат так же ялвляется и четырёхугольником, потому ему так же доступны методы предоставленные его непосредтсвенным родителем, т.е. классом Rectangle.
Ту структуру которую я создал, я нарисовал выше. Это сделано скорее для инкапсуляции, так как класс Square переопределяет методы доступа класса Rectangle так, что они не позволяют создать квадрат с разной динной сторон. К полиморфизму это вообще не относится. К сожалению ни Java, ни C# не поддерживают множественного наследования, а может к счастью. -------------------- "Время проходит", - привыкли говорить вы по неверному пониманию. "Время стоит - проходите вы". |
||||||||
|
|||||||||
korob2001 |
|
|||
Эксперт Профиль Группа: Комодератор Сообщений: 2871 Регистрация: 29.12.2002 Репутация: 31 Всего: 61 |
Давай -------------------- "Время проходит", - привыкли говорить вы по неверному пониманию. "Время стоит - проходите вы". |
|||
|
||||
Bulat |
|
|||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
Вот у меня есть класс - "коллекция", как пример, класс в котором каждое поле есть хралинище для поля из конкретной одной таблицы... И на каждую строку из этой таблицы у меня свой объект. Т.е. мы получаем, что использование само по себе объектов - нам может и не дать полиморфизм. а если я пишу портал, то термин "интерфейс" я могу использовать применяя совсем не к командам объекта. korob2001, ок, давай вынесем в отдельную ветку и через твой пример с Shape и далее, я за два шага(минимум, а при желании за большее еще более ярко) тебе придется существенно изменить твою реализацию полиморфизма.. И боюсь, что одного абстрактного класса во главе иерархии - Shape тебе уже не хватит. Я лишь попрошу дополнить твою реализацию парочкой новых фич.
Более или менее привычного нет, но в Java есть интерфейсы взамен множественного наследования -------------------- менеджер по кодеврайтингу |
|||
|
||||
sir_nuf_nuf |
|
|||
Опытный Профиль Группа: Участник Сообщений: 920 Регистрация: 6.1.2008 Репутация: 14 Всего: 31 |
файл Invoke.pm:
Полиморфизм - это свойство языка (в данном случае perl) автоматически определять класс (пакет) объекта (obj) и вызывать метод (do_method) из этого класса (пакета). Это позволяет работать с объектами не зная их класса, но зная что у них есть определенные методы (т.е. что объект реализует интерфейс) Наследование - это свойство языка использовать метод определенный в родительском классе, если он не найден в классе объекта. Иногда это же применимо и данным Менее важно но все же... Инкапсуляция - это свойство языка объединять данные в объекты, и ограничивать доступ к ним. В perl по большому счету это только на уровне документации Булат, ситуация прояснилась ? |
|||
|
||||
korob2001 |
|
|||
Эксперт Профиль Группа: Комодератор Сообщений: 2871 Регистрация: 29.12.2002 Репутация: 31 Всего: 61 |
А смысл выносить её в отдельную ветку? Речь ведь идёт об ООП. -------------------- "Время проходит", - привыкли говорить вы по неверному пониманию. "Время стоит - проходите вы". |
|||
|
||||
Bulat |
|
|||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
Ок. Тогда мне хотелось бы, чтобы все прямоугольники заливались красным цветом, а все окружности зеленым. Это первый шаг. Это сообщение отредактировал(а) Bulat - 12.1.2010, 16:25 -------------------- менеджер по кодеврайтингу |
|||
|
||||
sir_nuf_nuf |
|
||||
Опытный Профиль Группа: Участник Сообщений: 920 Регистрация: 6.1.2008 Репутация: 14 Всего: 31 |
Вы считает что цвет - это свойство фигуры ? Обычно в таких случаях в метод draw передают объект типа Canvas - то на чем происходит рисование. А вот уже у Canvas устанавливается текущий цвет. Поэтому в том месте где вы хотите окружность определенного цвет - вы делаете
Как то так. Только не надо говорить что instanceof - это не правильно - в этом смысл вашего предложения - на каком то этапе вам нужно знать что конкретный объект - это круг Но это никакого отношения к полиморфизму не имеет Это сообщение отредактировал(а) sir_nuf_nuf - 12.1.2010, 16:51 |
||||
|
|||||
mvsgt |
|
||||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
От оно как... Это Вы серьёзно написали, или в порядке разгрузки против трудового дня ? Посмотрите определение термина, например,в Википедии - http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%...%BD%D0%B8%D1%8F.
В случае портала классом будет код портала, объектом - исполняемый в момент запроса код, а интерфейсом - ссылки, кнопки, формы и экраны. Код можно переписать (Наследование), но пользователь этого не заметит если не менять интерфейс (полиморфизм).
Ну так надо унаследовать от Прямоугольник ЗелёныйПрямоугольник Это сообщение отредактировал(а) mvsgt - 12.1.2010, 16:54 |
||||
|
|||||
Bulat |
|
|||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
Я ничего не считаю. Представь себе, что я пользователь который будет использовать программу для рисования, которая пишется в данный момент.. И вот теперь, мне нужно чтобы все прямоугольники закрашивались в красный цвет, а все окружности в зеленый... Более того, меня не интересует отдельный кусок кода, меня интересует где и как он будет находится в рамках того примера который привел korob2001. Добавлено через 10 минут и 51 секунду
У меня есть класс, в котором есть два поля - id, name и конструктор.. Этот класс не является ни чьим родителем и сам ни от кого ничего не наследует.. Более того, в ходе работы алгоритма вполне может быть такая ситуация, что каждый раз у меня будет создаваться не более одного объекта, экземпляра данного класса... - Где здесь полиморфизм?? Остальное я даже комментировать не буду. -------------------- менеджер по кодеврайтингу |
|||
|
||||
mvsgt |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
||||
|
||||
Bulat |
|
|||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
А ты попробуй -------------------- менеджер по кодеврайтингу |
|||
|
||||
mvsgt |
|
|||
Бывалый Профиль Группа: Участник Сообщений: 209 Регистрация: 27.3.2009 Репутация: 1 Всего: 1 |
||||
|
||||
korob2001 |
|
|||
Эксперт Профиль Группа: Комодератор Сообщений: 2871 Регистрация: 29.12.2002 Репутация: 31 Всего: 61 |
Ну вообще-то, если брать во внимание именно тот код, который я привёл выше, то тут просто стоит добавить свойство color в класс Shape, так как впрниципе любая фигура может иметь цвет, либо не иметь его вовсе, т.е. быть transparent. Ну и инкапсулировать это свойство, добавив в этот же класс методы доступа getColor() и setColor(Color color). Ну и наконец использовать установленный цвет, при работе метода draw(). А где здесь полиморфизм? Где наследование или реализация хотя бы одного интерфейса? Не знаю, как там обстаят дела с Object Pascal, но в Java у составных типов всегда есть родитель Object, собственно унаследованные от него методы и можно вызвать полиморфно, больше никаким полиморфизмом здесь и не пахнет. -------------------- "Время проходит", - привыкли говорить вы по неверному пониманию. "Время стоит - проходите вы". |
|||
|
||||
Bulat |
|
||||||||
татарский Нео Профиль Группа: Завсегдатай Сообщений: 1701 Регистрация: 22.3.2006 Где: Альметьевск Репутация: 5 Всего: 57 |
ну так не интересно, либо уж мы делаем, либо не делаем. От, ты почти пришел к тому, к чему вел я, однако и здесь слишком "легкомысленно" подошел и допустил одну неточность.. Для полиморфизма, нам необходимо, чтобы абстрактные методы не только наследовались, но и переопределялись и использовались.... и если мне не изменяет память, то ниже я перечислю все методы нашего основного метода Object
Вот не могу говорить за все случаи из жизни, но лично я когда работал на Java и писал как раз "коллекции" - мне не приходилось переопределять данные методы. А вообще мне очень не понравилась твоя фраза: смею напомнить, что Java многое переняла у C/С++ и лишь представила это по-своему, как впрочем и C# И вот я представлю на твой суд очень интересную статью http://ru.wikipedia.org/wiki/%D0%92%D0%B8%...%86%D0%B8%D1%8F И в 120-й раз повторюсь, при понимании и осознании парадигм ООП, все же не очень хорошо опираться лишь на реализацию конкретного языка... Обращу внимание, на данные строки из этой статьи
а также
и кроме того
Увы, мне пришлось потратить пару часов и эта не единственная интересная статья, которую я нашел. Было бы еще интересно взглянуть на VBasic, но я с ним не знаком и даже в университете не приходилось с ним сталкиваться(в отличие от C++ и Object Pascal) Засим я расписываюсь в завершении дискуссии со своей стороны, ибо лично мне совсем не интересно обсуждать что-то с людьми, которые не то что "узко" понимают какие-то парадигмы, а просто не желают их хорошо понимать и расширять границы своих знаний, оттого и не видят тех недостатков на которые я уже давно пытаюсь открыть глаза. korob2001, а учитывая что язык Java является более молодым по сравнению с тем же С/С++, Turbo Pascal/Object Pascal я вообще сомневаюсь, что реализация парадигм в данном языке наилучшая нежели в остальных... Более простая, понятная и удобная для разработчика - да, а вот лучшая ли?? Это сообщение отредактировал(а) Bulat - 13.1.2010, 16:06 -------------------- менеджер по кодеврайтингу |
||||||||
|
|||||||||
korob2001 |
|
||||||
Эксперт Профиль Группа: Комодератор Сообщений: 2871 Регистрация: 29.12.2002 Репутация: 31 Всего: 61 |
А что мы делаем? Ты попросил, добавить возможность изменения цвета фигуры, я всё описал. Или нужно каждый раз приводить полный код? Это само сабой разумеется, иначе как же мы создадим обьект? Класс унаследовавший абстрактный метод и не определивший его, может быть только абстрактным. Создавать обьекты абстрактного класса, боюсь не получится, кстати это же написано и в приведённой тобой статье.
Насчёт того, что Java перенял многое от C++, а так же и других языков, ничего против сказать не могу. Хотя, к чему было это высказывание, я так и не понял. Я действительно не знаю, как обстаят дела с ООП в Object Pascal, потому и написл отталкиваясь от Java.
Зато есть понятие абстрактного метода и в куске статьи выше написано: Такие методы без реализации называются «чисто виртуальными» (калька с англ. pure virtual) или абстрактными.
Никто с этим и не спорил, даже пример приводился с абстрактными методом. Я тоже считаю, что лучше закончить это обсуждение, особенно когда человек вообще не желает прислушаться, даже если ему говорит об этом не один человек. Плохо так же то, что у тебя просыпается желание кого-то, на чём-то "подловить". Что бы заниматься этим, нужно самому знать тему от и до. Кстати, Object - это класс, а не метод. Это сообщение отредактировал(а) korob2001 - 13.1.2010, 19:40 -------------------- "Время проходит", - привыкли говорить вы по неверному пониманию. "Время стоит - проходите вы". |
||||||
|
|||||||
Logo |
|
|||
Опытный Профиль Группа: Участник Сообщений: 694 Регистрация: 22.7.2008 Репутация: 3 Всего: 10 |
Пол года на перле не програмировал... забыл как называется, подскажите.
Модуль для очистки пакета класса от экспортируемых функций из других модулей, что бы они не были методами. Поиск не помогает. |
|||
|
||||
Pfailed |
|
|||
Опытный Профиль Группа: Участник Сообщений: 933 Регистрация: 19.7.2009 Репутация: 22 Всего: 39 |
namespace::clean?
|
|||
|
||||
Logo |
|
|||
Опытный Профиль Группа: Участник Сообщений: 694 Регистрация: 22.7.2008 Репутация: 3 Всего: 10 |
Да, походу, он, правда странно что его нет в стандартной поставке.
|
|||
|
||||
Правила форума "Perl" | |
|
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, korob2001, sharq. |
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Perl: Общие вопросы | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |