Полиморфизма нет без наследования (кроме статического), вопроса не понимаю.

Наследование может быть заменено делегированием, например.

Что важнее, изменчивость или наследование?

полиморфизм или наследование?

Вопрос лишён смысла, нужно то и другое.

Для эволюционного развития важнее изменчивость или наследование?

Вопрос не лишён смысла, и вот почему:
- Во многих ООП-языках нет наследования, но есть делегирование, примеры: Io, go, factor.
- Наследование далеко не единственный способ достичь полиморфизма: например, во многих языках есть такая вещь, как интерфейсы.

Полиморфизм конечно. А концептуально скорее наоборот.

Полиморфизм - суть ООП. Уже и Гослинг сказал, что лучше бы наследования (реализации) в яве не было.

Полиморфизма нет без наследования (кроме статического)

Как у тебя в тегах оказался питон?

man ООП.

Наследование далеко не единственный способ достичь полиморфизма

Наследование не есть способ достижения полиморфизма.

Всё-равно, что спрашивать, что важнее в составе воды: кислород или водород.

Полиморфизм и наследование два неотъемлимо присущих качества ОО-системы.

А как же mixins?

ООП не нужно.

Полиморфизм и наследование(в том числе и от прототипа, например).

Скорее вредно, чем ненужно.

Пацаны, пацаны! А ведь есть ещё эта, ну как её... Имкупсуляция!

Плюсую.

я знаю три слова, три матерных слова...

... инкапсуляция, наследование, полиморфизм :)
Крылья? Ноги!

миксины это один из способов реализации множественного наследования

всё тлен

Открыл. Увидел заголовок «Does OOP really separate interface from implementation?». Нажал PgDown. Увидел код на крестах. Закрыл.

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

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

Проектирование иерархии наследования и прогнозирование будущих use case (способов использования) очень трудоёмко и легко ошибиться. Пример неверной модели иерархии классов: Java AWT, которая переписывалась уже потом, сохраняя совместимость с уже написанными приложениями, была проделана колоссальная работа.

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

видел тред на одной стрнаице

Очевидно же что инкапсуляция.

В ООП существеннее всего инкапсуляция.

Без инкапсюляции информации теряется весь смысл ООП, так как всё остальное моделируется существующими решениями (функциональное/процедурное программирование с объектами диспетчеризации вызовов функций/процедур).

Ты знал!

если про агрегацию то рекордов(привет Кобол) до ООП не было.

если про сокрытие то 1. модулей до ООП не было . 2. снижение связности тоже какбе ООП не открыло.

вопрос ОП что важнее для «ООП» полиморфизм(т.е обобщение алгоритмов и автоопределение по типу обьекта метода) либо наследование(повторное использование и классификация «Линнея»)

Олеговский сайт при включенном по дефолту шрифте из xkcd читается весьма забавно.

PImpl и прочие паттерны. (комментарий)

iZEN

Не ко мне. Я всё время держу в памяти модули TurboPascal.

В модулях невозможно раскрыть детали реализации через наследование, так как наследования в модулях нет, используется механика использования только специфицированного и явно объявленного (use this). А в иерархии классов возможность раскрыть детали реализации вверх по иерархии есть, так как используется механика is-a, тем самым нарушается принцип инкапсуляции информации в ООП.

полиморфизм же. потому что наследование можно реализовать через полиморфизм (миксины) *просто* , а наоборот, полиморфизм через наследование — слишком *костыльно* (is-a обшщче чем has-a) : второй способ требует множество ad-hoc иерархий классов, что есть костыль.

сношения-отношения тайпклассы ширче чем предок-потомок. потомки через тайпклассы — легко и просто, тайпклассы через потомков и наследование — адъ и израиль.

потому полиморфизм же.

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

что как бы намекает нам, что ортогонализировать дальше можно этот базис из трёх в базис из двух, например.

или в из одного — сферический полиморфизЪм в вакууме, как partitial evaluation, а уже специализации этого част. вычисления это суть и наследование, и полиморфизм, и инкапсуляция, и его 2 штуки, и что там ещё угодно будет.

если про сокрытие то 1. модулей до ООП не было

ниправда твоя. модульное суть структурное программирование и ADT, это примерно 60-65 года. ООП это например симула-67, внезапно, 67 год.

