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

В этом видео мы узнаем какие проблемы несет в себе принцип наследования из ООП и как эти проблемы можно решить при помощи стратегии, интерфейсов или методов расширения
Исходники из видео
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/?...

[@illidanstormrage8022]

Пингвин должен говорить не "ХЗ", а "Линукс"

[@Firefly_3161]

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

[@bsunjar]

"fuck nvidia"(c)

[@YY-zw2ec]

GNU

[@AlexP-jc7rz]

А в чем разница?

[@mhhit]

представь себе пингвина у которого звуки хз XD

[@user-we9ei6ks4d]

4:19 Как же хорошо, что в C# нет множественного наследования 4:20 ...А теперь в C# 8 можно пилить дефолтную реализацию интерфейса

[@ivangor1997]

@@user-w32eiJkNlIn9a2nRq6n Они становятся абстрактными классами просто с возможностью множественного наследования.

[@MacIn173]

@@user-w32eiJkNlIn9a2nRq6n так и просто полностью абстрактный класс остается контрактом, который нельзя сам по себе инстанцировать.

[@voltamperoff]

@@user-w32eiJkNlIn9a2nRq6n "Он может содержать в себе кучу базовой логики, в отличие от интерфейса." (с) Но начиная с 8-й версии, это отличие полностью исчезает.

[@bonumsignum7017]

@@voltamperoff Глупость, в интерфейс ты не добавишь поле. Это вся суть интерфейса, ты не можешь задать стейт классу.

[@khodis2002]

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

[@user-xm3ue3nc5x]

Когда пришёл узнать о недостатках наследования, но вместо этого начал танцевать ХАРДБАСС!

[@evgeniym29]

Слоны умеют плавать :) В остальном, как обычно, красава :)

[@dashandr1]

Ты слон

[@evgeniym29]

@@dashandr1 И кто это говорит, жирный троль? :)

[@dashandr1]

@@evgeniym29 азарной слон)

[@replace22yu40]

Кстати да, они хорошо плавают

[@yevheniidolmatov3170]

Кликбейт же

[@user-vm9ye6qy9h]

Проблемы не у наследования в ООП, а у того, кто неправильно его применяет. Если вы забиваете микроскопом гвозди, то ни гвозди, ни микроскоп в этом не виноваты.

[@Rumpelstilzchen_M]

так он вроде именно про это и говорит.

[@addressmodel2121]

Илья Иванов , наследование - это не совсем удачный термин для этого механизма. Именно поэтому это самое "наследование" и применяют неправильно многие люди. Если термин "наследование" заменить на термин "расширение функциональности", то название становится рекомендацией к применению этого механизма.

[@VeryWorried]

ога, архитектурно-структурные подходы.

[@vzlomer1000]

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

[@nuclearcoil]

Но почему микроскоп обычно применяют нормально, а наследование пихают хер знает куда? Кроме того, применений у этого "микроскопа" не так уж и много между прочим. А апологеты ООП выставляют его как "основопологающий принцип", один "трёх якобы суперглавных". Вот это и заставляет новичков пихать его куда-попало. Они думают, что без наследования их код будет не достаточно крутой. И в результате пытаются пришить к нему наследование, лишь бы было.

[@0vdmk]

3 часа ночи, я же даже не программист...

[@vip51000]

Становись

[@paztwel]

А в целом ты смог понять о чем вообще идёт речь? 😄

[@equim7363]

@@paztwel я не понял, почему метод swim нельзя засунуть сразу в класс Пингвин? Чтобы не повторять его если появится класс акула например?

[@user-vt1qw1zj9w]

Норм жизнь тратишь

[@azamatkurmangaliyev6010]

@@equim7363 да

[@Max-np7om]

Инкапсуляция тоже была бы мусором, если бы не сокрытие данных

[@user-rr5fx9zm1s]

Кажется, в одном из роликов говорилось, что инкапсуляция, это не тоже, что и сокрытие

[@bearpro]

@@user-rr5fx9zm1s По крайней мере не сокрытие данных точно. Инкапсуляция - сокрытие реализации за интерфейсом, и нужно для того чтобы в реализацию можно было вносить изменения в ходе поддержки программы (баг пофиксить, оптимизировать что-нибудь. С такими целями блин сделаны все нововведения в программировании после появления символьных имён для процессорных инструкций - упрощение поддержки и улучшения кода).

