Большие проблемы наследования в ООП
ฝัง
- เผยแพร่เมื่อ 26 ก.ย. 2024
- В этом видео мы узнаем какие проблемы несет в себе принцип наследования из ООП и как эти проблемы можно решить при помощи стратегии, интерфейсов или методов расширения
Исходники из видео
github.com/ext...
Видосик про Стратегию
• Важнейший шаблон прогр...
Музыка: DJ Blyatman - SLAV KING feat. Life of Boris (Instrumental)
• DJ BLYATMAN - SLAV KIN...
#ооп #программирование #наследование
Доп. ссылки:
● Insta: / _extremecode
● VK: extreme...
● Telegram Chat: t.me/extremecode (или в поиске @extremecode_chat)
● Конструктор сайтов StoryLand: storyland.mobi...
Пингвин должен говорить не "ХЗ", а "Линукс"
И еще пингвин бы сказал что ООП говно, а Си наше все! Каждый раз для граблей - ООП с выходом новых стандартов (по факту костылей которые называют фичами) для того чтобы улучшить грабли. Но всеравно грабли от этого не перестают ими быть, даже если они удобнее! Как следсвие over-garbage код, утечки памяти, мусорный код сжирающий ресурсы машины... Таким бы был пингвин если бы Линус Торвальд использовал грабли ООП для создания этой системы! Да и был бы этот пингвин еще жив - большой вопрос!
"fuck nvidia"(c)
GNU
А в чем разница?
представь себе пингвина у которого звуки хз XD
4:19 Как же хорошо, что в C# нет множественного наследования
4:20 ...А теперь в C# 8 можно пилить дефолтную реализацию интерфейса
@@user-w32eiJkNlIn9a2nRq6n Они становятся абстрактными классами просто с возможностью множественного наследования.
@@user-w32eiJkNlIn9a2nRq6n так и просто полностью абстрактный класс остается контрактом, который нельзя сам по себе инстанцировать.
@@user-w32eiJkNlIn9a2nRq6n "Он может содержать в себе кучу базовой логики, в отличие от интерфейса." (с)
Но начиная с 8-й версии, это отличие полностью исчезает.
@@voltamperoff Глупость, в интерфейс ты не добавишь поле. Это вся суть интерфейса, ты не можешь задать стейт классу.
Интерфейсы описывают, что класс делает, а абстрактный, как он это делает, то есть в нём лежит кусок кода, работающий за логику наследников. В интерфейсе методы логики особой не несут. Можно даже сказать, что метод в интерфейсе - заглушка, которую можно переделать (с целью избежания рефакторинга)
Когда пришёл узнать о недостатках наследования, но вместо этого начал танцевать ХАРДБАСС!
Слоны умеют плавать :)
В остальном, как обычно, красава :)
Ты слон
@@dashandr1 И кто это говорит, жирный троль? :)
@@evgeniym29 азарной слон)
Кстати да, они хорошо плавают
Кликбейт же
Зачем вообще пихать метод Swim() в родительский класс, если он не является общим для всех наследников? По-моему, вы чего-то не понимаете в ООП.
Проблемы с ООП возникают у тех, кто именно так его использует. Поэтому для демонстрации "как делать не нужно" самое то
@@leeroyjenkns5182 Ты описываешь идеальный мир которого не существует.в реальных проектах почти всегда такая хуйня как на видео и ен важно банк это или стартап , нет времени постоянно все рефакторить.
@@ivansidorov5 А если изначально так не делать?)
@@Nikita-hu9bk ты никогда не писал большой проект где участвуют больше 3 человек?) и длится больше года. Изначально можно сделать хорошо при 2 условиях: 1) ТЗ не меняется 2) Дают время на рефакторинг . Я перевидал много проектов, везде полная дичь с ООП и куча костылей для него. нет говна только в тех проектах, которые мелкие и пишутся 1 человеком, а еще в тех где писал все ты) потому что там там, как привык ты)
Да затем, чтобы видос заснять. А про что тогда снимать??
Сидишь такой, ура наконец то начал понимать ООП, спасибо видосу теперь понятно, что ни хя не понятно XD
Инкапсуляция тоже была бы мусором, если бы не сокрытие данных
Кажется, в одном из роликов говорилось, что инкапсуляция, это не тоже, что и сокрытие
@@ДавидАрахелян По крайней мере не сокрытие данных точно. Инкапсуляция - сокрытие реализации за интерфейсом, и нужно для того чтобы в реализацию можно было вносить изменения в ходе поддержки программы (баг пофиксить, оптимизировать что-нибудь. С такими целями блин сделаны все нововведения в программировании после появления символьных имён для процессорных инструкций - упрощение поддержки и улучшения кода).
Брат беги, не оглядывайся =)))
@@ДавидАрахелян сокрытие подразумевает не только сокрытие данные, но и сокрытие реализации.
что мешает делать мне все публичными?
3 часа ночи, я же даже не программист...
Становись
А в целом ты смог понять о чем вообще идёт речь? 😄
@@paztwel я не понял, почему метод swim нельзя засунуть сразу в класс Пингвин? Чтобы не повторять его если появится класс акула например?
Норм жизнь тратишь
@@equim7363 да
Новый год давно наступил, а автора отпускать похоже не собирается.
Взять хуево составленный контракт (а куча абстрактных методов и есть контракт, а не наследование) назвать это наследованием и предложить решение, которое к полиморфизму отношения не имеет от слова "совсем": все животные будут реализовывать ходьбу, плавние и т.п. одинаковым способом?
БРАВО, ГЕНИАЛЬНО, ШЕДЕВР. Еще и на серьезных щщах это все рассказывать...
Видимо смотрят это реально только "маслята", коли такое соотношение лайков/дизов
Эм, представьте что я тупой ребёнок, почему одним способом?
Слоны, ска, ПЛАВАЮТ!
А если серьезно, то это пример плохого приложения наследования. Ибо если бы в биологии так же решили классифицировать животных тупо по умениям они бы тоже быстро за.бались, и ничего бы у них толкового не вышло. Соответственно, проблема не в системе иерархического наследования, а в её правильном применении.
Точно. Здесь проблема не в том, что "наследование говно", а в том как оно используется. Добавление swim в класс animal соответствует утверждению, "все животные плавают". В данном случае, это неверное определение уровня абстракции, на котором должен быть размещен метод. Чем выше уровень абстракции, тем более общие части в нем должны находиться. Биологическая классификация живых организмов хороший пример развития такой классификации от общего к частному. Более прикладной уровень - возьмите System.Object, там будут только самые общие методы, которыми должны обладать все произвольные объекты, чтобы среда нормально работала. Так-то при желании или в угоду хайпу можно извратить любую идею.
AlexXx, я говорю как относительно биолог:вы ахуеть как правы
Тоже с вами парняги абсолютно согласен!!! Ребята с канала просто хайпануть захотели, а новечки в профессии решат после этого видео забить на наследование)
@@evgeny_5891 но в видео было сказано что наследование нужно, но использовать стоит аккуратно (если я ничего не забыл)
@@СергейГриневич-в5ф В целом мне видос очень понравился, лай однозначно! Автор ближе к концу ролика начинает говорить, о том что наследование "допустимая" штука, но нужно использовать ее с умом, как по мне, нужно это было-бы сказать в начале, но я не автор.) В целом классный канал, и ребята поднимают правильные темы, желаю им удачи!
Сами создаем проблемы -- сами героически преодолеваем.
1. Менять базовый класс можно только общей логикой. Уже ниже писали что добавлять метод, который будет вызыватся только в одном единственном наследнике -- такое себе.
2. Ничто не запрещает обьединить подход с интерфейсами и абстрактным классом. И тогда можешь внедрять хоть утконосов, которые вообще ни от кого не наследованы в реализации.
3. Без конкретики как это потом применять все это бесмысленный набор символов.
Итого полезного из видео: нехуй пихать в базовый класс всю логику, а потом удивлятся "че за порожняк".
странно как то написал, отвечу так, как понял.
1. Так вроде ты описал то, что в начале и объяснялось - проблема. Но! В ходе расширения наследников много будет.
2. Не совсем понял, к чему утконосы до объединения подходов с интерфейсами и абстрактными классами. Если можно, по проще объясни.
3. А ручками никто не запрещал потом это потрогать (попрактиковаться).
@@devil_of_war Так, я затер нахер всю ту простыню, что хотел выдать, и постарасю максимально упаковать "меседж":
Без явного понимания нахер нам эти классы и как их потом использовать, любой довод можно как подтвердить, так и опровергнуть. У нас нет дилемы "яйцо - курица", вначале ВСЕГДА НУЖНО ТЗ.
- если программа подразумевает что мы вытягиваем из коробки животное, и заставляем его подать голос, наследование вполне проканывает.
- если программа подразумевает что вытянутое животное нужно будет заставить сделать N-действий, и этот список "динамический", то наследование действительно больше создаст проблем, чем решит. Возможно часть обьектов и будут обьедены общей реализацией, но более надежно вынести все это за интерфейс.
И так можно придумывать до бесконечности.
@@Oleksandp вот теперь намного яснее. Даже нечего сказать в противовес. Ведь реально ТЗ разное, и программы разные.
даже если так, композиция + интерфейсы выглядят красивей и меньше кода пишется (лучше, чем у каждого наследника писать новый метод, а абсрактный класс будет содержать пару полей)
@@Oleksandp когда много похожих зверушек с маленькими отличиями, то лучше наследование. Но если же у нас целый зоопарк и общие у зверушек только пара свойсв, удобней будет указанный в видео способ.
Проблемы не у наследования в ООП, а у того, кто неправильно его применяет. Если вы забиваете микроскопом гвозди, то ни гвозди, ни микроскоп в этом не виноваты.
так он вроде именно про это и говорит.
Илья Иванов
, наследование - это не совсем удачный термин для этого механизма. Именно поэтому это самое "наследование" и применяют неправильно многие люди.
Если термин "наследование" заменить на термин "расширение функциональности", то название становится рекомендацией к применению этого механизма.
ога, архитектурно-структурные подходы.
Проблемы с доступом к джой казино, как только увидел твой коммент у меня пронеслось в первую очередь
Но почему микроскоп обычно применяют нормально, а наследование пихают хер знает куда? Кроме того, применений у этого "микроскопа" не так уж и много между прочим. А апологеты ООП выставляют его как "основопологающий принцип", один "трёх якобы суперглавных". Вот это и заставляет новичков пихать его куда-попало. Они думают, что без наследования их код будет не достаточно крутой. И в результате пытаются пришить к нему наследование, лишь бы было.
дроп в 8 утра в рабочий день, кайф))
Чтобы было чем на работе заняться..
щас мужики всем отделом посмотрят и будут холиварить весь день! А если там ещё адепты разных языков есть, то холиварить будут до понедельника.
@@paul_wiggin ахахаххахаха
Это не проблемы ООП, это проблемы кодеров, которые не могут в ООП
Если прогер говорит "Это проблемы кодеров которые не умеют в ООП", то этот прогер не умеет в ООП.
И слава богу что таким криворукам теперь вяжут руки в любом современном ЯП, чтобы они свое "мега ООП" не несли в массы.
@@vBasterv чел...
Ребят. Давайте жить дружно. Вы же понимаете, что ООП инструмент ограничений - метод борьбы одного программиста с коллегами. Когда над проектом работают сотри программистов, такие архитектурные решения - скелет проекта. Нужный чтобы весь код не превратился в мусор, который тяжело поддерживать. ООП это уже давно не пушистый зверёк, который создан для того, чтобы тебе было удобно)
@@sergeifomin3225 именно
Чел?
По-моему, если не следовать несуществующему принципу ООП "объявления всех методов должны быть только в базовых классах", то в примере будет всё ок с наследованием, не?
По-моему если следовать существующему принципу ООП, то мы должны в конечном счете работать с абстракциями, не?
@@ExtremeCode конкретный класс тоже описывает абстракцию. Над всеми его экземплярами
@@ExtremeCode но, вообще, не разу не видел понимание принципа "абстракция" из ООП как необходимость наличия слова "abstract" перед каждым методом. Обычно это про то, что мы должны создать хорошую абстракцию, которая скрывает детали реализации. Про создание минимального интерфейса, который легко использовать. Можете посмотреть у Крэга Лармена в главе про GRASP про принцип "high cohesion / low coupling", например
@@KirillTerekhov абстракция, это не абстрактные классы, весь смысл ООП заключен в полиморфизме и апкасте к "общим" типам, вместо работы с "конкретными" типами, именно из-за этого весь сыр бор в статической типизации, т.к. это единственный способ работать с группой схожих объектов без конкретизации что именно это за объект, хотя они могут иметь различные реализации.
Для того чтобы достичь этого - существует как наследование, так и реализация интерфейсов. В видео была показана конкретная проблема которая возникает при использовании именно наследования, и различные варианты решения этой проблемы.
@@ExtremeCode как я уже говорил, конкретный класс - это тоже абстракция. Достаточная для решения проблемы из видео. Проблема с наследованием там в том, что вы его применили неправильно. В нарушение принципа подстановки Лисков, например
Лучше уж просто сооздать класс Animal, и отдельно интефрейсы типа ISwimmer : where T , IWalker : where T ,
вроде так лучше. Возможно ошибаюсь) Я не так давно программирую
На самом деле, этот пример надуманный - он больше про проектирование"а что если, вдруг" - это как про бабушку, которая стала дедушкой
На самом деле если ты вдруг столкнёшься с данной проблемой перед каким нибудь дедлайном, то тебе придется либо нахер выкидывать свой прошлый код в помойку, либо юзать хуеву тучу костылей :/
Так что не советую говнокодить в таком случае если зарплата нормальная. В любом случае при расширении интерфейса тебе придется выкидывать код на помойку и писать его по новой. Имхо, это неуважение к себе и к своему свободному времени ибо никогда нельзя быть уверенным в будущей неизменности своего кода.
@@ebla1n393 в любую систему следует закладывать разумную реализацию, а если у вас внезапно, появляются собаки умеющие летать, то это проблемы проектирования, код не должен помогать говнокодить. Для остальных случаев, дедлайна того же, есть куча возможностей прилепить сколь угодно костылей. Наследование должно применяться не для красоты, а для простоты. То есть наследование от абстрактных классов, реализующие интерфейсы с не пустыми виртуальными методами - довольно гибкая система, когда нужно переиспользовать код
@@ebla1n393 но если нет оснований думать, что кто-то кроме пингвина будет плавать, так и не надо делать ерунду и обмазываться интерфесами. Вот когда появится необходимость, тогда и вынесется в отдельный абстр. класс или интерфейс "плавучее животное"
@@klerg321 в довольно больших проектах одиночные исключения встречаются очень редко, а при большом кол-ве исключений (имеется в виду различия в функциональности объектов подкласса т.к. речь идет о расширении функционала) теряется сама идейность наследственности, ибо каждому объекту придется расписывать по новой его ф-ции и код это почти не сократит. +как всегда аргумент об изменении родительского класса остается на месте.
@@klerg321 отсутсвие оснований на данное предположение почти не встречается в более-менее крупных проектах, а в мелких наследственность - игрушка, ибо создает минимальные сокращения и препятствует расширению ф-ционала
именно в словах типа "я запихну все в кучу, чтобы не усложнять код" и кроется вся суть :D
Слишком идеальный контент. Пишу комментарий, чтобы было понятно, что вы делаете лучшие туториалы на свете. И великолепным голосом
Проблемы наследования тут не показаны. Когда ты добавляешь метод в класс Animal, ты должен сразу прикинуть является ли данное свойство неотъемлемой частью именно всех животных, или только отдельных видов таковых. Если нет, то пользуешься чехардой из наследованных классов (вплоть до выделения всех царств, подцарств и т.д. из биологической иерархии в пределах требования программы). Если классов слишком много, пользуешь стратегию/мост/декоратор, например. Ну а в целом, да, есть принцип "композиция лучше наследования", например из-за того, что композиция динамична, а наследование статично.
Почему то во многих книгах, много где вообще в интернете наследование подается как один из самых популярных, часто используемых и нужных штук в ООП. На деле же это механизм, который нужно использовать с умом и не пихать везде где тока можно
Спасибо за критические ролики! И своеобразного юмора над всем тем балаганом что есть в кодинге. Долго время не мог подступиться к ооп и паттернам и прочим техникам, казалось чем то сверх сложным и требующим много времени для разбирательств, но когда узнал о проблемах в ооп и понял за что его макают лицом в грязь, вообщем говоря обратную сторону медали, то пришло озарение и понимание простых вещей, для чего все эти паттерны придуманы и какую большую проблему в проектировании с помощью кода они решают. Так же наконец то прочитал книгу чистый код и достаточно легко переварил все в ней сказано и офигел на сколько же она простая и это только верхушка айсберга тех вещей с помощью которых можно по-человечески выполнять свою работу))
Понятие класс -это то что объединяет общие методы и свойства (Бро пингвин и собака имеют разные свойства) не нужно усложнять жизнь называя их зверушками)))) еще и под один класс пихать их)) ах да название канала же 'ExtremeCode' теперь все понятно))
В последнем примере с Trait - зачем все так сложно? Почему нельзя просто сделать два интерфейса ICanWalk и ICanSwim, и затем написать класс расширение для каждого из них?
Типа
public static void Walk(this ICanWalk canWalk){...}
?
English viewers who got this recommended can take refuge here🙏
просто вместо walk нужно использовать move. и Вот уже и червяк и слон ходют... walk это уже реализация move ))) и в методе move определяем стиль движения - идти, ползти, плыть(если в воде) и это должно может быть инкапсулировано, это же не объект без поведения
Я благодаря этому паттерну собес прошел успешно.
- Вы умеете использовать наследие в ООП?
- Наследие мусор!
- Вы приняты
дык, open/closed principle! Только ситхи вносят изменения в классы
open/closed сложно представить при грубом наследовании
Хуык
@@vinik_tfo, наследование не нарушает его, каким бы грубым оно не было, только бы Лисков оставалась удовлетворённой)
В принципе, реализация множества интерфейсов - то же множественное наследование абстрактных классов, только с синтаксическими ограничениями, чтобы не отстрелить ногу ненароком. Но суть та же...
Этот видос явно лучше видоса про стратегию, исправляешься, потому лайк.
Вообще не ебу, что происходит на экране, но смотрю все видосы. 👍
Берешь абстрактный класс, делаешь у него метод virtual. И получается тот же интерфейс с дефолтной реализацией. Для меня добавление этой "фичи" очень сомнительная идея... которая как раз порождает множественное наследование
Час назад вернулся с днюхи, смотрю в универе и получаю полезную инфу 😂
Наоборот, это очень вредное видео, в котором автор показал как он не понял как правильно использовать ООП.
Классно! Помню как в рамках изучения JS писал терариум, так добавление каких-либо возможностей "жителям" иногда приводило к хорошим проблемам. А вообще мне понравилось)
Проблема в том, что практика показывает следующее.
Как бы вы не проектировали, по мере роста проекта у вас в любом случае будет такая мешанина кода, что там ООП - не ООП, уже не важно будет.
Потому что такова жизнь! Проектирование дает результат в начале и потом некоторое время. А дальше все это станет легаси кодом.
В ЛЮБОМ СЛУЧАЕ! Независимо от парадигмы и подхода.
Шаблон «Компоненты» стучится в дверь
Именно. Хоть кто-то написал.
Слоны как раз отлично умеют плавать.
Тема конфронтации объектно-ориентированного кода и кода процедурного все же не несколько однозначная. Например, при ооп легко добавлять новые объекты, а в процедурном программировании легче расширить функции объектов.
Наследование в подавляющем большинстве случаев необходимо только разве что при использовании различных фреймворков и api, где дизайн классов специально заточен для того, чтобы от них наследовались. А если реюзать свой код, то интерфейсы, композиция и utility-методы)
ВЫЗЫВАЮ ПОЯСНИТЕЛЬНУЮ БРИГАДУ.
А на. уя было в первом примере добавлять столько сущностей, если можно было просто добавить виртуальную функцию, переопредедив ее в гребаном пингвине?
Но теперь для создания пингвина надо изучить в коде 3-4 сущности вместо 1. А каждая из них может так же конструироваться из 3-4 сущностей. Создание объектов в такой архитектуре усложняется геометрически.
Полезно, понятно, быстро и с музыкой! Однозначно лайк и спасибо! 😘
Умный кто-то,
Может видео, как делать большие проекты типа paint, word? С чего начинать, какая должна быть структура чтобы было ооп и красиво
а ты маленькие уже умеешь делать?
@@Andrey-il8rh калькулятор-шифратор какой-нибудь легко, с чуть ооп
@@sergey1658 такие проекты как word явно не в одно рыло делаются, многое ещё зависит от языка на котором предстоит писать проект. ООП это не панацея и не показатель крутости - это инструмент для решения конкретных проблем которые для начала нужно осознать, не нужно городить в проекте ООП ради оценки подруги маминой сестры
Слоны не умеют плавать... Посмотрим как ты уплывешь от бешеного слона xD
Ничего не понятно, но очень интересно.
Глупо винить молоток за то, что он не работает как отвёртка. ЭТО ПРОСТО РАЗНЫЕ ИНСТРУМЕНТЫ!
Я под такую музыку иногда отхватывал и иногда сам кому-нибудь вкладывал на подмосковных дискотеках в начале нулевых))) А тут ООП.
Здорово раскрываете суть паттерна(нов), все понятно. Остается попрактиковать закрепив результат. Кстати в книге «Банды четырех» этот паттерн нифига не понятен, с их примером создания текст.редактора.
Вот что значит хороший ролик. Я вообще не кодер, не понимаю ничего из сказанного, но смотреть интересно.
Данный коммент был написан для того чтобы пинать алгоритмы ютуба и видос больше рекомендовался человекам. Если тоже хочешь их пинать лайкни комент
Видео нужно было назвать "How to slav your inheritance".
Спасибо, только сегодня сделал дз по массива и теперь в ООП погрузился, нихрена не ясно но очень интересно)
музыкальное сопровождение шикарно
Лайк. Но, 4:00 интерфейс IAnimal это моЩЩно ))
Начал писать этот комментарий , а потом остановился , решил досмотреть видос , вдруг автор скажет , но либо я прослушал , либо автор так и не сказал. Вот у нас есть класс , который реализует несколько интерфейсов , но это ведь тоже самое множественное наследование , а интерфейсы - абстрактные классы , даже больше , в тех же срр вообще нет интерфейсов по умолчанию , на сколько я знаю , и абстрактные классы как раз используются как интерфейсы если это необходимо , без объявления конструктора. Интерфейсы в других языках это тоже самое же ж , только слово "класс" заменилось на "интерфейс"
upd да я знаю про то , что классы наследуются , а интерфейсы реализуются , минус лишние сущности , проблема ромба бла-бла-бла , но идеалогически это тоже самое , то же множественное наследование
Это не проблема наследования, а проблема кривых рук и мозгов. Внезапно, действия (методы) в реальной жизни тоже попадают под классификацию, но данные (существительные) в оопе воспринимаются как имеющие механизм наследования, а функции (глаголы) - нет. Например у конкретных методов walk и swim должен быть родительский абстрактный метод move. Конкретные методы (действия передвижения в реальном мире) основаны на том, в какую среду "погружён" объект, и это ясно показывает, что они зависят от внешних объектов, а не от наследования. Добавляем животинам методы перехода в среду (паттерн Стратегия), которые у каждого разные и получаем, что при прыжке пингвина в воду метод move будет плавать, а при прыжке в воду особого-не-умещюего-плавать-слона метод move - плавать не будет. Естественный ход вещей реального мира предполагает, что животное умеет/не умеет особым образом передвигаться (move) в разных средах; при передвижении животное может попадать в другую среду и там нужно будет передвигаться иным, чем только что способом. По этому в случаях, подобных данному примеру, проблема состоит не в наследовании, а в не правильном понимании происходящего. Но, конечно проще всего сказать что это не разрабы тупые, а ООП должно само не явно уметь паттерн стратегия, а если не умеет, то это его (ООП) большая проблема. Но то, что мы в абстрактный класс добавили метод walk, это точно не мы тупые. Я уже не говорю про то, что различные уровни абстракции люди запихивают в один абстрактный класс, а потом огребают и бегут плакаться в бложики.
Если исходить из понятия наследования, как биологического термина, то у наследования в ООП есть проблема отсутствия механизма доминантности и рецесивности признаков; иными словами у биологических потомков некоторые свойства могут пропадать и эта пропажа наследуется далее, а у в ООП наследники не могут исключать из наследования родительские признаки. Но при появлении такого механизма будут массово появляться разработчики подкидывающие петуха со словами "э ну чё он не летает", а так же появятся разработчики, которые нашли "решение проблемы не летающего петуха" не понимая, что это не была проблема и петух так и должен себя вести. По этому: проблема всегда в человеке.
Угарнул на моменте трейтов и PHP программистов)
This is your daily dose of Recommendation
.
Найс процитировал первую главу про Стратегию из книжки по шаблонам проектирования.
О. Как раз исключения изучаю. Рассказывай.
А разве следование "принципу единой ответственности" не должно на корню присечь подобные ситуации?
Exceptions не нужны - а вот это уже интересненько! Давай жги!
Не ну за хардбас только лукаса можно влипить\
Может сделаете видос про функциАнальное программирование? Думаю малаяткам(мне) будет интересно послушать байки про императивные и декларативые стили, карелизация там...
Смотрю и понимаю что лучше продолжу использовать
life:
jmp poszrat
jmp posrat
jmp sleep
jmp life
Еще не хватает несколько строк для обработки прерывания:
jz death
jnz Paradise
jmp God's judgment
jmp Hell
Paradise:
...
Hell:
...
Не проще просто написать функции walk и swim без класса и вызвать их в нужных реализациях интерфейса? Можно было же просто сделать "swim();" вместо "swimAction.doAction()".
Вообще-то, если животное не умеет плавать, а на нем вызвали этот метод - то оно должно умереть. Т.е. или выкинуть эксепшн или написать в консольке "drowned". А тут получается, что ты не только лишаешь слона умения плавать (что он умеет, кстати, делать), но и лишаешь возможности в будущем понять что будет с животными которые не умеют плавать. Они просто не будут обработаны... или они все посчитаются одинаково не умеющими плавать (и каждому выделится стандартный спасательный жилет, который не поможет условному слону и будет велик мышке)...
В целом, выбранный подход должен определяться не только стройностью классов и их простотой их изменения, но и их использованием. И иногда немного говнеца в виде лишнего кода может сэкономить тонну времени на разбирательстве в 100 интерфейсов в разных модулях... KISS никто не отменял, и он в реальной жизни важнее SOLID или, простихоспади, ООП.
Слоны умеют плавать.. и весьма неплохо
Я начал понимать для чего нужны интерфейсы, но я еще не дочитался до них в книжках.
Чета загнул все фразой - «Нахрен не нужный».
Я пока что студент и довольно больших проектов не писал.( максимум университетская система )
Но, скажу одно! На мой скромнейший опыт, я понял то что нужно использовать - то что нужно. А говорить что «нахрен не нужно то-то» как то глупо.
Но видео само качественное, лайк
Учите функциональное программирования и все будут хорошо
...кроме зарплаты
В ООП не шарю, но хоть музыку послушал)
Слоны умеют плавать)
Может я чего-то не понимаю, но в java, например, можно создать готовый класс с методами которые уже что-то делают и когда какой-то класс от него наследуется, то этот класс может переопределить готовые методы класса родители без переписок abstract
Вот хороший вопрос. Когда плюсы изучал, тоже так делал
Слоны по дефолту не умеют плавать. Если ты напишешь реализацию для плавания по умолчанию в классе, и наследуешь от этого класса слона, то метод swim все равно унаследуется, и получится что слоны умеют плавать.
@@МаксимМалышев-м6ы в видео говориться что уже после добавляется метод свим. Так вот, в джаве пишешь в класс пингвин метод свим и все. В класс родительский не надо его пихать. Я ещё тот маслёнок... только учусь. Может чего не понимаю еще
@@qaserus1226 Тогда тебе придется весь код этого метода продублировать для каждого животного, которое умеет плавать. Написать метод swim для пингвина, собаки, кошки и.тд, причем весь этот код будет одинаковым (или почти одинаковым). А дублирование это плохо
@@МаксимМалышев-м6ы ну если этот метод нужен многим классам то да)))
Не забирайте хлеб у Виндертона
х))))
ок, если я получаю список животных и они в начале должны говорить, а потом ходить, какой интерфейс мне указывать?
Сам по себе интерфейс с точки зрения ООП разве ни есть наследование? Например, в случае с++ вообще нет интерфейсов как языковой конструкции, но можно создавать абстрактные методы, при этом есть множественное наследование, в итоге можно через наследование реализовать то что ты показал через интерфейсы.
сейчас бы прийти в офис с колоночькой и врубить эту прекрасную музыку и кодить... *кайф*
Спасибо! Схема гибкая бесспорно, но в защиту наследования хочется спрлсить - возможно не в парадигме дело, а в детализации архитектуры? Ведь если подумать перед тем как писать код можно же превентировать будущие изменения добавив пару промежуточных классов? Или это бред? У вас просто в видео так обставленно, что наследование изначально неумёхи используют)
Ребят, а как вы доступ к полям через свою стратегию получать то будете?
А легко, прокидывать также. Лучше каждый сеттер/геттер оформить отдельным экшэном :D
Пересматриваю этот ролик после обучения для проверки навыков сишарпа
3:53 - мой рекорд по пониманию происходящего (skull)
в книге Троелсена было подобное 2:56 и он там указал, что абстрактные функции-члены и данные-члены, которые не принадлежат ко всем производным от абстрактного классам нужно делать интерфэйсом, в данном случае был бы интерфэйс ICanSwim, и проблема множественного наследования бы решилась. Далее вы показываете "Решение", но использовать интерфэйсы без абстрактного класса глуповато и строить на них все, поскольку первоначально назначение у них другое
Я столько раз пытался тоже самое объяснить разрабам, но всегда встречал полное непонимание)
Слоны на самом деле умеют плавать
Конструктор у класса быстрее создавать через снипет ctor 😀
Просто абстрактный класс нужно назвать Move. )))
Животное может выполнять массу действий. Если добавлять на каждое действие по свойству IAction, то класс разбухнет. Как организовать возможные действия для животного?
да не воспринимать это как догму. Нафигачить действия кушать/спать в абстрактном, редкие действия или через общего наследника, или предложенным способом, или вообще не плодить интерфейсов, если действие уникально
все же нужно расматривать конкретного слона, а не абстрактного в вакуме. очень, ОЧЕНЬ много зависит от того что изачем делаешь.
Рад, что выходят подобные видосы. Лайк. Может вскоре все начнут догонять что ООП не нужно в 97.4 % случаев, а java ооп - это лютый треш.
Бред
Возможно я ошибаюсь, но разве шаблон проектирования "Декоратор" не решает показанную проблему?
Да, в большинстве своём решает, но шаблон Декоратор скорее подходит для четкой логики без нюансов, например такой, как тот же самый класс Stream: в Java использован как раз таки Декоратор, и в "производных" от него классах следует логика "базового", но она постоянна и преследует декорируемый объект всегда. В нашем же случае такое скорее будет вредно, чем полезно, так как наш зоопарк имеет огромное количество нюансов, вытекающих из биологии: пингвины хоть и птицы, но не летают; киты и дельфины - млекопитающие, но живут под водой; утконосы тоже млекопитающие, но откладывают яйца и многие другие подобные моменты.
Могу и сам ошибаться, поэтому waiting for feedback.
@@vinik_tfo лучше использовать один класс без наследования в данном случае с животными. В этом классе нужно определить все поля которые могут существовать (добавлять по мере необходимости) и уже конкретно в обьекте определять те поля, которые используются. Если полей очень много - можно/лучше использовать хешмап. А касательно методов тут все тоже логично, добавлять методы по мере необходимости. Скажете а как же полиморфизм? А что мы не можем в одном методе if (type) прописать? В полиморфизме это тоже делается, только неявно.
Я не говорю что наследование плохо, просто как это в видео указано, не всегда применимо удачно. В большинстве случаев достаточно хешмап использовать в качестве полей-значений или полей с дефолтным значением.
@@serhiis_ если этих type-ов 2-3, то ещё терпимо, а как набирается ближе к десятку - поди проконтролируй, что во всех "полиморфных" методах перечислены варианты для всех типов.
@@serhiis_ А что касается примера - надо было в базовом классе определить метод Move(), чтобы управлять животными единообразно, а уже в подклассах реализовывать те или иные особенности передвижения либо промежуточным абстрактным классом, либо навешиванием через декоратор, тут уже от конкретики зависит.
@@0imax Касательно C# в нем есть только 2 механизма избегания падения приложения, когда мы пытаемся вызвать метод, которого нету в классе,
1) Ручная проверка класса на интерфейс, в котором прописан этот метод. Топорно но работает и не падает!
2) Отражение/рефлексия. На этапе загрузки либы/классов мы можем через рефлексию добавить в интересующие нам классы методы по умолчанию, если их там нет. Например если метода нету у класса, можно добавить метод который будет присылать багрепорт разработчику при попытке вызвать этот метод. При этом приложение у пользователя не крашнется - что для нас очень важно! Ведь краш приложения - это потеря всех данных!!! Кроме того по статистике при краше приложение примерно 40% пользоветелей на 2-3 краш удаляют такое приложение и ставят 3 на плеймертеке!!! Оно вам нужно?
Поэтому я не рекомендую использовать ни чего, что могло бы вызвать краш у пользователя! Лучше пусть у него на экране верстка поедет криво накось чем упадет приложение. В случае верстки данные не потеряются, в случае краша все данные навсегда теряются вместе с пользователем!
Пили про исключения!)
Монады лучше
Я весь урок качался под трек 😂
по сути это пересказ первой главы книги про паттерны фрименов)
По сути хорошо, но название типа "чем опасно нарушение принципа сегрегации (разделения) интерфейсов" было бы точнее.
Я препод. В чат видео с Твоего канала скинул один из школьников. Из-за специфической лексики не очень воспринял сперва. Но настолько охуенно рассказанные вещи в паре видео вынудили меня пересмотреть отношение. Более того, ввиду своей лени порой даже скидываю видос вместо подготовки к уроку )) Шикарный канал, надо способствовать Твоему росту, бро
Как это нет множественного наследования, оно есть практически у всех популярных языках
Все красиво в теории, но на практике ломаем инкапсуляцию. Что делать если вдруг нам нужно сделать что то более сложное в методе чем вывод в консоль, установка свойства например, придется делать сетторы в классе, что превращает наш код в процедурный, но это не значит плохо. Подход конечно полезный и я его часто использую, но есть нюансы о котором не сказано. По начал кажется как можно без наследования жить, но с годами понимаешь что больше проблем от использования наследования, и не стоит его использовать для выноса общего функционала, лучше композиция
С каждым видео понимаю всё сильнее, что автор гуманитарий.
Инкапсуляция
.
.
.
.
.
.
.
.
.
Это сокрытие
2:10 Потому что неправильно было сделано наследование. Как в биологии, животные делятся на типы, типы на классы, классы на отряды, отряды на семейства, семейства на роды, роды на виды.То есть, нужно было наследовать от animal тип хордовые, потом от хордовых наследовать класс птицы, у птиц реализовать метод летать, где у пингвина будет он в виде плавания
так подумал, в джаве таких проблем пока не наблюдается
Как услышал хардбасс. Сразу лайк подписка колокольчик