Большие проблемы наследования в ООП
Vložit
- čas přidán 8. 01. 2020
- В этом видео мы узнаем какие проблемы несет в себе принцип наследования из ООП и как эти проблемы можно решить при помощи стратегии, интерфейсов или методов расширения
Исходники из видео
github.com/extremecodetv/Inhe...
Видосик про Стратегию
• Важнейший шаблон прогр...
Музыка: DJ Blyatman - SLAV KING feat. Life of Boris (Instrumental)
• DJ BLYATMAN - SLAV KIN...
#ооп #программирование #наследование
Доп. ссылки:
● Insta: / _extremecode
● VK: extremecodetv
● Telegram Chat: t.me/extremecode (или в поиске @extremecode_chat)
● Конструктор сайтов StoryLand: storyland.mobi/?... - Věda a technologie
Пингвин должен говорить не "ХЗ", а "Линукс"
И еще пингвин бы сказал что ООП говно, а Си наше все! Каждый раз для граблей - ООП с выходом новых стандартов (по факту костылей которые называют фичами) для того чтобы улучшить грабли. Но всеравно грабли от этого не перестают ими быть, даже если они удобнее! Как следсвие over-garbage код, утечки памяти, мусорный код сжирающий ресурсы машины... Таким бы был пингвин если бы Линус Торвальд использовал грабли ООП для создания этой системы! Да и был бы этот пингвин еще жив - большой вопрос!
"fuck nvidia"(c)
GNU
А в чем разница?
представь себе пингвина у которого звуки хз XD
Слоны умеют плавать :)
В остальном, как обычно, красава :)
Ты слон
@@dashandr1 И кто это говорит, жирный троль? :)
@@evgeniym29 азарной слон)
Кстати да, они хорошо плавают
Кликбейт же
Когда пришёл узнать о недостатках наследования, но вместо этого начал танцевать ХАРДБАСС!
4:19 Как же хорошо, что в C# нет множественного наследования
4:20 ...А теперь в C# 8 можно пилить дефолтную реализацию интерфейса
@@user-w32eiJkNlIn9a2nRq6n Они становятся абстрактными классами просто с возможностью множественного наследования.
@@user-w32eiJkNlIn9a2nRq6n так и просто полностью абстрактный класс остается контрактом, который нельзя сам по себе инстанцировать.
@@user-w32eiJkNlIn9a2nRq6n "Он может содержать в себе кучу базовой логики, в отличие от интерфейса." (с)
Но начиная с 8-й версии, это отличие полностью исчезает.
@@voltamperoff Глупость, в интерфейс ты не добавишь поле. Это вся суть интерфейса, ты не можешь задать стейт классу.
Интерфейсы описывают, что класс делает, а абстрактный, как он это делает, то есть в нём лежит кусок кода, работающий за логику наследников. В интерфейсе методы логики особой не несут. Можно даже сказать, что метод в интерфейсе - заглушка, которую можно переделать (с целью избежания рефакторинга)
Сидишь такой, ура наконец то начал понимать ООП, спасибо видосу теперь понятно, что ни хя не понятно XD
Проблемы не у наследования в ООП, а у того, кто неправильно его применяет. Если вы забиваете микроскопом гвозди, то ни гвозди, ни микроскоп в этом не виноваты.
так он вроде именно про это и говорит.
Илья Иванов
, наследование - это не совсем удачный термин для этого механизма. Именно поэтому это самое "наследование" и применяют неправильно многие люди.
Если термин "наследование" заменить на термин "расширение функциональности", то название становится рекомендацией к применению этого механизма.
ога, архитектурно-структурные подходы.
Проблемы с доступом к джой казино, как только увидел твой коммент у меня пронеслось в первую очередь
Но почему микроскоп обычно применяют нормально, а наследование пихают хер знает куда? Кроме того, применений у этого "микроскопа" не так уж и много между прочим. А апологеты ООП выставляют его как "основопологающий принцип", один "трёх якобы суперглавных". Вот это и заставляет новичков пихать его куда-попало. Они думают, что без наследования их код будет не достаточно крутой. И в результате пытаются пришить к нему наследование, лишь бы было.
Зачем вообще пихать метод Swim() в родительский класс, если он не является общим для всех наследников? По-моему, вы чего-то не понимаете в ООП.
Проблемы с ООП возникают у тех, кто именно так его использует. Поэтому для демонстрации "как делать не нужно" самое то
@@leeroyjenkns5182 Ты описываешь идеальный мир которого не существует.в реальных проектах почти всегда такая хуйня как на видео и ен важно банк это или стартап , нет времени постоянно все рефакторить.
@@ivansidorov5 А если изначально так не делать?)
@@Nikita-hu9bk ты никогда не писал большой проект где участвуют больше 3 человек?) и длится больше года. Изначально можно сделать хорошо при 2 условиях: 1) ТЗ не меняется 2) Дают время на рефакторинг . Я перевидал много проектов, везде полная дичь с ООП и куча костылей для него. нет говна только в тех проектах, которые мелкие и пишутся 1 человеком, а еще в тех где писал все ты) потому что там там, как привык ты)
Да затем, чтобы видос заснять. А про что тогда снимать??
Полезно, понятно, быстро и с музыкой! Однозначно лайк и спасибо! 😘
3 часа ночи, я же даже не программист...
Становись
А в целом ты смог понять о чем вообще идёт речь? 😄
@@paztwel я не понял, почему метод swim нельзя засунуть сразу в класс Пингвин? Чтобы не повторять его если появится класс акула например?
Норм жизнь тратишь
@@equim7363 да
Инкапсуляция тоже была бы мусором, если бы не сокрытие данных
Кажется, в одном из роликов говорилось, что инкапсуляция, это не тоже, что и сокрытие
@@user-rr5fx9zm1s По крайней мере не сокрытие данных точно. Инкапсуляция - сокрытие реализации за интерфейсом, и нужно для того чтобы в реализацию можно было вносить изменения в ходе поддержки программы (баг пофиксить, оптимизировать что-нибудь. С такими целями блин сделаны все нововведения в программировании после появления символьных имён для процессорных инструкций - упрощение поддержки и улучшения кода).
Брат беги, не оглядывайся =)))
@@user-rr5fx9zm1s сокрытие подразумевает не только сокрытие данные, но и сокрытие реализации.
что мешает делать мне все публичными?
Слишком идеальный контент. Пишу комментарий, чтобы было понятно, что вы делаете лучшие туториалы на свете. И великолепным голосом
дроп в 8 утра в рабочий день, кайф))
Чтобы было чем на работе заняться..
щас мужики всем отделом посмотрят и будут холиварить весь день! А если там ещё адепты разных языков есть, то холиварить будут до понедельника.
@@paul_wiggin ахахаххахаха
Классно! Помню как в рамках изучения JS писал терариум, так добавление каких-либо возможностей "жителям" иногда приводило к хорошим проблемам. А вообще мне понравилось)
Спасибо за критические ролики! И своеобразного юмора над всем тем балаганом что есть в кодинге. Долго время не мог подступиться к ооп и паттернам и прочим техникам, казалось чем то сверх сложным и требующим много времени для разбирательств, но когда узнал о проблемах в ооп и понял за что его макают лицом в грязь, вообщем говоря обратную сторону медали, то пришло озарение и понимание простых вещей, для чего все эти паттерны придуманы и какую большую проблему в проектировании с помощью кода они решают. Так же наконец то прочитал книгу чистый код и достаточно легко переварил все в ней сказано и офигел на сколько же она простая и это только верхушка айсберга тех вещей с помощью которых можно по-человечески выполнять свою работу))
Этот видос явно лучше видоса про стратегию, исправляешься, потому лайк.
Новый год давно наступил, а автора отпускать похоже не собирается.
Взять хуево составленный контракт (а куча абстрактных методов и есть контракт, а не наследование) назвать это наследованием и предложить решение, которое к полиморфизму отношения не имеет от слова "совсем": все животные будут реализовывать ходьбу, плавние и т.п. одинаковым способом?
БРАВО, ГЕНИАЛЬНО, ШЕДЕВР. Еще и на серьезных щщах это все рассказывать...
Видимо смотрят это реально только "маслята", коли такое соотношение лайков/дизов
Эм, представьте что я тупой ребёнок, почему одним способом?
Спасибо, только сегодня сделал дз по массива и теперь в ООП погрузился, нихрена не ясно но очень интересно)
Отличный ролик👍🤗
По-моему, если не следовать несуществующему принципу ООП "объявления всех методов должны быть только в базовых классах", то в примере будет всё ок с наследованием, не?
По-моему если следовать существующему принципу ООП, то мы должны в конечном счете работать с абстракциями, не?
@@ExtremeCode конкретный класс тоже описывает абстракцию. Над всеми его экземплярами
@@ExtremeCode но, вообще, не разу не видел понимание принципа "абстракция" из ООП как необходимость наличия слова "abstract" перед каждым методом. Обычно это про то, что мы должны создать хорошую абстракцию, которая скрывает детали реализации. Про создание минимального интерфейса, который легко использовать. Можете посмотреть у Крэга Лармена в главе про GRASP про принцип "high cohesion / low coupling", например
@@KirillTerekhov абстракция, это не абстрактные классы, весь смысл ООП заключен в полиморфизме и апкасте к "общим" типам, вместо работы с "конкретными" типами, именно из-за этого весь сыр бор в статической типизации, т.к. это единственный способ работать с группой схожих объектов без конкретизации что именно это за объект, хотя они могут иметь различные реализации.
Для того чтобы достичь этого - существует как наследование, так и реализация интерфейсов. В видео была показана конкретная проблема которая возникает при использовании именно наследования, и различные варианты решения этой проблемы.
@@ExtremeCode как я уже говорил, конкретный класс - это тоже абстракция. Достаточная для решения проблемы из видео. Проблема с наследованием там в том, что вы его применили неправильно. В нарушение принципа подстановки Лисков, например
Слоны, ска, ПЛАВАЮТ!
А если серьезно, то это пример плохого приложения наследования. Ибо если бы в биологии так же решили классифицировать животных тупо по умениям они бы тоже быстро за.бались, и ничего бы у них толкового не вышло. Соответственно, проблема не в системе иерархического наследования, а в её правильном применении.
Точно. Здесь проблема не в том, что "наследование говно", а в том как оно используется. Добавление swim в класс animal соответствует утверждению, "все животные плавают". В данном случае, это неверное определение уровня абстракции, на котором должен быть размещен метод. Чем выше уровень абстракции, тем более общие части в нем должны находиться. Биологическая классификация живых организмов хороший пример развития такой классификации от общего к частному. Более прикладной уровень - возьмите System.Object, там будут только самые общие методы, которыми должны обладать все произвольные объекты, чтобы среда нормально работала. Так-то при желании или в угоду хайпу можно извратить любую идею.
AlexXx, я говорю как относительно биолог:вы ахуеть как правы
Тоже с вами парняги абсолютно согласен!!! Ребята с канала просто хайпануть захотели, а новечки в профессии решат после этого видео забить на наследование)
@@evgeny_5891 но в видео было сказано что наследование нужно, но использовать стоит аккуратно (если я ничего не забыл)
@@user-bu1ou5vd5y В целом мне видос очень понравился, лай однозначно! Автор ближе к концу ролика начинает говорить, о том что наследование "допустимая" штука, но нужно использовать ее с умом, как по мне, нужно это было-бы сказать в начале, но я не автор.) В целом классный канал, и ребята поднимают правильные темы, желаю им удачи!
Час назад вернулся с днюхи, смотрю в универе и получаю полезную инфу 😂
Наоборот, это очень вредное видео, в котором автор показал как он не понял как правильно использовать ООП.
Прекрасная подача
Сами создаем проблемы -- сами героически преодолеваем.
1. Менять базовый класс можно только общей логикой. Уже ниже писали что добавлять метод, который будет вызыватся только в одном единственном наследнике -- такое себе.
2. Ничто не запрещает обьединить подход с интерфейсами и абстрактным классом. И тогда можешь внедрять хоть утконосов, которые вообще ни от кого не наследованы в реализации.
3. Без конкретики как это потом применять все это бесмысленный набор символов.
Итого полезного из видео: нехуй пихать в базовый класс всю логику, а потом удивлятся "че за порожняк".
странно как то написал, отвечу так, как понял.
1. Так вроде ты описал то, что в начале и объяснялось - проблема. Но! В ходе расширения наследников много будет.
2. Не совсем понял, к чему утконосы до объединения подходов с интерфейсами и абстрактными классами. Если можно, по проще объясни.
3. А ручками никто не запрещал потом это потрогать (попрактиковаться).
@@devil_of_war Так, я затер нахер всю ту простыню, что хотел выдать, и постарасю максимально упаковать "меседж":
Без явного понимания нахер нам эти классы и как их потом использовать, любой довод можно как подтвердить, так и опровергнуть. У нас нет дилемы "яйцо - курица", вначале ВСЕГДА НУЖНО ТЗ.
- если программа подразумевает что мы вытягиваем из коробки животное, и заставляем его подать голос, наследование вполне проканывает.
- если программа подразумевает что вытянутое животное нужно будет заставить сделать N-действий, и этот список "динамический", то наследование действительно больше создаст проблем, чем решит. Возможно часть обьектов и будут обьедены общей реализацией, но более надежно вынести все это за интерфейс.
И так можно придумывать до бесконечности.
@@Oleksandp вот теперь намного яснее. Даже нечего сказать в противовес. Ведь реально ТЗ разное, и программы разные.
даже если так, композиция + интерфейсы выглядят красивей и меньше кода пишется (лучше, чем у каждого наследника писать новый метод, а абсрактный класс будет содержать пару полей)
@@Oleksandp когда много похожих зверушек с маленькими отличиями, то лучше наследование. Но если же у нас целый зоопарк и общие у зверушек только пара свойсв, удобней будет указанный в видео способ.
Доброго времени суток.
Осветите пожалуйста темы с подключением GitHub, Azure и прочим. Плюсы, минусы, отличия. Как подключить для чего нужно.
И еще хотелось бы увидеть программирование с использование баз данных, так ка большинство приложений клиент-серверные.
Заранее спасибо.
This is your daily dose of Recommendation
.
дождались!
Exceptions не нужны - а вот это уже интересненько! Давай жги!
Классненько!
В последнем примере с Trait - зачем все так сложно? Почему нельзя просто сделать два интерфейса ICanWalk и ICanSwim, и затем написать класс расширение для каждого из них?
Типа
public static void Walk(this ICanWalk canWalk){...}
?
Вот что значит хороший ролик. Я вообще не кодер, не понимаю ничего из сказанного, но смотреть интересно.
Мне кажется не плохой вариант, когда мы создаем пустые емкости через абстрактный класс Trait и наполняем их расширенными методами статического класса.
Extrimiсты по вашему мнению какой лучший вариант? C#8.0 позволяет реализовывать методы в интерфейсе. В чем плюсы и минусы.?
Спасибо! Схема гибкая бесспорно, но в защиту наследования хочется спрлсить - возможно не в парадигме дело, а в детализации архитектуры? Ведь если подумать перед тем как писать код можно же превентировать будущие изменения добавив пару промежуточных классов? Или это бред? У вас просто в видео так обставленно, что наследование изначально неумёхи используют)
Угарнул на моменте трейтов и PHP программистов)
лайк за музло, контент тоже годный
Это не проблемы ООП, это проблемы кодеров, которые не могут в ООП
Если прогер говорит "Это проблемы кодеров которые не умеют в ООП", то этот прогер не умеет в ООП.
И слава богу что таким криворукам теперь вяжут руки в любом современном ЯП, чтобы они свое "мега ООП" не несли в массы.
@@vBasterv чел...
Ребят. Давайте жить дружно. Вы же понимаете, что ООП инструмент ограничений - метод борьбы одного программиста с коллегами. Когда над проектом работают сотри программистов, такие архитектурные решения - скелет проекта. Нужный чтобы весь код не превратился в мусор, который тяжело поддерживать. ООП это уже давно не пушистый зверёк, который создан для того, чтобы тебе было удобно)
@@sergeifomin3225 именно
Чел?
наконец то снова шарп)
Прикольно. Не знал, что так можно.
Не ну за хардбас только лукаса можно влипить\
Здорово раскрываете суть паттерна(нов), все понятно. Остается попрактиковать закрепив результат. Кстати в книге «Банды четырех» этот паттерн нифига не понятен, с их примером создания текст.редактора.
Лучше уж просто сооздать класс Animal, и отдельно интефрейсы типа ISwimmer : where T , IWalker : where T ,
вроде так лучше. Возможно ошибаюсь) Я не так давно программирую
Лукас, заслуженно.
Очень люблю ваш канал.
Не хотите сделать видео на тему, как начать участвовать в опенсорс проектах, и контрибьютить на гитхабе?
А так же как участвовать в хакатонах, и надо ли оно вообще. С каким опытом итд.
Лайк за нормальную музыку, браток)
Привет, подскажи вкратце каких вещей хватит для фронтенда кроме html и css конечно
Ребят, а как вы доступ к полям через свою стратегию получать то будете?
А легко, прокидывать также. Лучше каждый сеттер/геттер оформить отдельным экшэном :D
Умный кто-то,
Может видео, как делать большие проекты типа paint, word? С чего начинать, какая должна быть структура чтобы было ооп и красиво
а ты маленькие уже умеешь делать?
@@Andrey-il8rh калькулятор-шифратор какой-нибудь легко, с чуть ооп
@@sergey1658 такие проекты как word явно не в одно рыло делаются, многое ещё зависит от языка на котором предстоит писать проект. ООП это не панацея и не показатель крутости - это инструмент для решения конкретных проблем которые для начала нужно осознать, не нужно городить в проекте ООП ради оценки подруги маминой сестры
Аффигенно! Спасибо за хорошие примеры и аргументацию )
именно в словах типа "я запихну все в кучу, чтобы не усложнять код" и кроется вся суть :D
Подскажите нубу что это за волшебная кнопочка которая совершает автозаполнение?
Как услышал хардбасс. Сразу лайк подписка колокольчик
Пили про исключения!)
Монады лучше
сейчас бы прийти в офис с колоночькой и врубить эту прекрасную музыку и кодить... *кайф*
Давай по чаще видосы, очень годно 👍
ВЫЗЫВАЮ ПОЯСНИТЕЛЬНУЮ БРИГАДУ.
А на. уя было в первом примере добавлять столько сущностей, если можно было просто добавить виртуальную функцию, переопредедив ее в гребаном пингвине?
Вообще не ебу, что происходит на экране, но смотрю все видосы. 👍
Если не множественное, тогда может селективное наследование? В описании производного класса перечисляем что наследуем, а что отбрасываем?
Поставил лайк под видео, видос хороший, но сейчас меня зачмырят...
Как же я рад что я учил только Java))) Там как бы с этим делом реально по проще.
7:30 а чтобы не делать приведение типа, нельзя вместо var базовый тип укзать?
Жду видео про исключения
а почему нельзя обращаться просто penguin.Swim и penguin.Walk, в примере с дефолтными рализациями в интерфейсе?
Там класс Penguin имплементирует 2 интерфейса (IWalker и ISwimmer), которые уже имеют реализацию.
Тема конфронтации объектно-ориентированного кода и кода процедурного все же не несколько однозначная. Например, при ооп легко добавлять новые объекты, а в процедурном программировании легче расширить функции объектов.
них...чего не понятно, но ооочень интересно
Может сделаете видос про функциАнальное программирование? Думаю малаяткам(мне) будет интересно послушать байки про императивные и декларативые стили, карелизация там...
Лукааааааааас!
Почему то во многих книгах, много где вообще в интернете наследование подается как один из самых популярных, часто используемых и нужных штук в ООП. На деле же это механизм, который нужно использовать с умом и не пихать везде где тока можно
Наследование в подавляющем большинстве случаев необходимо только разве что при использовании различных фреймворков и api, где дизайн классов специально заточен для того, чтобы от них наследовались. А если реюзать свой код, то интерфейсы, композиция и utility-методы)
Очень интересное решение. А в шарпах нет миксинов?
И чем интерфейс с реализацией отличаться от множественного наследования?
Да ничем, интерфейс по сути все тот же класс, просто в шарпе нельзя во множественное наследование, зато можно подключать интерфейсы, т.к. в шарпе это отдельная синтаксическая структура, которую для похожих случаев и сделали отдельной.
А разве следование "принципу единой ответственности" не должно на корню присечь подобные ситуации?
Спасибо
Но теперь для создания пингвина надо изучить в коде 3-4 сущности вместо 1. А каждая из них может так же конструироваться из 3-4 сущностей. Создание объектов в такой архитектуре усложняется геометрически.
Проблемы наследования тут не показаны. Когда ты добавляешь метод в класс Animal, ты должен сразу прикинуть является ли данное свойство неотъемлемой частью именно всех животных, или только отдельных видов таковых. Если нет, то пользуешься чехардой из наследованных классов (вплоть до выделения всех царств, подцарств и т.д. из биологической иерархии в пределах требования программы). Если классов слишком много, пользуешь стратегию/мост/декоратор, например. Ну а в целом, да, есть принцип "композиция лучше наследования", например из-за того, что композиция динамична, а наследование статично.
Не мог вникнуть в код , потому что музон качает xD
дык, open/closed principle! Только ситхи вносят изменения в классы
open/closed сложно представить при грубом наследовании
Хуык
@@vinik_tfo, наследование не нарушает его, каким бы грубым оно не было, только бы Лисков оставалась удовлетворённой)
Берешь абстрактный класс, делаешь у него метод virtual. И получается тот же интерфейс с дефолтной реализацией. Для меня добавление этой "фичи" очень сомнительная идея... которая как раз порождает множественное наследование
Что за музыка, когда он пишет код?
Найс процитировал первую главу про Стратегию из книжки по шаблонам проектирования.
О. Как раз исключения изучаю. Рассказывай.
ок, если я получаю список животных и они в начале должны говорить, а потом ходить, какой интерфейс мне указывать?
Сам по себе интерфейс с точки зрения ООП разве ни есть наследование? Например, в случае с++ вообще нет интерфейсов как языковой конструкции, но можно создавать абстрактные методы, при этом есть множественное наследование, в итоге можно через наследование реализовать то что ты показал через интерфейсы.
Я правильно понял, что для обхода проблем с наследованием пришлось реализовать typeclasses из Хацкеля?
Ничего не понятно, но очень интересно.
Животное может выполнять массу действий. Если добавлять на каждое действие по свойству IAction, то класс разбухнет. Как организовать возможные действия для животного?
да не воспринимать это как догму. Нафигачить действия кушать/спать в абстрактном, редкие действия или через общего наследника, или предложенным способом, или вообще не плодить интерфейсов, если действие уникально
все же нужно расматривать конкретного слона, а не абстрактного в вакуме. очень, ОЧЕНЬ много зависит от того что изачем делаешь.
Если интерфейсам разрешено содержать дефолтную реализацию, тогда чем это отличается от множественного наследования?
Лайк. Но, 4:00 интерфейс IAnimal это моЩЩно ))
Абстрактные методы не прокатят?
музыкальное сопровождение шикарно
Ничего не понял, но крайне интересно
Гайс, что стоило бы учить после Шилдта (c#), есть вопрос куда идти, в десктоп, или веб?
Поговаривают, что декстоп медленно стремится к вымиранию. А веб универсален (в плане платформ) и более востребован сейчас.
@@user-nw1jq3ie9t а как думаешь, стоит начинать учить asp .net или уже с asp .core начинать?
@@NameSurname-zm7gl иди сразу в ASP.NET Core, не промахнешься. Стильно, модно, молодежно
Я весь урок качался под трек 😂
Ну если при проектировании начинаешь понимать, что интерфейс будет расширяться намного быстрее чем сущности, то visitor можно прикрутить. Для меня, как для плюсовика, все что вы показали то же наследование, ибо интерфейсов как сущностей у нас нет. Вопрос лишь в том, какую иерархию строить с учетом будущих изменений. И достаточно часто очевидно какие части будут расширяться в будущем быстрее, а какие медленнее.
Лукас поставлен! Где видос, о том, как правильно писать код без exception? Реально говнопроект получается, весь в этих exceprion!)
Может ли класс "Продавец рельсов" наследовать функциональность от класса "Продавец планов"?
План это последовательность действий или ганж?)
Слоны как раз отлично умеют плавать.
Ой, как же я тебя обожаю, если честно
Я начал понимать для чего нужны интерфейсы, но я еще не дочитался до них в книжках.
Где видос про исключения?
Муза на фоне топчик
Может я чего-то не понимаю, но в java, например, можно создать готовый класс с методами которые уже что-то делают и когда какой-то класс от него наследуется, то этот класс может переопределить готовые методы класса родители без переписок abstract
Вот хороший вопрос. Когда плюсы изучал, тоже так делал
Слоны по дефолту не умеют плавать. Если ты напишешь реализацию для плавания по умолчанию в классе, и наследуешь от этого класса слона, то метод swim все равно унаследуется, и получится что слоны умеют плавать.
@@user-ws5ns3sl1q в видео говориться что уже после добавляется метод свим. Так вот, в джаве пишешь в класс пингвин метод свим и все. В класс родительский не надо его пихать. Я ещё тот маслёнок... только учусь. Может чего не понимаю еще
@@qaserus1226 Тогда тебе придется весь код этого метода продублировать для каждого животного, которое умеет плавать. Написать метод swim для пингвина, собаки, кошки и.тд, причем весь этот код будет одинаковым (или почти одинаковым). А дублирование это плохо
@@user-ws5ns3sl1q ну если этот метод нужен многим классам то да)))
English viewers who got this recommended can take refuge here🙏
Слоны замечательно плавают!