[@tankowot]

Брат беги, не оглядывайся =)))

[@nuclearcoil]

@@user-rr5fx9zm1s сокрытие подразумевает не только сокрытие данные, но и сокрытие реализации.

[@kek2961]

что мешает делать мне все публичными?

[@soulwind7577]

Сидишь такой, ура наконец то начал понимать ООП, спасибо видосу теперь понятно, что ни хя не понятно XD

[@angelotrriton9940]

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

[@antaki93]

Зачем вообще пихать метод Swim() в родительский класс, если он не является общим для всех наследников? По-моему, вы чего-то не понимаете в ООП.

[@leeroyjenkns5182]

Проблемы с ООП возникают у тех, кто именно так его использует. Поэтому для демонстрации "как делать не нужно" самое то

[@ivansidorov5]

@@leeroyjenkns5182 Ты описываешь идеальный мир которого не существует.в реальных проектах почти всегда такая хуйня как на видео и ен важно банк это или стартап , нет времени постоянно все рефакторить.

[@Nikita-hu9bk]

@@ivansidorov5 А если изначально так не делать?)

[@ivansidorov5]

@@Nikita-hu9bk ты никогда не писал большой проект где участвуют больше 3 человек?) и длится больше года. Изначально можно сделать хорошо при 2 условиях: 1) ТЗ не меняется 2) Дают время на рефакторинг . Я перевидал много проектов, везде полная дичь с ООП и куча костылей для него. нет говна только в тех проектах, которые мелкие и пишутся 1 человеком, а еще в тех где писал все ты) потому что там там, как привык ты)

[@AlexAlex-ms3bg]

Да затем, чтобы видос заснять. А про что тогда снимать??

[@Temp1archik]

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

[@alexxx4434]

Слоны, ска, ПЛАВАЮТ! А если серьезно, то это пример плохого приложения наследования. Ибо если бы в биологии так же решили классифицировать животных тупо по умениям они бы тоже быстро за.бались, и ничего бы у них толкового не вышло. Соответственно, проблема не в системе иерархического наследования, а в её правильном применении.

[@dmitriiplotnikov1137]

Точно. Здесь проблема не в том, что "наследование говно", а в том как оно используется. Добавление swim в класс animal соответствует утверждению, "все животные плавают". В данном случае, это неверное определение уровня абстракции, на котором должен быть размещен метод. Чем выше уровень абстракции, тем более общие части в нем должны находиться. Биологическая классификация живых организмов хороший пример развития такой классификации от общего к частному. Более прикладной уровень - возьмите System.Object, там будут только самые общие методы, которыми должны обладать все произвольные объекты, чтобы среда нормально работала. Так-то при желании или в угоду хайпу можно извратить любую идею.

[@shadowinthemirror2055]

AlexXx, я говорю как относительно биолог:вы ахуеть как правы

[@evgeny_5891]

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

[@user-bu1ou5vd5y]

@@evgeny_5891 но в видео было сказано что наследование нужно, но использовать стоит аккуратно (если я ничего не забыл)

[@evgeny_5891]

@@user-bu1ou5vd5y В целом мне видос очень понравился, лай однозначно! Автор ближе к концу ролика начинает говорить, о том что наследование "допустимая" штука, но нужно использовать ее с умом, как по мне, нужно это было-бы сказать в начале, но я не автор.) В целом классный канал, и ребята поднимают правильные темы, желаю им удачи!

[@donqhomo8810]

дроп в 8 утра в рабочий день, кайф))

[@paul_wiggin]

Чтобы было чем на работе заняться.. щас мужики всем отделом посмотрят и будут холиварить весь день! А если там ещё адепты разных языков есть, то холиварить будут до понедельника.

[@purplep3466]

@@paul_wiggin ахахаххахаха

[@ajajapenoflex]

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

[@JasterSalli]

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

[@EshkinKot1980]

Этот видос явно лучше видоса про стратегию, исправляешься, потому лайк.

[@user-hh7cy8tr6h]

