А ООП вообще парадоксальная тема. Обычно, при изучении чего-то нового и сложного, изучающий проходит следующие этапы:
1. Что за чертовщина?
2. Что-то не врублюсь.
3. Впринципе, все понятно.
4. Эксперт.
Но в отношение ООП порядок строго обратный: 4, 3, 2, 1!
Но самое интересное — на этом все не заканчивается и ряд продолжается: 2, 3, 4, 3, 2, 1, 2, 3, 4, 3, 2, 1...
Поэтому, если встретится оппонент, находящийся, скажем, на этапе 2, целесообразно выяснить, на каком витке спирали он находится...
Здравствуйте, artelk, Вы писали:
A>А ООП вообще парадоксальная тема. Обычно, при изучении чего-то нового и сложного, изучающий проходит следующие этапы:
A>1. Что за чертовщина? A>2. Что-то не врублюсь. A>3. Впринципе, все понятно. A>4. Эксперт.
Классические этапы:
1) Не умеешь использовать.
2) Умеешь использовать.
3) Умеешь не использовать.
Здравствуйте, artelk, Вы писали:
A>А ООП вообще парадоксальная тема. Обычно, при изучении чего-то нового и сложного, изучающий проходит следующие этапы:
Парадоксальность (aka холиваропригодность) темы прямо связана с возможностью проверить (или опровергнуть) утверждения оппонентов. Я что-то не припомню мощных заруб на тему двоичной арифметики или проблем бинарной сортировки. Зато любое обсуждение паттернов/аджиля/метапрограммирования на макросах — только успевай оттаскивать
Без привязки к конкретному языку/фреймворку любое обсуждение неизбежно скатывается к замерам "моё ООП сильнее твоего!". Победил — эксперт, не вышло — что за чертовщина?
С привязкой — рулят не сферическое ООП и паттерны в вакууме, а знание матчасти и умение её с толком применять. Да, ООП как вещь в себе тоже входит в матчасть, но далеко не на первом месте.
Здравствуйте, dilmah, Вы писали:
D>спираль это простейший случай; we need to dig deeper: реально там марковский процесс
Дело осложняется еще и тем, что (подозреваю) количество вариантов понимания ООП сравнимо с количеством человек, утверждающих, что они понимают ООП.
И еще со временем этот термин претерпевал изменения в трактовке (I did not have C++ in mind (C) Alan Kay).
Если завтра ко мне (или к тебе) придет на собеседование сам Алан Кей, то очень вероятно, что придется послать его в пешее дальнее за незнание основ ООП!
Здравствуйте, minorlogic, Вы писали:
M>Если не путать ООП и ООД , тогда все ок.
Т.е. можно писать код в ООП парадигме, и при этом дизайн системы может не быть объектно-ориентированным? Оригинально.
Конечно же, ООП включает себя ООД.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, 0x7be, Вы писали:
A>>>Но в отношение ООП порядок строго обратный: 4, 3, 2, 1! A>>>Но самое интересное — на этом все не заканчивается и ряд продолжается: 2, 3, 4, 3, 2, 1, 2, 3, 4, 3, 2, 1... 0>>Пруфлинк?
I>Это он Гегеля перефразирует.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, artelk, Вы писали:
A>>1. На этапе 4, с которого все начинается, все кажется предельно простым, а бенефитов при этом обещают целую кучу! A>>2. "Новое платье короля": фуу, да у тебя тут говнокодище, ты что, вообще не понимаешь ООП?! A>>3. Бенефиты таки есть (по крайней мере, для некоторого подмножества задач).
I>Аналогия с шахматами, разбор партии: I>Игрок с рейтингом ЭЛО где то в 500 объясняет новичку — "здесь надо не так а вот так" I>Эло 1000 — "нет, это отстой и надо вот так" I>Эло 1500 — "это отстой, ибо будет мат через 15 ходов" I>Эло 2000 — "мата не будет, будет ничья после 10 ходов" I>Эло 2500 — "нужно сдаваться, партия уже проиграна"
Впечатляет. Только я второй день пытаюсь понять, аналогия к чему это?
Можно для особо тупых разжевать?
Здравствуйте, artelk, Вы писали:
A>И вот накопился у меня вопрос на текущем витке спирали. A>Что же есть полиморфизм в ООП? A>Из википедии:
A>
Subtype polymorphism, often referred to as simply polymorphism in the context of object-oriented programming, is the ability to create a variable, a function, or an object that has more than one form.
<>
Начнём с самого главного: с принципа подстановки Лисков (LSP). Именно по нему проходит граница.
Ад-хок-полиморфизм отличается от параметрического и субтипов тем, что плюёт на LSP.
Как именно это наплевательство реализовано — компилятором ли (перегрузка функций С++, параметры шаблонов С++, классы типов Хаскелла), проверками в рантайме пользователем — printf, if(typeid(p)==...), if(dynamic_cast<T*>(p)), паттерн-матчинг Пролога и Эрланга — это совершенно неважно.
Главное, что набор "съедобных" типов задаётся пользователем и образует плоскую одноуровневую иерархию: "некий аргумент" <- "аргумент конкретного типа".
Параметрический полиморфизм основывается на полиморфизме деталей реализации.
Он не плюёт на LSP, а воспроизводит требования деталей. Если детали функции на субтипах — значит, и вся функция на субтипах и отвечает LSP; если детали только произвольные — значит, и вся функция произвольная.
Полиморфизм субтипов вводит ограничения. Между типами вводится иерархия произвольной глубины (даже если это не классы, а прототипы или диапазоны — только тогда следить за иерархией будет уже не компилятор, а пользователь).
Параметрически полиморфные функции обязаны быть всеядными по LSP — если принимаешь аргумент базового типа, то и любого его наследника примешь.
Переопределения функций (как бы, ad-hoc) — обязаны быть контравариантными по входам и ковариантными по выходам: не зауживать типы аргументов, кроме определяющих, и не расширять тип результата. Тут смысл такой, что у семейства перегруженных функций мысленно есть одна интерфейсная параметрически полиморфная — а она должна отвечать LSP.
Для единственного определяющего аргумента (того, который this) — есть и очень простая (и логически выстроенная!) схема диспетчеризации, и, соответственно, очень простая реализация (таблицы виртуальных функций).
Для нескольких определяющих аргументов (т.е. когда делаем мультиметод) начинаются всякие неоднозначности и страсти.
Мне кажется, именно из-за неоднозначностей мультиметоды и не попали в ООП изначально. А когда нужда в них стала появляться — тут-то и начались все эти фокусы с двойной диспетчеризацией (которая, на самом деле, одна из возможных схем).
Да, ещё один важный момент: для субтипов нет ограничения на количество и ассортимент типов, в отличие от ad-hoc, где количество заранее известно либо ограничено какими-то внезапными факторами (например, подгрузкой модуля, который знает, что делать с данным тэгом варианта).
И, в то же время, есть ограничение на иерархию, в отличие от параметрического.
Здравствуйте, robin_of_the_wood, Вы писали:
VD>>Я начинал изучение ООП с C. ___>А можно немного детальнее?
Можно.
___>Не ради споров, а реально интересно. ___>Я могу представить(хотя это и не легко) как можно применять ООП используя голый С. ___>Но вот чтобы ООП таким образом изучать и даже начать изучать. Это как минимум сурово.
Все очень просто. Я учился писать на С. Одной из первых моих задач было создание ээ... текствого GUI . Эдакой оконной справочной (гипертекстовой, это было еще до того как HTML стал известен, а может и до его появления) системы.
Первая версия была написана в лоб. Код получился очень грязным и трудно поддерживаемым. Параллельно я читал книгу о программировании под Виндовс и проникся идеями ОО-дизайна. Это подтолкнуло меня искать пути абстрагирования работы с окнами. Так я пришел к объектам, сообщениям и виртуальным методам.
ООП, конечно же, эмулировался С-паттернами. Он был не таким как на С++.
Зато когда я стал изучать С++, то все ОО-понятия были для меня очевидны.
VD>>Потом С++ показался очень простым и понятным. ___>Ну сложность и непонятность С++ по моим наблюдениям именно с ООП и не очень связаны
Мне тоже так кажется. Но тут рядом прозвучало именно такое утверждение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Вот сюда смотреть: A>>>1. На этапе 4, с которого все начинается, все кажется предельно простым, а бенефитов при этом обещают целую кучу! A>>>2. "Новое платье короля": фуу, да у тебя тут говнокодище, ты что, вообще не понимаешь ООП?! A>>>3. Бенефиты таки есть (по крайней мере, для некоторого подмножества задач).
I>>Аналогия с шахматами, разбор партии: I>>Игрок с рейтингом ЭЛО где то в 500 объясняет новичку — "здесь надо не так а вот так" I>>Эло 1000 — "нет, это отстой и надо вот так" I>>Эло 1500 — "это отстой, ибо будет мат через 15 ходов" I>>Эло 2000 — "мата не будет, будет ничья после 10 ходов" I>>Эло 2500 — "нужно сдаваться, партия уже проиграна"
A>Впечатляет. Только я второй день пытаюсь понять, аналогия к чему это? A>Можно для особо тупых разжевать?
Аналогия про этапы 1 2 3 4 3 2 1 или как там было. Идейка в том, что понимание растет с опытом, при чем, как водится, растет не линейно а скачками, что естественно дял человека. И на каждом уровне пересматриваешь свои позиции.
У Гегеля это закон отрицания отрицания,т.е. движение по спирали.
Здравствуйте, 0x7be, Вы писали:
A>>Но в отношение ООП порядок строго обратный: 4, 3, 2, 1! A>>Но самое интересное — на этом все не заканчивается и ряд продолжается: 2, 3, 4, 3, 2, 1, 2, 3, 4, 3, 2, 1... 0>Пруфлинк?
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, artelk, Вы писали:
A>в ООП нет ничего сложного. A>если ты используешь "объекты" — значит ты используешь ООП. это просто.
Ну да, поначалу все просто. Остается только уточнить понятие "объект" в контексте ООП, чтобы небыло неоднозначности, а то термином "объект" в жизни можно назвать все, что угодно.
И тут начинается: identity, поведение, состояние... And we need to go deeper!
A>сделать правильную архитектуру, правильно использовать правильные технологии — это может быть сложно. но само по себе ООП — просто.
Само по себе "представим приложение в виде набора объектов, обменивающихся сообщениями" настолько же просто, насколько бесполезно на практике.
Здравствуйте, artelk, Вы писали: A>Но в отношение ООП порядок строго обратный: 4, 3, 2, 1! A>Но самое интересное — на этом все не заканчивается и ряд продолжается: 2, 3, 4, 3, 2, 1, 2, 3, 4, 3, 2, 1...
Это потому, что программирование в целом и ООП в частности знанием не являются. Это навык. Когда вы пересаживаетесь с механики на автомат или с микролитражки на БЧД, ваш навык вождения автомобиля ведет себя точно так же. Это нормально, нечего топики плодить по таким мелочам.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, artelk, Вы писали:
A>Но в отношение ООП порядок строго обратный: 4, 3, 2, 1! A>Но самое интересное — на этом все не заканчивается и ряд продолжается: 2, 3, 4, 3, 2, 1, 2, 3, 4, 3, 2, 1...
Пруфлинк?
Здравствуйте, artelk, Вы писали:
A>А ООП вообще парадоксальная тема. Обычно, при изучении чего-то нового и сложного, изучающий проходит следующие этапы:
A>1. Что за чертовщина? A>2. Что-то не врублюсь. A>3. Впринципе, все понятно. A>4. Эксперт.
A>Но в отношение ООП порядок строго обратный: 4, 3, 2, 1!
В сказках, рассказываемых теми, кто выше пункта 2 никогда не поднимался и не пытается.
Такие люди с рождения себя экспертами во многих сферах считают и ООП тут не единичный случай.
A>Но самое интересное — на этом все не заканчивается и ряд продолжается: 2, 3, 4, 3, 2, 1, 2, 3, 4, 3, 2, 1...
Это им так кажется. На самом деле там 1, 2, 1, 2, 1, 2... и не более того.
A>Поэтому, если встретится оппонент, находящийся, скажем, на этапе 2, целесообразно выяснить, на каком витке спирали он находится...
В своем воображении он может находиться где угодно. А на самом деле или 1 или 2
А у дошедших до пункта 3 и 4 появляется еще один очень важный пункт:
5. У любой вещи есть ограниченная область применения.
Здравствуйте, artelk, Вы писали:
A>А ООП вообще парадоксальная тема.
в ООП ничего сложного нет, если, конечно, не начинать его изучение с плюсов.
скажем, радиолюбители сначала собирают (и заставляют работать) приемник прямого усиления по готовым схемам. затем, они вносят в схему изменения на предмет улучшений до полного ее развала. после чего курят матчасть и проектируют отдельные компоненты уже самостоятельно.
затем они переходят к супергетеродину, который проще собрать, чем отладить. а собирают его по готовым схемам. и очень долго экспериментируют с ними прежде, чем отправиться в самостоятельное плаванье.
си++ -- очень сложный язык. начинать изучать ООП с него -- убийство времени, сил и кода.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>си++ -- очень сложный язык. начинать изучать ООП с него -- убийство времени, сил и кода.
Я начинал изучение ООП с C. Потом С++ показался очень простым и понятным.
ЗЫ
Правда это был старый С++. До того как на шаблонах стало можно писать рекурсивные функции работающие во время компиляции и использующие паттерн-матчинг для остановки рекурсии.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, artelk, Вы писали:
A>А ООП вообще парадоксальная тема. Обычно, при изучении чего-то нового и сложного, изучающий проходит следующие этапы:
A>1. Что за чертовщина? A>2. Что-то не врублюсь. A>3. Впринципе, все понятно. A>4. Эксперт.
A>Но в отношение ООП порядок строго обратный: 4, 3, 2, 1! A>Но самое интересное — на этом все не заканчивается и ряд продолжается: 2, 3, 4, 3, 2, 1, 2, 3, 4, 3, 2, 1...
A>Поэтому, если встретится оппонент, находящийся, скажем, на этапе 2, целесообразно выяснить, на каком витке спирали он находится...
"Если все кажется лёгким, это безошибочно доказывает, что работник весьма мало искусен и что работа выше его разумения." Леонардо да Винчи
Здравствуйте, VladD2, Вы писали:
VD>Я начинал изучение ООП с C.
А можно немного детальнее?
Не ради споров, а реально интересно.
Я могу представить(хотя это и не легко) как можно применять ООП используя голый С.
Но вот чтобы ООП таким образом изучать и даже начать изучать. Это как минимум сурово.
VD>Потом С++ показался очень простым и понятным.
Ну сложность и непонятность С++ по моим наблюдениям именно с ООП и не очень связаны
но в реальности же тебе был нужен вовсе не ООП, а модульность, абстрагирование, инверсия контроля, конкатенирование (когда сложное поведение получается комбинацией независимых, отдельно разрабатываемых кусков)
Здравствуйте, dilmah, Вы писали:
D>но в реальности же тебе был нужен вовсе не ООП, а модульность, абстрагирование, инверсия контроля, конкатенирование (когда сложное поведение получается комбинацией независимых, отдельно разрабатываемых кусков)
В реальности мне нужен был подход позволяющий легко описывать окна и взаимодействие с ним. А вот эти ваши "модульность, абстрагирование, инверсия контроля, конкатенирование" мне на фиг не упали. Я тогда о них и не слышал. Идей из книги по виндовс мне более чем хватило. А когда все эти идеи я увидел в С++ мне не пришлось их объяснять (хотя они были сильно иные). Ну, а то что это назвали ООП-ом меня вообще не колышет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
A>Но в отношение ООП порядок строго обратный: 4, 3, 2, 1!
Предполагаю, что это основная причина одержимости распространенности ООП.
На мой взгляд, три главные причины распространения ООП (в порядке убывания значимости) следующие:
1. На этапе 4, с которого все начинается, все кажется предельно простым, а бенефитов при этом обещают целую кучу!
2. "Новое платье короля": фуу, да у тебя тут говнокодище, ты что, вообще не понимаешь ООП?!
3. Бенефиты таки есть (по крайней мере, для некоторого подмножества задач).
Здравствуйте, artelk, Вы писали:
A>1. На этапе 4, с которого все начинается, все кажется предельно простым, а бенефитов при этом обещают целую кучу! A>2. "Новое платье короля": фуу, да у тебя тут говнокодище, ты что, вообще не понимаешь ООП?! A>3. Бенефиты таки есть (по крайней мере, для некоторого подмножества задач).
Аналогия с шахматами, разбор партии:
Игрок с рейтингом ЭЛО где то в 500 объясняет новичку — "здесь надо не так а вот так"
Эло 1000 — "нет, это отстой и надо вот так"
Эло 1500 — "это отстой, ибо будет мат через 15 ходов"
Эло 2000 — "мата не будет, будет ничья после 10 ходов"
Эло 2500 — "нужно сдаваться, партия уже проиграна"
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, minorlogic, Вы писали:
M>>Если не путать ООП и ООД , тогда все ок. A>Т.е. можно писать код в ООП парадигме, и при этом дизайн системы может не быть объектно-ориентированным? Оригинально. A>Конечно же, ООП включает себя ООД.
А если поменять "изучение ООП" на "освоение ООП", возражения будут?
"Освоение" включает в себя развитие способности правильно применять ООП при разработке — т.е. чтобы достичь обещанных бенефитов.
И вот накопился у меня вопрос на текущем витке спирали.
Что же есть полиморфизм в ООП?
Из википедии:
Subtype polymorphism, often referred to as simply polymorphism in the context of object-oriented programming, is the ability to create a variable, a function, or an object that has more than one form.
Ага, это Subtype polymorphism. Только нифига непонятно.
Смотрим тут:
subtyping polymorphism (sometimes referred to as dynamic polymorphism) allows a function to be written to take an object of a certain type T, but also work correctly if passed an object that belongs to a type S that is a subtype of T (according to the Liskov substitution principle). This type relation is sometimes written S <: T. Conversely, T is said to be a supertype of S—written T :> S.
Хорошо, только причем тут виртуальные функции, про которые сразу вспоминают, когда заходит речь о полиморфизме ООП?!
Формально, ни причем. Т.е. если в языке есть виртуальные функции — то это уже расширение базовой концепнии ООП (как лямбды в ОО языке C#).
Получается, что под "наследованием" в ООП следует понимаеть исключительно наследование реализации!
Subtype polymorphism зачем-то считается отдельной формей полиморфизма (не ad hoc и не parametric, см. Contents тут).
Выходит, что Gaperton в своем великолепном посте
ошибался, сводя его к параметрическому полиморфизму.
По мне, так это частный случай Bounded parametric polymorphism-а с упрощенным синтаксисом (не нужно явно указывать "генерик" параметр). Но у ООП ведь должен быть свой, особый полиморфизм и свой, особый гуманитарный путь развития!
Здравствуйте, artelk, Вы писали:
A>Т.е. можно писать код в ООП парадигме, и при этом дизайн системы может не быть объектно-ориентированным? Оригинально. A>Конечно же, ООП включает себя ООД.
Легко!
Как известно, ООП — это замыкания для бедных.
Берём какой-нибудь ФП-проект, интенсивно использующий функции высшего порядка и параметрический полиморфизм.
Тупо транслируем ФВП в интерфейс с единственным методом, а параметрический полиморфизм — в интерфейс с набором методов-примитивов (в ООД это называется "паттерн Стратегия" и "паттерн Шаблонный Метод"; чорт, всё-таки ООД пролез сюда! окей, вычёркиваем полиморфизм; или не вычёркиваем, но обфускиваем, чтобы не было в явном виде ни Стратегий, ни Шаблонных Методов).
Вуаля.
Здравствуйте, Кодт, Вы писали:
К>Легко! К>Как известно, ООП — это замыкания для бедных. К>Берём какой-нибудь ФП-проект, интенсивно использующий функции высшего порядка и параметрический полиморфизм. К>Тупо транслируем ФВП в интерфейс с единственным методом, а параметрический полиморфизм — в интерфейс с набором методов-примитивов (в ООД это называется "паттерн Стратегия" и "паттерн Шаблонный Метод"; чорт, всё-таки ООД пролез сюда! окей, вычёркиваем полиморфизм; или не вычёркиваем, но обфускиваем, чтобы не было в явном виде ни Стратегий, ни Шаблонных Методов). К>Вуаля.
Я имел ввиду, что изучение/освоение ООП включает в себя изучение/освоение ООД.
Мало с чем согласен (или мало что понял). Хотя бы вот: LSP определяется в контексте отношения тип-подтип (и, на самом деле, определяет это отношение); параметрический полиморфизм никакого отношения к этому отношению не имеет.
К>Начнём с самого главного: с принципа подстановки Лисков (LSP). Именно по нему проходит граница.
Не очевидно.
К>Ад-хок-полиморфизм отличается от параметрического и субтипов тем, что плюёт на LSP. К>Как именно это наплевательство реализовано — компилятором ли (перегрузка функций С++, параметры шаблонов С++, классы типов Хаскелла), проверками в рантайме пользователем — printf, if(typeid(p)==...), if(dynamic_cast<T*>(p)), паттерн-матчинг Пролога и Эрланга — это совершенно неважно. К>Главное, что набор "съедобных" типов задаётся пользователем и образует плоскую одноуровневую иерархию: "некий аргумент" <- "аргумент конкретного типа".
Не понял.
К>Параметрический полиморфизм основывается на полиморфизме деталей реализации.
Это как? К>Он не плюёт на LSP, а воспроизводит требования деталей. Если детали функции на субтипах — значит, и вся функция на субтипах и отвечает LSP; если детали только произвольные — значит, и вся функция произвольная.
Можно пример(ы)?
К>Полиморфизм субтипов вводит ограничения. Между типами вводится иерархия произвольной глубины (даже если это не классы, а прототипы или диапазоны — только тогда следить за иерархией будет уже не компилятор, а пользователь). К>Параметрически полиморфные функции обязаны быть всеядными по LSP — если принимаешь аргумент базового типа, то и любого его наследника примешь.
Ты о всех параметрически полиморфных функциях говоришь или только об огранниченно-полиморфных с ограничемиями вида ТипПараметра <: Тип?
Если о последних, то они по своему определению всеядны по LSP.
<...>
К>Да, ещё один важный момент: для субтипов нет ограничения на количество и ассортимент типов, в отличие от ad-hoc, где количество заранее известно либо ограничено какими-то внезапными факторами (например, подгрузкой модуля, который знает, что делать с данным тэгом варианта).
А для субтипов нет ограничений внезапными факторами (например, подгрузкой модуля, который знает, какие еще субтипы данного типа бывают)?
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, Кодт, Вы писали:
A>Мало с чем согласен (или мало что понял). Хотя бы вот: LSP определяется в контексте отношения тип-подтип (и, на самом деле, определяет это отношение); параметрический полиморфизм никакого отношения к этому отношению не имеет.
Естественно. И ad-hoc, и параметрический полиморфизм не смотрят на LSP.
К>>Начнём с самого главного: с принципа подстановки Лисков (LSP). Именно по нему проходит граница. A>Не очевидно.
Вот именно поэтому граница проходит по LSP. Мы ведь хотим разобраться, чем субтипы так отличаются от всего остального.
К>>Ад-хок-полиморфизм отличается от параметрического и субтипов тем, что плюёт на LSP. К>>Как именно это наплевательство реализовано — компилятором ли (перегрузка функций С++, параметры шаблонов С++, классы типов Хаскелла), проверками в рантайме пользователем — printf, if(typeid(p)==...), if(dynamic_cast<T*>(p)), паттерн-матчинг Пролога и Эрланга — это совершенно неважно. К>>Главное, что набор "съедобных" типов задаётся пользователем и образует плоскую одноуровневую иерархию: "некий аргумент" <- "аргумент конкретного типа". A>Не понял.
Если у нас есть семейство функций вида foo(T), включающие foo(int), foo(string), template<class X> foo(X*)
то получается иерархия "что угодно из перечня (int,string,указатель)" <-- int; string; X*
Если в этом семействе есть универсальная ловушка-заглушка — foo(...) или tempate<class T> foo(T), — то корневым типом будет не вариантный, а "вообще что угодно".
В С++ информацию о типе знает компилятор, в хаскелле — отчасти компилятор, отчасти она передаётся в рантайме, в яваскрипте каком-нибудь — всё в рантайме и на пользователе.
К>>Параметрический полиморфизм основывается на полиморфизме деталей реализации. A>Это как? К>>Он не плюёт на LSP, а воспроизводит требования деталей. Если детали функции на субтипах — значит, и вся функция на субтипах и отвечает LSP; если детали только произвольные — значит, и вся функция произвольная. A>Можно пример(ы)?
Для любых подходящих типов делаем два действия
— T2 operator+(T,T) — как правило, перегруженный или определённый компилятором, т.е. ad-hoc
— ostream& operator<<(ostream&,T2) — наверняка перегруженный, т.е. ad-hoc
То же самое на хаскелле
foo :: (Num a, Show a) => a -> IO ()
foo a = putStrLn (show (a+a))
С той разницей, что С++ генерит воплощение шаблона для каждого использованного типа, а хаскелл — единственное воплощение с двумя неявными параметрами: словарём класса Num и словарём класса Show.
В эту функцию мы можем подсунуть не любой тип, для которого определены + и <<, а только участника иерархии INumShow.
Зато этих участников может быть сколько угодно, хоть из сторонней dll позаимствуем (тогда как в первом случае все типы были известны компилятору ещё до линковки).
Кстати, здесь я схитрил: не стал делать мультиметод plus(INumShow*,INumShow*), который был бы определён для пар одинаковых типов, так, как это сделано в классе Num у хаскелла. Потому что сразу встал бы вопрос: а как он определён для неодинаковых типов?
И здесь мы бы получили жирный-прежирный ад-хок. Ну, я об этом уже говорил раньше.
К>>Полиморфизм субтипов вводит ограничения. Между типами вводится иерархия произвольной глубины (даже если это не классы, а прототипы или диапазоны — только тогда следить за иерархией будет уже не компилятор, а пользователь). К>>Параметрически полиморфные функции обязаны быть всеядными по LSP — если принимаешь аргумент базового типа, то и любого его наследника примешь. A>Ты о всех параметрически полиморфных функциях говоришь или только об огранниченно-полиморфных с ограничемиями вида ТипПараметра <: Тип? A>Если о последних, то они по своему определению всеядны по LSP.
Разумеется, я уже про ограниченно-полиморфные начал. Да, именно "по определению".
И можно заметить, что их "по определению" отличается от "по определению" ад-хок и "по определению" подлинно параметрических
К>>Да, ещё один важный момент: для субтипов нет ограничения на количество и ассортимент типов, в отличие от ad-hoc, где количество заранее известно либо ограничено какими-то внезапными факторами (например, подгрузкой модуля, который знает, что делать с данным тэгом варианта). A>А для субтипов нет ограничений внезапными факторами (например, подгрузкой модуля, который знает, какие еще субтипы данного типа бывают)?
Если не подгрузить модуль с реализацией субтипа, то в системе ничего не изменится, кроме того, что этот субтип нигде не будет фигурировать.
А если не подгрузить модуль с реализацией ад-хок обработчика, то, встретив данный тип, мы пойдём по иному пути. По какому именно? Это уж как захотим, или как получится:
— исключительная ситуация: "неизвестный науке тип"
— ловушка: "by default"
— другой подходящий обработчик
Предвидя вопросы, замечу: в ООП-программах встречаются места с махровым ад-хоком. Это всяческая десериализация (чтение конфигов, фабрики классов по GUID/ProgID/etc...)
К>Для любых подходящих типов делаем два действия К>- T2 operator+(T,T) — как правило, перегруженный или определённый компилятором, т.е. ad-hoc К>- ostream& operator<<(ostream&,T2) — наверняка перегруженный, т.е. ad-hoc
К>То же самое на хаскелле К>
К>foo :: (Num a, Show a) => a -> IO ()
К>foo a = putStrLn (show (a+a))
К>
К>С той разницей, что С++ генерит воплощение шаблона для каждого использованного типа, а хаскелл — единственное воплощение с двумя неявными параметрами: словарём класса Num и словарём класса Show.
Да, придумал пример на голом си, практически по мотивам хаскелла.
/* обе функции размещают результат в malloc */typedef void* (*PLUS_PROC)(void*, void*);
typedef char* (*SHOW_PROC)(void*);
void foo(PLUS_PROC plus, SHOW_PROC show, void* t, FILE* f)
{
void* tt;
char* s;
tt = plus(t,t);
s = show(tt);
fprintf(f, "<< %s >>\n", s);
free(s);
free(tt);
}
/******* пользовательский код *******/void* plus_shorts(void* a, void* b)
{
int* sum;
sum = (int*)malloc(sizeof(int));
*sum = *(short*)a + *(short*)b;
return sum;
}
char* show_int(void* i)
{
char* buf;
buf = (char*)malloc(sizeof(int)*10/3 + 2);
sprintf(buf, "%d", *(int*)i); /* itoa(*(int*)i, buf, 10); */return buf;
}
int main()
{
short x;
x = 12345;
foo(plus_shorts, show_int, &x, stdout);
}
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, artelk, Вы писали:
К>>>Он не плюёт на LSP, а воспроизводит требования деталей. Если детали функции на субтипах — значит, и вся функция на субтипах и отвечает LSP; если детали только произвольные — значит, и вся функция произвольная. A>>Можно пример(ы)?
К>Параметрический, вытекающий из ad-hoc
К>На С++ К>
К>Для любых подходящих типов делаем два действия К>- T2 operator+(T,T) — как правило, перегруженный или определённый компилятором, т.е. ad-hoc К>- ostream& operator<<(ostream&,T2) — наверняка перегруженный, т.е. ad-hoc
Я не согласен что это параметрический. Если мы разделим объявление на декларацию и объявление, то декларация будет параметрической, а объявление — ad-hoc. Чисто параметрический полиморфизм обязан работать для любых типов. А здесь — лишь для тех, для которых определены "+" и "<<".
Вобщем, и не чисто параметрический и не чисто ad-hoc. А чисто часть от того и другого.
К>То же самое на хаскелле К>
К>foo :: (Num a, Show a) => a -> IO ()
К>foo a = putStrLn (show (a+a))
К>
К>С той разницей, что С++ генерит воплощение шаблона для каждого использованного типа, а хаскелл — единственное воплощение с двумя неявными параметрами: словарём класса Num и словарём класса Show.
Здесь чисто bounded полиморфизм. Т.к. про квантор всеобщности мы забыли при объявлении сигнатуры функции.
К>Параметрический, на субтипах К>
К>В эту функцию мы можем подсунуть не любой тип, для которого определены + и <<, а только участника иерархии INumShow.
Да, и потому это не чисто параметрический, который должен принять любой тип. Это именно subtype полиморфизм. К>Зато этих участников может быть сколько угодно, хоть из сторонней dll позаимствуем (тогда как в первом случае все типы были известны компилятору ещё до линковки).
A>>Ты о всех параметрически полиморфных функциях говоришь или только об огранниченно-полиморфных с ограничемиями вида ТипПараметра <: Тип? A>>Если о последних, то они по своему определению всеядны по LSP.
К>Разумеется, я уже про ограниченно-полиморфные начал. Да, именно "по определению". К>И можно заметить, что их "по определению" отличается от "по определению" ад-хок и "по определению" подлинно параметрических
С такой оговоркой часть претензий снимается, кроме разве что примера на Хаскеле. Там bounded и все тут.
К>>>Да, ещё один важный момент: для субтипов нет ограничения на количество и ассортимент типов, в отличие от ad-hoc, где количество заранее известно либо ограничено какими-то внезапными факторами (например, подгрузкой модуля, который знает, что делать с данным тэгом варианта). A>>А для субтипов нет ограничений внезапными факторами (например, подгрузкой модуля, который знает, какие еще субтипы данного типа бывают)?
К>Предвидя вопросы, замечу: в ООП-программах встречаются места с махровым ад-хоком. Это всяческая десериализация (чтение конфигов, фабрики классов по GUID/ProgID/etc...)
Дык суть всего ООП в понимании А. Кея в терминах полиморфизма сводится к ад-хоку времени выполнения. А то что он реализован через сабтайпинг — это детали реализации.
К>>Для любых подходящих типов делаем два действия К>>- T2 operator+(T,T) — как правило, перегруженный или определённый компилятором, т.е. ad-hoc К>>- ostream& operator<<(ostream&,T2) — наверняка перегруженный, т.е. ad-hoc
S>Я не согласен что это параметрический. Если мы разделим объявление на декларацию и объявление, то декларация будет параметрической, а объявление — ad-hoc. Чисто параметрический полиморфизм обязан работать для любых типов. А здесь — лишь для тех, для которых определены "+" и "<<". S>Вобщем, и не чисто параметрический и не чисто ad-hoc. А чисто часть от того и другого.
В смысле, на декларацию и объявление? Может быть, на определение?
Чисто параметрический полиморфизм — это сфероконь.
Хоть что-то же должно превратиться в конкретику, ну хотя бы, управление памятью.
Впрочем, вот пример максимально очищенного от конкретики
template<class T> // по сути, здесь T только для контроля типов нужен - можно даже заменить на void
std::shared_ptr<T> // управление памятью абстрагировано от T, спасибо механизму shared_ptr
pop_back_if_exist(std::vector< std::shared_ptr<T> >& v) // вектору указателей всё равно, что хранить
{
std::shared_ptr<T> f;
if(!v.empty()) { f = v.back(); v.pop_back(); }
return f;
}
Точнее, мы всю конкретику явно прибили гвоздями, не накладывая ограничений на собственно полиморфный тип.
К>>То же самое на хаскелле К>>
К>>foo :: (Num a, Show a) => a -> IO ()
К>>foo a = putStrLn (show (a+a))
К>>
К>>С той разницей, что С++ генерит воплощение шаблона для каждого использованного типа, а хаскелл — единственное воплощение с двумя неявными параметрами: словарём класса Num и словарём класса Show. S>Здесь чисто bounded полиморфизм. Т.к. про квантор всеобщности мы забыли при объявлении сигнатуры функции.
А он нам здесь нужен, квантор всеобщности? forall a вроде как подразумевается?
<>
К>>Предвидя вопросы, замечу: в ООП-программах встречаются места с махровым ад-хоком. Это всяческая десериализация (чтение конфигов, фабрики классов по GUID/ProgID/etc...) S>Дык суть всего ООП в понимании А. Кея в терминах полиморфизма сводится к ад-хоку времени выполнения. А то что он реализован через сабтайпинг — это детали реализации.
Тогда хаскелл — это ООП-язык? Вот, даже слово "класс" присутствует
Здравствуйте, Кодт, Вы писали:
К>Начнём с самого главного: с принципа подстановки Лисков (LSP). Именно по нему проходит граница.
К>Ад-хок-полиморфизм отличается от параметрического и субтипов тем, что плюёт на LSP.
Не могу согласиться.
Во-первых, плевать или не плевать на LSP может только программист, а не конкретная техника или механизм языка.
Я уже писал на эту тему тут: http://www.rsdn.ru/forum/philosophy/4355436.1
(предлагаю прочитать, прежде чем двигаться дальше в этом посте).
Во-вторых, "обычный" полиморфизм через наследование — это просто подмножество параметрического полиморфизма с зашитым предикатом "is_base_of".
То есть следующие два куска кода ничем, кроме времени диспетчеризации (compile time/run time), не отличаются:
template< class T>
enable_if< quacks_as_duck<T> >
f(T& x) {}
А уже обязанность программиста — следить, чтобы типы, которые он функции подсвывает, удовлетворяли принципу Лисков.
В-третьих, ad-hoc-полиморфизм сам по себе никак не противоречит принципу Лисков, потому что представляет собой опять же просто разновидность параметрического полиморфизма. При обычном полиморфизме, когда ты добавляешь типы к множеству допустимых типов, ты ведь одновременно с этим добавляешь и какие-то операции, так? Но ведь ты можешь добавлять не только внутренние операции, но и внешние, например, придумав свой арифметический класс и правильно(!) реализовав для него арифметические операторы. Таким образом твой класс является подтипом типа аргумента оператора+.
Более того, ты можешь пойти дальше и тип, не являющийся подтипом формально, сделать таковым — я говорю здесь о traits и concept_map.
Так что LSP — это крайне широкий принцип, никак не завязанный на механизмы конкретного языка, диспетчеризацию времени исполнения или времени компиляции и т.п. Он не об этом. Он — о логической совместимости типов с неким архетипом, зашитым в предусловиях функции.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, samius, Вы писали:
К>>>Параметрический, вытекающий из ad-hoc
S>>Я не согласен что это параметрический. Если мы разделим объявление на декларацию и объявление, то декларация будет параметрической, а объявление — ad-hoc. Чисто параметрический полиморфизм обязан работать для любых типов. А здесь — лишь для тех, для которых определены "+" и "<<". S>>Вобщем, и не чисто параметрический и не чисто ad-hoc. А чисто часть от того и другого.
К>В смысле, на декларацию и объявление? Может быть, на определение?
Верно
К>Чисто параметрический полиморфизм — это сфероконь.
В C++ — да К>Хоть что-то же должно превратиться в конкретику, ну хотя бы, управление памятью.
В конкретику превращается все, вопрос в том, требует ли превращение в конкретику специального подхода, вот как в операторе "+". К>Впрочем, вот пример максимально очищенного от конкретики К>
К>template<class T> // по сути, здесь T только для контроля типов нужен - можно даже заменить на void
К>std::shared_ptr<T> // управление памятью абстрагировано от T, спасибо механизму shared_ptr
К>pop_back_if_exist(std::vector< std::shared_ptr<T> >& v) // вектору указателей всё равно, что хранить
К>{
К> std::shared_ptr<T> f;
К> if(!v.empty()) { f = v.back(); v.pop_back(); }
К> return f;
К>}
К>
К>Точнее, мы всю конкретику явно прибили гвоздями, не накладывая ограничений на собственно полиморфный тип.
Согласен
К>>>
Здравствуйте, B0FEE664, Вы писали:
BFE>big-endian VS little-endian никогда не видел? BFE>Или там, прямой код VS дополнительный код...
+100500
sign vs unsign ещё забыл
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, artelk, Вы писали:
A>>И вот накопился у меня вопрос на текущем витке спирали. A>>Что же есть полиморфизм в ООП?
D>http://www.rsdn.ru/forum/philosophy/2853873
Здравствуйте, artelk, Вы писали:
A>Ссылка как раз на это сообщение Gaperton-а была в сообщении, на которое ты ответил этой ссылкой.
Чукча не читатель, фигли.
Но вообще, начать с жизнеутверждающего в духе "фигня все эти ваши баззворды" и скатиться до ковыряния в них самых — не понимаю.
Здравствуйте, dilmah, Вы писали:
D>В каждой шутке про ООП есть иерархия этапов
В этой вроде как нет. Есть только перечисление...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Перекуём баги на фичи!