модульное например, модула, оберон, бета, cedar и прочая хипстота (limbo,go,..мльщина) : модули уже есть, раздельная компиляция есть, интерфейсы меж модулями есть через ADT, а ни наследования ни полиморфизма ни инкапсуляции данных нет (есть для модулей, не для данных).

то есть ооп - слова по сути нет, а жо^W по духу — есть.

пимпл же хавают из-за костылей (поломанный ABI) плюсанутые, ради бинарной совместимости. вот в оберон-2, BBCP например ABI не ломаеццо, и этот «подтерн» не нужен, потому чта модули сделаны толково, с блекджеком, динамической загрузкой (без динамической линковки) и fingerprint-ами. см. евойный рантайм апи модуля и интроспекцию во все поля.

так как наследования в модулях нет, используется механика использования только специфицированного и явно объявленного (use this

это в ваших дурацких паскакалях нет. а вот в оберонах есть звёздочка экспорт(чтение-запись), есть минус экспорт (только на чтение), и приватный/публичный импорт модулей.

ну чем не кони^W наследование модулей,а ?

А в иерархии классов возможность раскрыть детали реализации вверх по иерархии есть, так как используется механика is-a, тем самым нарушается принцип инкапсуляции информации в ООП.

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

ну чем не кони^W наследование модулей,а ?

Это не наследование, а разграничение использования.

Наследование в другом. Переопределить процедуру в модуле, заюзав её в другом модуле, не получится — нужно делать обёртку над ней. Пусть даже с такой же публичной сигнатурой, что и у используемой функции/процедуры, но это уже будет не наследование, а перекрытие.

будь ВНИМАТЕЛЕН при обГОНЕ.

вот в соседнем треде пилят напильником про торсионные поля и эфиродинамику... лулзы однако, но ведь идея айперона-амера-как-там-его это и есть самый натуральный «сферический полиморфизм» в вакууме, без всяких там эволюций, метасистемных переходов и синергетик? полный генетический перенос, по лысенковщине

Без инкапсюляции информации теряется весь смысл ООП, так как всё остальное моделируется существующими решениями (функциональное/процедурное программирование с объектами диспетчеризации вызовов функций/процедур).

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

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

но это уже будет не наследование, а перекрытие

а если из перекрытой вызвать (call-next-method)? или [ :doesNotUnderstand ] ? и далее в диспетчеризацию над рантаймом.

ну или их аналоги палками и верёвками над интерфейсами и интроспекцией модулей.

Начнем с «что такое ООП»? Что такое полиморфизм?

1. к А.кею.

2. определение(авто) какой код исполнять по типу(«актуальному»- т.е момента исполнения) первого аргумента среди одноимённых функций подходящих по сигнатуре.

2.

это полиморфизм кода. а что такое полиморфизм данных (типов)?

вот когда мы в стек ложим аргументы функции cdecl calling convention, а потом внезапно вытаскиваем не того типа, что положили — это полиморфизм чего?

или, когда разыменовали указатель в другой тип? это полиморфизм чего?

или, указатель на метод.

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

то есть, сишный cdecl (неявно требует, что известны все типы и количество аргументов) можно ослабить : достаточно знать *одинаковость* типов в местах положили/получили. выходит такой лисповый calling convention, где полиморфность обеспечивается соответствием друг другу push/pop. с точки зрения cdecl это полиморфизм.

2 определение(авто) какой код исполнять по типу(«актуальному»- т.е момента исполнения) первого аргумента среди одноимённых функций подходящих по сигнатуре.

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

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

Полиморфизм в ООП достаточно полезен и безобиден, например при наследовании интерфейса.

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

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

А если мы хотим диспетчеризацию не только по первому аргументу, ООП нам покажет фигу?

молодец!

Что такое полиморфизм?

в данном треде - ad-hoc полиморфизм, одиночная диспетчеризация

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

в ручную на диспетчериш , и фигу не увидеш.

всё таки для случая «ад-hoc одиночной диспетчеризации» VS наследование.

что есть из этих двух квадратноколёсных велосипедов инструмент с положительной полезностью , а что (если есть) ритуализированной случайностью ?

Такое ощущение, что у тебя аккаунт угнали. Или ты там третьи сутки пьяный в говно?

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