Спасибо, только сегодня сделал дз по массива и теперь в ООП погрузился, нихрена не ясно но очень интересно)

[@Oleksandp]

Сами создаем проблемы -- сами героически преодолеваем. 1. Менять базовый класс можно только общей логикой. Уже ниже писали что добавлять метод, который будет вызыватся только в одном единственном наследнике -- такое себе. 2. Ничто не запрещает обьединить подход с интерфейсами и абстрактным классом. И тогда можешь внедрять хоть утконосов, которые вообще ни от кого не наследованы в реализации. 3. Без конкретики как это потом применять все это бесмысленный набор символов. Итого полезного из видео: нехуй пихать в базовый класс всю логику, а потом удивлятся "че за порожняк".

[@devil_of_war]

странно как то написал, отвечу так, как понял. 1. Так вроде ты описал то, что в начале и объяснялось - проблема. Но! В ходе расширения наследников много будет. 2. Не совсем понял, к чему утконосы до объединения подходов с интерфейсами и абстрактными классами. Если можно, по проще объясни. 3. А ручками никто не запрещал потом это потрогать (попрактиковаться).

[@Oleksandp]

@@devil_of_war Так, я затер нахер всю ту простыню, что хотел выдать, и постарасю максимально упаковать "меседж": Без явного понимания нахер нам эти классы и как их потом использовать, любой довод можно как подтвердить, так и опровергнуть. У нас нет дилемы "яйцо - курица", вначале ВСЕГДА НУЖНО ТЗ. - если программа подразумевает что мы вытягиваем из коробки животное, и заставляем его подать голос, наследование вполне проканывает. - если программа подразумевает что вытянутое животное нужно будет заставить сделать N-действий, и этот список "динамический", то наследование действительно больше создаст проблем, чем решит. Возможно часть обьектов и будут обьедены общей реализацией, но более надежно вынести все это за интерфейс. И так можно придумывать до бесконечности.

[@devil_of_war]

@@Oleksandp вот теперь намного яснее. Даже нечего сказать в противовес. Ведь реально ТЗ разное, и программы разные.

[@dreawmy2912]

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

[@dreawmy2912]

@@Oleksandp когда много похожих зверушек с маленькими отличиями, то лучше наследование. Но если же у нас целый зоопарк и общие у зверушек только пара свойсв, удобней будет указанный в видео способ.

[@KirillTerekhov]

По-моему, если не следовать несуществующему принципу ООП "объявления всех методов должны быть только в базовых классах", то в примере будет всё ок с наследованием, не?

[@ExtremeCode]

По-моему если следовать существующему принципу ООП, то мы должны в конечном счете работать с абстракциями, не?

[@KirillTerekhov]

@@ExtremeCode конкретный класс тоже описывает абстракцию. Над всеми его экземплярами

[@KirillTerekhov]

@@ExtremeCode но, вообще, не разу не видел понимание принципа "абстракция" из ООП как необходимость наличия слова "abstract" перед каждым методом. Обычно это про то, что мы должны создать хорошую абстракцию, которая скрывает детали реализации. Про создание минимального интерфейса, который легко использовать. Можете посмотреть у Крэга Лармена в главе про GRASP про принцип "high cohesion / low coupling", например

[@ExtremeCode]

@@KirillTerekhov абстракция, это не абстрактные классы, весь смысл ООП заключен в полиморфизме и апкасте к "общим" типам, вместо работы с "конкретными" типами, именно из-за этого весь сыр бор в статической типизации, т.к. это единственный способ работать с группой схожих объектов без конкретизации что именно это за объект, хотя они могут иметь различные реализации. Для того чтобы достичь этого - существует как наследование, так и реализация интерфейсов. В видео была показана конкретная проблема которая возникает при использовании именно наследования, и различные варианты решения этой проблемы.

[@KirillTerekhov]

@@ExtremeCode как я уже говорил, конкретный класс - это тоже абстракция. Достаточная для решения проблемы из видео. Проблема с наследованием там в том, что вы его применили неправильно. В нарушение принципа подстановки Лисков, например

[@star_lord1911]

Час назад вернулся с днюхи, смотрю в универе и получаю полезную инфу 😂

[@DicrTarasov]

