Большие проблемы наследования в ООП

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

музыкальное сопровождение шикарно

10 тыс лайков от горе программистов

автор сам создал проблему и обвинил в этом наследование. Ясно

Код в C# написан или Java?

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

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

Слоны на самом деле умеют плавать

Очень интересное решение. А в шарпах нет миксинов?

Можно более подробный разбор последнего примера ? А-то я вроде понял , но больше на интуицию , хотелось бы больше ясности в нем , что бы так сказать уверенно ступать и чувствовать твердый пол под ногами =D

А можно было бы не заниматься херней и в базовый класс "Зверушки" добавить метод "Перемещаться", а конкректная реализация метода "Перемешаться" в конкректном классе "Рыбка" уже бы реализовала необходимое перемещение, а именно плавание

Другими словами нельзя городить абстактный класс "Средство_передвижения" с конкретным методом "Ехать", потому что он может и плавать и летать, все зависит от класса наследника который реализует конкректное поведение и конкректное средство_передвижения

P. S У абстрактного класса и методы абстрактные

Всё классно, но вот про то, что исключения не нужны, это ты, конечно, хватанул. А как мне ещё быстро свернуть стек при завершении длинной рекурсии? Чё, скакать по ретурнам, как долбоящеру? )))))

Слоны ес шо умеют плавать

Я столько раз пытался тоже самое объяснить разрабам, но всегда встречал полное непонимание)

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

исключения — насилие над системой типов

Чем опытнее кодер - тем реже он использует наследование реализации и чаще - наследование интерфейсов...

Полезно, понятно, быстро и с музыкой! Однозначно лайк и спасибо! 😘

Просто абстрактный класс нужно назвать Move. )))

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

Нужно было создать метод "BAJOBATbC9_POD_XBOCT" для класса "ADEPT_OOP".

Где мы говорим что все звери могут ходить, надо записать этот метод в абстрактный класс НЕ ДЕЛАЯ ЭТО САМЫЙ МЕТОД АБСТРАКТНЫМ, и всё, этот метод добавляется ко всем наследованным классам и нам не надо его реализовывать в каждом классе. К пингвину же мы добавляем его собственный метод плавания и всеееее. Или либо я такой тупой, что не понимаю всего того что городит Экстрим в первом примере, либо это у экстрима опять приступ шизофрении

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

Я может чего-то не понимаю, но можно просто не делать базовый класс абстрактным, тогда в реализации производных не надо будет переписывать те функции, которые там не нужны

Я под такую музыку иногда отхватывал и иногда сам кому-нибудь вкладывал на подмосковных дискотеках в начале нулевых))) А тут ООП.

Автор не умеет выделять абстракции.

ExtremeCode: Хорошо что современные языки не поддерживают множественного наследования...
Тоже ExtremeCode: Делает множественную реализацию интерфейсов с дефолтными методами
🤡

Над было сказать: "Пример решения проблем наследования мостом и стратегией"

Ты паходу и есть Life of Boris

Penguin это модель данных, в ней не должно быть зависимостей. Попробуйте сделать стратегию с применением clean architecture. Вся логика обработки событий должна быть в сервисном слое. Этот пример не применим к реальным бизнес задачам.

А зачем тебе абстрактный класс?

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

Слишком идеальный контент. Пишу комментарий, чтобы было понятно, что вы делаете лучшие туториалы на свете. И великолепным голосом

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

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

Классно! Помню как в рамках изучения JS писал терариум, так добавление каких-либо возможностей "жителям" иногда приводило к хорошим проблемам. А вообще мне понравилось)

В плюсах есть множественное наследование...

УЖААААССС) Как забить гвоздь микроскопом - это как раз про эти подходы)))) Сложно, код вынесен в кучу мест, модель получается раздробленная, логика вынесена вообще к авакову на кулички, УЖАССС!!! Это не программирование, а надувание щёк. Это не про творчество при программирование, а про потешание своего эго(...

) ахахахаха)))))))))) Так проблема-то вовсе не в наследовании, а в абстрактных методах)))) Абстракции вообще надо только тогда, когда без них никак)))
Учите матчасть и будет вам наследование очень нравиться) Просто пишите как люди, а не как обизяны после крутых курсов))))
Я вообще в коде на crystal-lang отлично справляюсь ВООБЩЕ без абстракций простым наследованием и код ОЧЕНЬ внятный и понятный получается.

Слоны умеют плавать

Сплошная манипуляция. Начнем с того, что идет рассказ про абстракции, а в мэйне идет работа с конкретным типом. Ну да ладно, не будем придираться. Итак, абстрактный клас Animal, автор добавляет в него конкретный метод Walk вместо абстрактного Move и дальше начинает решать созданую самим же собой проблему. Наследование подразумевает перенятие основополагающей логики, а интерфейсы - обозначение второстепенной. И вот тут автор умолчал об основной проблеме предложенного им решения, а именно том, как экшоны будут менять состояние объектов на которых они висят. Чем более фундаментальный фунционал переносится в классы стратегии, тем больше доступа к данным для них нужно предоставлять. Т.е. решам одну проблему, но создаем другую.

ну и где 3d демонстрация ходьбы и плаванья пингвина по нажатиям клавиш

То есть про разделение интерфейсов в SOLID автор не слышал

Ебу**я музыка! Из головы теперь не выходит...

так подумал, в джаве таких проблем пока не наблюдается