Наоборот, это очень вредное видео, в котором автор показал как он не понял как правильно использовать ООП.

[@FoRGeish]

Новый год давно наступил, а автора отпускать похоже не собирается. Взять хуево составленный контракт (а куча абстрактных методов и есть контракт, а не наследование) назвать это наследованием и предложить решение, которое к полиморфизму отношения не имеет от слова "совсем": все животные будут реализовывать ходьбу, плавние и т.п. одинаковым способом? БРАВО, ГЕНИАЛЬНО, ШЕДЕВР. Еще и на серьезных щщах это все рассказывать... Видимо смотрят это реально только "маслята", коли такое соотношение лайков/дизов

[@ivankramarenko]

Эм, представьте что я тупой ребёнок, почему одним способом?

[@NikolayMishin]

Отличный ролик👍🤗

[@victor_bozhok]

Прекрасная подача

[@Rostik-pk1ik]

дождались!

[@vilkillian]

Это не проблемы ООП, это проблемы кодеров, которые не могут в ООП

[@vBasterv]

Если прогер говорит "Это проблемы кодеров которые не умеют в ООП", то этот прогер не умеет в ООП. И слава богу что таким криворукам теперь вяжут руки в любом современном ЯП, чтобы они свое "мега ООП" не несли в массы.

[@vilkillian]

@@vBasterv чел...

[@sergeifomin3225]

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

[@vilkillian]

@@sergeifomin3225 именно

[@easystm6865]

Чел?

[@Retroromancer]

Вот что значит хороший ролик. Я вообще не кодер, не понимаю ничего из сказанного, но смотреть интересно.

[@user-xg8hw3iz6e]

Доброго времени суток. Осветите пожалуйста темы с подключением GitHub, Azure и прочим. Плюсы, минусы, отличия. Как подключить для чего нужно. И еще хотелось бы увидеть программирование с использование баз данных, так ка большинство приложений клиент-серверные. Заранее спасибо.

[@xakkep9000]

Классненько!

[@razor23Ukraine]

Exceptions не нужны - а вот это уже интересненько! Давай жги!

[@JOELwindows7]

This is your daily dose of Recommendation .

[@dimzinnatov7242]

Лучше уж просто сооздать класс Animal, и отдельно интефрейсы типа ISwimmer : where T , IWalker : where T , вроде так лучше. Возможно ошибаюсь) Я не так давно программирую

[@evgenasd8892]

Здорово раскрываете суть паттерна(нов), все понятно. Остается попрактиковать закрепив результат. Кстати в книге «Банды четырех» этот паттерн нифига не понятен, с их примером создания текст.редактора.

[@sergey1658]

Умный кто-то, Может видео, как делать большие проекты типа paint, word? С чего начинать, какая должна быть структура чтобы было ооп и красиво

[@Andrey-il8rh]

а ты маленькие уже умеешь делать?

[@sergey1658]

@@Andrey-il8rh калькулятор-шифратор какой-нибудь легко, с чуть ооп

[@Andrey-il8rh]

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

[@user-ml6im5rs1e]

Угарнул на моменте трейтов и PHP программистов)

[@user-up7lg8ol9c]

именно в словах типа "я запихну все в кучу, чтобы не усложнять код" и кроется вся суть :D

[@PrefixKrema]

Очень люблю ваш канал. Не хотите сделать видео на тему, как начать участвовать в опенсорс проектах, и контрибьютить на гитхабе? А так же как участвовать в хакатонах, и надо ли оно вообще. С каким опытом итд.

[@user-sj2ky8ol1f]

Спасибо! Схема гибкая бесспорно, но в защиту наследования хочется спрлсить - возможно не в парадигме дело, а в детализации архитектуры? Ведь если подумать перед тем как писать код можно же превентировать будущие изменения добавив пару промежуточных классов? Или это бред? У вас просто в видео так обставленно, что наследование изначально неумёхи используют)

[@Rostik-pk1ik]

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

[@lesnoy_leo]

Не ну за хардбас только лукаса можно влипить\

[@unset1302]

Вообще не ебу, что происходит на экране, но смотрю все видосы. 👍

[@sergiysych7760]

лайк за музло, контент тоже годный

[@algol36]

В последнем примере с Trait - зачем все так сложно? Почему нельзя просто сделать два интерфейса ICanWalk и ICanSwim, и затем написать класс расширение для каждого из них? Типа public static void Walk(this ICanWalk canWalk){...} ?

[@SWdarkWind]

наконец то снова шарп)

[@vladimir2358]

дык, open/closed principle! Только ситхи вносят изменения в классы

[@vinik_tfo]

open/closed сложно представить при грубом наследовании

[@pangutovskiy1659]

Хуык

[@vladimir2358]

@@vinik_tfo, наследование не нарушает его, каким бы грубым оно не было, только бы Лисков оставалась удовлетворённой)

[@it-6411]

Наследование в подавляющем большинстве случаев необходимо только разве что при использовании различных фреймворков и api, где дизайн классов специально заточен для того, чтобы от них наследовались. А если реюзать свой код, то интерфейсы, композиция и utility-методы)

[@alonev1875]

Мне кажется не плохой вариант, когда мы создаем пустые емкости через абстрактный класс Trait и наполняем их расширенными методами статического класса. Extrimiсты по вашему мнению какой лучший вариант? C#8.0 позволяет реализовывать методы в интерфейсе. В чем плюсы и минусы.?

[@demantools]

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

[@guxershmeg]

Но теперь для создания пингвина надо изучить в коде 3-4 сущности вместо 1. А каждая из них может так же конструироваться из 3-4 сущностей. Создание объектов в такой архитектуре усложняется геометрически.

[@KulaGGin]

Прикольно. Не знал, что так можно.

[@denismaltsev9573]

Лайк за нормальную музыку, браток)

[@Crazmuss]

Ничего не понятно, но очень интересно.

[@vladyslavtymofieiev4213]

Тема конфронтации объектно-ориентированного кода и кода процедурного все же не несколько однозначная. Например, при ооп легко добавлять новые объекты, а в процедурном программировании легче расширить функции объектов.

[@konstantine_2761]

ВЫЗЫВАЮ ПОЯСНИТЕЛЬНУЮ БРИГАДУ. А на. уя было в первом примере добавлять столько сущностей, если можно было просто добавить виртуальную функцию, переопредедив ее в гребаном пингвине?

[@keeroin]

Пили про исключения!)

[@ishdx9374]

Монады лучше

[@DarkIllusoire]

На самом деле, этот пример надуманный - он больше про проектирование"а что если, вдруг" - это как про бабушку, которая стала дедушкой

[@ebla1n393]

На самом деле если ты вдруг столкнёшься с данной проблемой перед каким нибудь дедлайном, то тебе придется либо нахер выкидывать свой прошлый код в помойку, либо юзать хуеву тучу костылей :/ Так что не советую говнокодить в таком случае если зарплата нормальная. В любом случае при расширении интерфейса тебе придется выкидывать код на помойку и писать его по новой. Имхо, это неуважение к себе и к своему свободному времени ибо никогда нельзя быть уверенным в будущей неизменности своего кода.

[@DarkIllusoire]

@@ebla1n393 в любую систему следует закладывать разумную реализацию, а если у вас внезапно, появляются собаки умеющие летать, то это проблемы проектирования, код не должен помогать говнокодить. Для остальных случаев, дедлайна того же, есть куча возможностей прилепить сколь угодно костылей. Наследование должно применяться не для красоты, а для простоты. То есть наследование от абстрактных классов, реализующие интерфейсы с не пустыми виртуальными методами - довольно гибкая система, когда нужно переиспользовать код

[@klerg321]

@@ebla1n393 но если нет оснований думать, что кто-то кроме пингвина будет плавать, так и не надо делать ерунду и обмазываться интерфесами. Вот когда появится необходимость, тогда и вынесется в отдельный абстр. класс или интерфейс "плавучее животное"

[@ebla1n393]

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

[@ebla1n393]

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

[@Mr43046721]

Лукас, заслуженно.

[@user-bn7tq4ml6l]

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

[@sergobelich6963]

Как услышал хардбасс. Сразу лайк подписка колокольчик

[@rotrhino]

Найс процитировал первую главу про Стратегию из книжки по шаблонам проектирования.

[@pavlochychylnitskiy1288]

Привет, подскажи вкратце каких вещей хватит для фронтенда кроме html и css конечно

[@kirill2974]

Жду видео про исключения

[@nezajac]

Я начал понимать для чего нужны интерфейсы, но я еще не дочитался до них в книжках.

[@user-rl8ei4iu9z]

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

[@teddeiread1735]

Лукааааааааас!

[@user-hl7zj8fc7u]

Поставил лайк под видео, видос хороший, но сейчас меня зачмырят... Как же я рад что я учил только Java))) Там как бы с этим делом реально по проще.

[@user-nw8sn5gf9e]

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

[@Wherrimy]

Проблемы наследования тут не показаны. Когда ты добавляешь метод в класс Animal, ты должен сразу прикинуть является ли данное свойство неотъемлемой частью именно всех животных, или только отдельных видов таковых. Если нет, то пользуешься чехардой из наследованных классов (вплоть до выделения всех царств, подцарств и т.д. из биологической иерархии в пределах требования программы). Если классов слишком много, пользуешь стратегию/мост/декоратор, например. Ну а в целом, да, есть принцип "композиция лучше наследования", например из-за того, что композиция динамична, а наследование статично.

[@ilya9485]

Ребят, а как вы доступ к полям через свою стратегию получать то будете?

[@klerg321]

А легко, прокидывать также. Лучше каждый сеттер/геттер оформить отдельным экшэном :D

[@nezajac]

Подскажите нубу что это за волшебная кнопочка которая совершает автозаполнение?

[@ryazanov13]

ок, если я получаю список животных и они в начале должны говорить, а потом ходить, какой интерфейс мне указывать? Сам по себе интерфейс с точки зрения ООП разве ни есть наследование? Например, в случае с++ вообще нет интерфейсов как языковой конструкции, но можно создавать абстрактные методы, при этом есть множественное наследование, в итоге можно через наследование реализовать то что ты показал через интерфейсы.

[@matrix_root]

Муза на фоне топчик

[@Rumpelstilzchen_M]

О. Как раз исключения изучаю. Рассказывай.

[@agweprint27]

а почему нельзя обращаться просто penguin.Swim и penguin.Walk, в примере с дефолтными рализациями в интерфейсе? Там класс Penguin имплементирует 2 интерфейса (IWalker и ISwimmer), которые уже имеют реализацию.

[@conanchief]

них...чего не понятно, но ооочень интересно

[@jmik4956]

А разве следование "принципу единой ответственности" не должно на корню присечь подобные ситуации?

[@MK_Electron]

Не мог вникнуть в код , потому что музон качает xD

[@yurademchenko9924]

Лайк. Но, 4:00 интерфейс IAnimal это моЩЩно ))

[@bearpro]

Default Interface Implementation сделали только для поддержки Legacy, по этому нужно явно обращаться через интерфейс при использовании реализации по умолчанию. Да и это приводит к тем же проблемам, что и множественное наследование. Вообще, у меня вопросы возникли уже в самом начале видео, где автор начал добавлять член к абстрактному Animal. Два интерфейса : IWalking и ISwimming - решат все проблемы не хуже чем решения продемонстированные в конце (я говорю "не хуже" не просто так, неудобства возникнут как только мы сложим всех наших Animals в какой-нибудь List, и у нас уже не останется информации ни о каких интерфейсах, так что типы придётся всё равно проверять в рантайме). При использовании типов достаточно придерживаться SOLID (в данном примере нужно было бы обратить внимание сразу на O, L и I). Бизнес-логику можно и даже нужно писать, по максимуму используя все фишки ООП. Просто ООП нужно уметь правильно готовить.

[@umangmishra5614]

English viewers who got this recommended can take refuge here🙏

[@dmytrolambru2984]

Аффигенно! Спасибо за хорошие примеры и аргументацию )

[@user-fv6jt7vf6k]

Если не множественное, тогда может селективное наследование? В описании производного класса перечисляем что наследуем, а что отбрасываем?

[@El.Barrent]

Видео нужно было назвать "How to slav your inheritance".

[@jakksoft]

Я весь урок качался под трек 😂

[@user-mu8ve8in6q]

Слоны как раз отлично умеют плавать.

[@seniordev9275]

Берешь абстрактный класс, делаешь у него метод virtual. И получается тот же интерфейс с дефолтной реализацией. Для меня добавление этой "фичи" очень сомнительная идея... которая как раз порождает множественное наследование

[@maslyonoklesnoy6699]

Животное может выполнять массу действий. Если добавлять на каждое действие по свойству IAction, то класс разбухнет. Как организовать возможные действия для животного?

[@klerg321]

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

[@Oleksandp]

все же нужно расматривать конкретного слона, а не абстрактного в вакуме. очень, ОЧЕНЬ много зависит от того что изачем делаешь.

[@user-ox4yl6gu3u]

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

[@mitrus4]

Ну если при проектировании начинаешь понимать, что интерфейс будет расширяться намного быстрее чем сущности, то visitor можно прикрутить. Для меня, как для плюсовика, все что вы показали то же наследование, ибо интерфейсов как сущностей у нас нет. Вопрос лишь в том, какую иерархию строить с учетом будущих изменений. И достаточно часто очевидно какие части будут расширяться в будущем быстрее, а какие медленнее.

[@tigranovakyan4913]

Понятие класс -это то что объединяет общие методы и свойства (Бро пингвин и собака имеют разные свойства) не нужно усложнять жизнь называя их зверушками)))) еще и под один класс пихать их)) ах да название канала же 'ExtremeCode' теперь все понятно))

[@oleghardy4622]

по сути это пересказ первой главы книги про паттерны фрименов)

[@star_lord1911]

Давай по чаще видосы, очень годно 👍

[@vladyslavandriienko3969]

Ничего не понял, но крайне интересно

[@olezhonnv3215]

Проблема в том, что практика показывает следующее. Как бы вы не проектировали, по мере роста проекта у вас в любом случае будет такая мешанина кода, что там ООП - не ООП, уже не важно будет. Потому что такова жизнь! Проектирование дает результат в начале и потом некоторое время. А дальше все это станет легаси кодом. В ЛЮБОМ СЛУЧАЕ! Независимо от парадигмы и подхода.

[@smaugterrible5785]

Я правильно понял, что для обхода проблем с наследованием пришлось реализовать typeclasses из Хацкеля?

[@danilkha]

Может я чего-то не понимаю, но в java, например, можно создать готовый класс с методами которые уже что-то делают и когда какой-то класс от него наследуется, то этот класс может переопределить готовые методы класса родители без переписок abstract

[@dashandr1]

Вот хороший вопрос. Когда плюсы изучал, тоже так делал

[@user-ws5ns3sl1q]

Слоны по дефолту не умеют плавать. Если ты напишешь реализацию для плавания по умолчанию в классе, и наследуешь от этого класса слона, то метод swim все равно унаследуется, и получится что слоны умеют плавать.

[@qaserus1226]

@@user-ws5ns3sl1q в видео говориться что уже после добавляется метод свим. Так вот, в джаве пишешь в класс пингвин метод свим и все. В класс родительский не надо его пихать. Я ещё тот маслёнок... только учусь. Может чего не понимаю еще

[@user-ws5ns3sl1q]

@@qaserus1226 Тогда тебе придется весь код этого метода продублировать для каждого животного, которое умеет плавать. Написать метод swim для пингвина, собаки, кошки и.тд, причем весь этот код будет одинаковым (или почти одинаковым). А дублирование это плохо

[@qaserus1226]

@@user-ws5ns3sl1q ну если этот метод нужен многим классам то да)))

[@user-be2cy2fb9u]

просто вместо walk нужно использовать move. и Вот уже и червяк и слон ходют... walk это уже реализация move ))) и в методе move определяем стиль движения - идти, ползти, плыть(если в воде) и это должно может быть инкапсулировано, это же не объект без поведения

[@VaeV1ct1s]

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

[@user-tk2jy8xr8b]

Слоны замечательно плавают!

[@Das.Kleine.Krokodil]

7:30 а чтобы не делать приведение типа, нельзя вместо var базовый тип укзать?

[@user-zi8jn1go8k]

Если интерфейсам разрешено содержать дефолтную реализацию, тогда чем это отличается от множественного наследования?