Наследование в ООП. Зачем использовать наследование?

[@mitaigo9400]

Зашел чтобы убедится, что вы все еще Сергей Немчинский

[@alexanderchudaev9431]

Я только для этого захожу на его видосы. До самого конца смотрю чтоб точно убедиться что это он

[@sergeyinkognito7236]

Напишите в личку когда Сергей Немчинский уже не будет Сергеем Немчинским

[@dmitry9728]

@Дмитрий Давыдовпомню была 10 нет назад.

[@konstcranky]

Всю жизнь использую наследование. И отец мой использовал, и дед, и прадед.

[@oleksiibuheria932]

...и Object

[@acrrono]

Сына выгнали из семьи за функциональщину.

[@HaiIag]

ох уже эти староверы.

[@alexandersemionov5790]

У вас это наследственное значит

[@igs335]

Бог наследовал и нам велел

[@Skreepan]

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

[@ivanchernenko7958]

Кто-нибудь в курсе как ведущего зовут?

[@strangelylookingperson]

Оскар Сукинцев

[@vorobiovv]

Немчей Сергинский

[@cosinix]

Его не зовут, он сам приходит

[@ImmortalBest]

Вроде Игорь, но могу ошибаться

[@valerii-barabanov-vvb]

А, это тот чел из Extreme Code

[@Jeka-ji2yu]

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

[@vladimirshiasu7983]

@@kitten-free А где сразу хочется композицию - агрегацию

[@mik_zd]

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

[@МаксимВеснин-ш3р]

Потому что это не наследование а имплементация

[@ksviety]

@@МаксимВеснин-ш3р Есть имплементация - это когда Объект реализует какой то функционал, а есть наследование интерфейсов - это когда интерфейс наследует поведение другого интерфейса.

[@TcheburTcheburashka]

Подытожу кратко, что сказал Сергей в видео: - "Применяйте наследование там где оно действительно нужно, если в нем нет смысла используйте делегирование. Больше думайте и применяйте все по назначению, а не потому, что так модно"

[@SergeyNemchinskiy]

Спасибо

[@nadirnazirov4707]

Спасибо Сергей, с вами всё становится проще.

[@Cleannetcode]

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

[@igorbruhanov9176]

"полиморфизм тоже невозможен без наследования" расскажите кто-нибудь автору про шаблоны в c++, про трейты в rust... Дядька крепко застрял в модных концепциях ООП из начала 90-х.

[@vladislavrodin8036]

И встраивание в Go. Это называется java головного мозга. Все, что не джава - все плохо

[@roman-_-novikov]

Если слушать внимателольно, то можно понять, что автор про template в с++ знает и упоминает... hate головного мозга)))

[@mik_zd]

шаблоны c++ это же вроде только статический полиморфизм?

[@Alexey0795]

сколько раз в ролике использовалось слово "композиция" ? так не честно же из субтитров: "наслед" 37 раз "делегирова" 2 раза "компо" 0 раз

[@ДмитрийС-п9д]

Наверно это самая важная часть в книге банды четырех: специфицирование интерфейсов объектов и далее (стр 27, docs.google.com/file/d/0B6GuCegBf3X3Tm1rZl9BUTduQm8/edit). Они четко разделяют понятия интерфейс/тип (причем это не только то, что находится после слова interface) и реализацию/класс. "... интерфейсы ... фундаментальны". Только после разделения этих понятий в голове становятся возможны: декораторы, адаптеры, композиции и др. Если же рассматривать их в одной куче, то получаются что без наследования (в целом) невозможно строить полиморфизм (большинство паттернов его частный случай). На самом деле его невозможно строить без разделения между несколькими классами интерфейсов или попросту наследования классами интерфейсов.Пример в видео с зарплатой приведен не очень корректно. Обычно этот расчет занимает сотни и тысячи строк кода и обычно его хочется реализовывать где-то еще, а не в сотруднике. Наследование интерфейсов позволит реализовать его во вне понятия сотрудник, а наследование реализаций заставит вас сделать божественный базовый класс. Отсюда, на мой взгляг, и проблема наследования реализаций, но к наследованию интерфейсов это не имеет ни какого отношения.

[@dmitriyvaulin]

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

[@Lucio11a]

Тоже, наверное, в каком то смысле про наследование... Что вы думаете над тенденциями, где считается не нужным использование классов вообще (типа классы в ооп - это ошибка (слова Дэвида Уэста)), а так же о книге Егора Бугаенко "Элегантные объекты"? Заранее благодарю за ответ)

[@TimurShemsedinov]

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

[@SergeyNemchinskiy]

да, так было, но давно. Сейчас наоборот - новички не используют наследование ВООБЩЕ.

[@shitposting_box]

Это вопрос уже "Насколько развито абстрактное мышление". Многие люди не умеют выделять из объектов общие свойства и создавать родителя с этими свойствами. Есть директор, есть зам. больше ничего не надо, директор главнее, значит он родитель.

[@TimurShemsedinov]

@@SergeyNemchinskiy Маразм проходит циклическое развитие, то мода на одно, то на другое. Это редукция сложного к одному, она конечно нужна, но первые 10 лет выходит что выходит))) ну и это смотря в каком языке еще, разные языки на разной стадии моды в данный момент

[@TimurShemsedinov]

@@shitposting_box начинать нужно с Платона и Аристотеля

[@SergeyNemchinskiy]

@@TimurShemsedinov согласен :)

[@Mike19910711]

Без наследования в принципе нельзя писать приложения под тот же Android, например, где все элементы UI наследуются от View. Хочешь запилить кастомный контрол - наследуешься от View (или от любых других его потомков, не помеченных как final). Забавно, что в Android кнопки (Button) наследуются от TextView, и, если глянуть в исходники TextView и Button, можно увидеть, что в TextView около 13000 строк Java-кода, в то время как в Button не набирается и 200 (бóльшая часть из которых - javadoc).

[@Aticinsane]

Вот это настоящие эмоции! Круто!

[@lyloo6577]

Как на счет реализации полиморфизма через композицию + интерфейсы? Продолжая пример Сергея, ну ок, вынесли расчёт зарплаты в базовый класс "Сотрудник", а завтра выясняется что программисты (или некоторые из них) имеют ФОПы и выдача зарплаты у них принципиально другая. Что делать? Рисовать в базовом классе if, нарушая solid? Выносить эту логику в промежуточный класс? А что будет если будут еще такие отличия? Привет множественное наследование и mixin? ПыСы: ничего не имею против наследования, но по факту крайне мало бизнес-логики, которую можно было без опаски вынести в базовый класс. Базовый класс "Сотрудник" конечно же должен быть, на всякий случай

[@qwertymangames1800]

5:32 да именно так, в функциональной парадигме всё иммутабельно! Используем только структуры, никаких объектов. Если конечно не пишем на Scala, но и там стараемся от иммутабельности избавится

[@vmike72]

Второй лайк за упоминание Foxpro - отличная система была! Пришлось в 90-е с ней немало поработать. Даже низкоуровневые операции были доступны.

[@ArturPronin-g6f]

Что за ноутбук у Сергея? Подскажите, пожалуйста.

[@vitamin2845]

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

[@airatilyasov7694]

Сергей! От души рад, что позволили подписаться на Вас, влекущее автоматическое уведомление на смартфон и позволяющее на ровном месте ЛикБез-сть! и по-брацки.

[@maximhoroshilov]

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

[@redkoala4882]

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

[@ReaperArcheon]

Я от перешел с ангуляра на "современный" реакт, и полностью понимаю вашу боль, Сергей)

[@nikitas3160]

Разве для работников не лучше прописать интерфейс?

[@hihabl]

Огонь, жду ещё такую тематику

[@acrrono]

Ок, я всё понял. Если нужно будет делать приложение с работниками и сотрудниками - использовать наследование.

[@JustMe-y8d]

На самом деле хрень редкая. На предприятиях где этот расчет зарплаты реально применяется запросто бывают ситуации когда сотрудник 10 дней работает токарем, 5 дней грузчиком на погрузке вагонов, 2 дня сварщиком и 3 дня белит потолки. Это обычная, рядовая ситуация. Успехов вам с вашим ООП.

[@Anton-gc2xb]

Или с капибараами

[@СергейКондратенко-о9ц]

в большинстве случаев будет достаточно одного класса сотрудников, а должность - значение его поля

[@TwilightSun32]

Если нужно будет делать приложение с работниками и сотрудниками - использовать 1С ;-)

[@СергейКондратенко-о9ц]

@@TwilightSun32 для рынка постсовка в основном так и делают, но Немчинский занимается подготовкой спецов в первую очередь на проекты для западных заказчиков

[@anatolijpetrakovskij9076]

Пример с сотрудниками неудачен. Сотрудник - это сотрудник, а программист - это роль сотрудника. Таких ролей может быть много. Сотрудник может быть и программистом, и аналитиком одновременно. Т.е. программист - это не наследник сотрудника.

[@sardaucar]

А программист не сотрудник? Или аналитик не сотрудник?

[@otkwass]

​@@sardaucar это еще и человек, наследующийся от млекопитающего - ты уверен что от этого объекта на роли программиста требуются все методы, включая жрать(), срать(), спать()? от него требуются методы которые ему характерны и да, он может имплементировать множество интерфейсов, один из которых скажем сотрудник, с методами ходить_на_работу(), получать_зарплату(), участвовать_в_корпоративах(), а другой интерфейс - программист, с методами писать_код() дебажить(), задавать_глупые_вопросы_в_интернетиках(). то же самое и аналитик. но вот допустим нюанс - а если аналитик удаленный? тогда чо? будем ему перепиливать метод ходить_на_работу()? а если у нас 100500 удаленных ролей - всем им перепиливать? упс, да? :)) поэтому наследование - ну такое. тут просто Сергей застрял немного во времени и сейчас в современных языках уже появились возможности безболезненно пилить реализации для интерфейсов.

[@xxxxxx-kz6yi]

О, по ООП вовремя видосики пошли.

[@08284]

Расскажите, Сергей, пожалуйста, и о других принципах ООП!

[@sergeymih55]

Подскажите пожалуйста, честно, уже устал искать ответ на свой вопрос, может тут кто-то сможет чем-то помочь. Вот прет меня в IT направление embedded и никакое другое. Уже даже в чем-то разобрался, несложные проекты на stm32 могу разрабатывать. Только вот почему-то очень мало вакансий, меньше всех платят, а знать надо больше, чем во многих других направлениях. Почему так происходит? Может embedded еще не раскручено?

[@arthurfonzerelli6484]

Полиморфизм возможен через реализацию интерфейсов. Реализацию интерфейсов можно считать наследованием?

[@deniskoroliov1039]

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

[@arthurfonzerelli6484]

@@deniskoroliov1039 значит тезис "без наследования невозможен полифорфизм" неверен, потому что полиморфизм возможен через реализацию интерфейса

[@deniskoroliov1039]

@@arthurfonzerelli6484 По сути да. Но с этим надо аккуратнее, иначе все может превратится в говнокод пострашнее чем "все наследуется от всего". В больших коммерческих проектах без наследования никак не обойтись, а интерфейсы больше используются для построения зависимостей. Если все строить чисто на интерфейсах в проекте, у которого исходники занимают несколько сотен мегабайт, то там можно сума сойти

[@deniskoroliov1039]

@@arthurfonzerelli6484 Опять же. Наследование убирает проблемуц дублирования кода, интерфейсы ее создают

[@FarSetChannel]

Ах да. Сергей. Киньте людям ролик про интерфейсы и про их полезность. А потом и про дженерики в пром коде перетрите немного. Вас просто тут расцелуют.

[@08284]

Поддерживаю.

[@konstantinalekseev5455]

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

[@ivannovosyolov115]

Расскажите об ESP32.

[@user-fc8ut5ww4v]

Большое спасибо за такой полезный контент!

[@dgavrikov84]

А как же абстракция, посылка сообщений и повторное использование?

[@adeusexmachina]

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

[@adeusexmachina]

может запутанно сказал, но давайте предположим, что нам всё таки понадобилось вынести десяток важных общих функций в один класс предок. Да вся детвора будет обращаться к этим функциям. Утверждаем что это некрасиво и лучше создадим десяток интерфейсов и каждый из них интегрируем в каждый класс потомка. Да? Это и есть решение озвученной проблемы?

[@aleksa3969]

Привет! почему Вами не назван четвертый принцип ООП " Абстракция" ?

[@zakharbondarev7814]

Спасибо большое за разъяснение. 👍

[@voloboeff2010]

Возможно, это уже упоминали, но... Ведь в Go нет наследования, зато есть утиная типизация, позволяющая творить полиморфизм. На нём написаны очень сложные системы(минимум docker и kubernetes), и на нём создаётся всё больше программ вне enterprise сектора(я затрудняюсь определить понятие enterprise более конкретно, но думаю, Вы поняли меня). Почему он так успешен в этом направлении, обходясь без наследования?

[@shalidor1619]

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

[@nicolas267s]

Я всегда говорю, что надо зреть в корень и понимать, как что работает и почему. Нам ещё в институте приводили в пример такую историю. Женщина нарезала бекон маленькими полосками перед тем как обжарить его на сковородке. Её спросили зачем она это делает? Почему просто не жарить его так как он порезан в упаковке? Она сказала, что так делала её мама. А мама сказала, что так делала её мама. Когда у бабушки, спросили тоже самое, она сказала, что в её время сковородки были очень маленькие и длинные полоски просто не помещались. Это конечно всего лишь история, но суть передаёт. Если вы не понимаете зачем вы что-то делаете, возможно вы делаете это в пустую. Так как возможно причина этого уже не существует.

[@0imax]

Вы сейчас такую тему затронули, которая касается всей нашей жизни)) Всякие суеверия, вера в сверхъестественное и тому подобное так же наследуются))

[@nicolas267s]

@@0imax это да, традиции в особенности.

[@СергейКошельник-н9н]

Чётко и понятно.

[@Andrew1a]

Пример с сотрудниками не корректен. По сотрудникам как раз стоит юзать композицию "сотрудник" + вложенный объект "функциональная спецификация" . И не забывать в "сотруднике" про атрибутивный состав (положение в штатке, расположение рабочего места и т.д.) Если же все отдельные классы сотрудников наследуются от базового, то изменение штатки - убийство существующего объекта и создание нового. Опять же, начальник отдела программистов может быть иле не быть программистом, но менеджером он быть обязан.

[@bohdan9133]

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

[@deniskoroliov1039]

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

[@bohdan9133]

@@deniskoroliov1039 спасибо большое

[@sanyamisharin5039]

Декоратор через наследование что ли делается?

[@МихаилКрамер-н7ш]

Ну вот с повышением уборщицы до программиста, если это разные классы, даже с общим предком, всё равно надо один объект убить, другой создать. Правда, ко мне, как к программисту PHP, это всё не относится :))) У меня объекты так долго не живут :)))

[@lipaylon4967]

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

[@КириллЧе-я5ы]

Есть программа, которая написана на фортране, моделирующая перенос фундаментальных частиц. Софт коммерческий, и широко используется для расчётов. Так вот там тысяч 50 строк кода, не меньше. Она в принципе поставляется с исходниками для возможной ее модификации. Чтобы ее модифицировать, надо перелопатить охрененную тучу кода!!! Зато фортран. С кусками Си. Возможность подключать определенные библиотеки физических величин.

[@МаксимВеснин-ш3р]

Например, у нас базовый класс сервиса, а остальные реализации мы передаем в качестве агрегированных объектов. И вот у нас без наследование точно так же всё работает)) Только удобнее менять) И можно проверять реализации и тестировать их не зависимо от базового класса. А базовый класс не зависимо от реализации так называемых наследников.

[@АнтонСолдатов-щ1т]

Поставлю себе на рабочий ярлык на это видео. Чтобы в любой непонятной ситуации по принципу Наследования, оно было где надо.

[@yupiie1722]

Теперь сделайте видео про Полиморфизм.

[@SergeyNemchinskiy]

kzbin.info/www/bejne/d6rCeKqFhryDqZo

[@Manio1333]

И про полиморфные вирусы!

[@Pasechnik54]

Ну так вообще непонятно, как общую функциональность выделять из классов без наследования (если не брать пример с godObject, про который Сергей в видео рассказал)

[@vitiok78]

Создатель ООП Алан Кэй об ООП: "ООП для меня это сообщения, локальное удержание и защита, скрытие состояния и позднее связывание всего. Это можно сделать в Smalltalk и в LISP." Всё.... Остальное наворотили авторитетные люди. Поэтому, если кто-то говорит о проблемах наследования, то не стоит ссылаться на догмы о трёх принципах...

[@maxlich9139]

позднее связывание через наследование реализуется же

[@shalidor1619]

Только вот какая разница что там думал чел, язык которого не взлетел от слова совсем, а то ооп, которое в итоге позволило создать колоссальные приложения, не похоже ни на йоту на ооп его "создателя".

[@DenisGuitarin]

ad-hoc полиморфизм в каком-то виде без наследования возможен, когда язык позволяет вручную заменять ссылку на метод, например

[@now.7348]

Полезно, но почему не прозвучвла "КОМПОЗИЦИЯ' в контексте альтернативы наследования?

[@SergeyNemchinskiy]

прозвучало. Делегирование

[@notacucumber7617]

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

[@alexeyvoronin4651]

Почему-то программисты, когда приводят пример другого сотрудника, чаще всего упоминают уборщицу. Видимо это тот сотрудник, который чаще всего отвлекает их от работы ... или прокрастинации.

[@dmitriyvaulin]

просто условное разделение по типу "программист" - "не программист". Ну а про начальство просто молчат чтобы не сбиться с темы на обсуждение личности.

[@aleksandrbeloushkin7971]

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

[@dmytrobilyk1539]

Как зовут автора? Нигде не могу найти

[@grommaks]

Композиция решает проблему зарплаты Плюс что делать если программист не сотрудник фирмы, а он фрилансер...что в этом случае делать, как удалить всех наследников? Допустим такой случай. Есть продукт, как у него цену посчитать, сделать метод у базового класса? А что если несколько типов цен будет? Лучше вынести в АПИ класс для получения цены, не зависимо от класса продукта Полиморфизм достигается за счет имплементации интерфейсов...мы же не о C++ говорим, когда там интерфейсы это классы которые нужно наследовать. В Java интерфейсы реализуются, я не наследуются... Наследование хорошо ведет себя когда 100% код твой, а когда приложение многослойное, то наследование сильно связывает логику. Например модуль налогов хочет модифицировать цену, модуль специальной цены хочет вписаться, плюс модуль цен от другого производителя тоже хочет модифицировать... Получается на 1 класс 3 наследника...и кто кого будет наследовать? Представим описанного сотрудника...и вспомним I из SOLID как будет выглядет 10 мелких интерфейсов в этом случае, все на одном классе. В случае с active record все создают модели = таблице, в результате божественные модели получаются, добавить туда еще наследования и получается 5 слойная божественная модель Конечно же, если создавать модельки очень и очень мелкими, бить их на valueObject, то однозначно вариантов для наследования будет существенно больше...но опять же, через композицию классов можно добиться более гибкого и стабильного решения, хотя оно будет существенно сложнее Я говорю с точки зрения e-commerce enterprice, чтобы было понятно, тут специфика такая, что есть ограниченное количество агрегатов, условно до 10 на весь проект, и есть 500-900 модулей которые хотят на эти модели как-то накинуть свою логику... В системах с более тонкими моделями и меньшей модульностью уверн что наследование будет заходить как удобное и надежное решение...

[@yurim7756]

Ого, я стал настолько старым, что начал узнавать что-то новое. Например, в этом ролике услышал, что появилась мода считать, что наследование не нужно ) А патерны, в теории, можно и без наследования делать. Полиморфизм можно сделать указателями на функции (делегатами). Ах, да, я ж сишарп программист. Но на джаве там тоже как-то это можно сделать, подобие. Наверное. Если в классе без наследования хранить поле - указатель на функцию, и его подменять, для разных объектов получая разное поведение, то получится и полиморфизм без наследования, и остальное можно постаравшись, поизвращавщись, получить. Не знаю зачем. Может кто педантично ненавидит наследование и готов страдать за свои убеждения.

[@0imax]

В C++ по сути, так и сделано, через указатели и таблицы виртуальных функций. В более продвинутых языках все подробности убраны под капот, дабы программисту было проще и выглядело красивее. Но вот почитал тут комменты - находятся люди, доказывающие, что можно сделать и БЕЗ наследования, хотя сами, по сути, просто реализовывают его вручную :)

[@vitiok78]

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

[@0imax]

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

[@vitiok78]

@@0imax А почему они "выросли"? Потому что у наследования есть проблемы. При этом отказываться от наследования полностью тоже считаю идиотизмом. Оно нужно там, где оно нужно. Главное - не возводить его на пьедестал.

[@olegkot3362]

Пример с уборщицей Элементарно выносится подсчет зарплаты в SalaryCalculator В целом, наследование нужно, но лучше его избегать ввиду сильного повышения сложности кода с ним

[@erlanibraev]

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

[@SergeyNemchinskiy]

Элементаррно все методы выносятся в общий класс... Черт, я ровно об этом и рассказал в видео.

[@olegkot3362]

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

[@erlanibraev]

@@olegkot3362 Даже в рамках одной и той же штатной единицы начисление ЗП может быть разным. И вычеты могут быть разными. Это я не говорю о премии и пр. Доп выплатах.

[@liravesnovaya242]

В этом плане очень и хороши интерфейсы с композицией. Создаем интерфейс SalaryCalculator. Делаем разные классы калькуляторов, а в классе сотрудника заводим атрибут SalaryCalculator и метод расчёта зарплаты через этот атрибут. И при повышении уборщицы до программиста просто меняем SalaryCalculator уборщицы на программиста.

[@Dimonina]

наследование использую только в написании каких-то системных вещей или системных (не связанных с конкретной бизнес логикой) либ для приложения, где логика понятна и вряд ли поменяется. практика показала, что наследовать объекты реального мира, то есть брать данные из ТЗ и делать из этого какую-то иерархическую структуру как правило приводит в перспективе к говнокоду и усложнению поддержки, из-за того что бизнес меняется очень быстро. Сегодня программист - это сотрудник, завтра он уже "удаленный сотрудник", а еще вот есть "удаленный на полставки". В итоге сегодня мы под ТЗ делаем красивую стройную модель, а завтра малейшее изменение приводит к тому, что нам надо рефачить все дерево и все зависимые от либы проекты. Какой выход? под конкретные проекты по-разному придумываем, но часто стараемся делать так, чтобы переиспользование кода было минимальным как раз. Если у меня есть похожая логика, я ее не выношу в отдельный модуль или библиотеку, а прямо копипащу с небольшими изменениями. В итоге новый человек на проекте или я через год, когда нужно будет логику поменять, увидит, что определенный метод используется всего в 1 или 2 местах в коде и описывает небольшой кусочек (SRP привет), чем код, который растянут на 10 наследников и еще переопределен в куче мест. Не утверждаю, что наследование плохо, просто на практике оказалось выгоднее стараться обходиться без него, ну или скорее не совать его везде. П.С. у S0ERа есть хорошее видео на тему копипаста кода. согласен с ним, что копипаст, это не всегда зло. Если логика просто похожая, но логически другая - здесь копипаст это не дублирование кода, так как логически эти методы про разное и похожий код не является дублированием.

[@yuriy.kostenko]

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

[@Dimonina]

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

[@МаксимМалышев-м6ы]

@@Dimonina В чем проблема вынести подобные алгоритмы работы в отдельные классы-стратрегии? Как раз-таки наследование и нужно для того, чтобы решить описанную тобой проблему. Выносишь поведения "удаленный сотрудник" и "сотрудник на полставки" в отдельные классы-стратегии и внедряешь зависимость в свой класс. Если в будущем надо будет добавить еще какой-то тип сотрудника, ты просто расширяешь свой код через наследование, а не изменяешь уже разработанный и протестированный, и не пишешь огромную пелену кастов и условных операторов для определения типа сотрудника. Если возникла необходимость комбинировать, например "удаленный сотрудник на полставки", то оборачиваешь это все в декоратор. Я не вижу тут никакой проблемы наследования, а только типичную ситуацию, в котором оно полезно

[@Dimonina]

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

[@yuriy.kostenko]

@@Dimonina по моему мнению как раз именно наследованием мы описавыем реальный мир. И свойства обьектов в реальном мире очень даже проверяются. Типичный пример касса в магазине. Касса работает с людьми, а не с покупателями (потому что еще не факт что человек станет покупателем, вдруг его свойство "количество денег" не достаточно для того что он приволок на кассу) и проверяет много свойств, в том числе If(покупает алкоголь && свойство Возраст > 18) OK else() "а ну брысь!" Как-то вот так. )

[@shmaltorhbooks]

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

[@Mr43046721]

Да. После лабораторок на Паскале и Си/Си++ и упором преподов на функциональщину, смотря на ООП в C# или той же Java задаешься вопросом, господи, это гениально. Интересно, на смену ООП придет ли когда-то другая парадигма? P.S. Сергей, может поразмышляете видосик на тему того, умрет ли когда-то парадигма ОПП?) Но, наверное это уже совсем другая история...

[@dmitriyvaulin]

будет всë, ибо ложка к супу, лопата к огороду, а экскаватор строителям. Тру.

[@yurim7756]

Конечно, придет. Я думаю придет. Эта парадигма придет и уволит всех программистов, потому что они уже будут не нужны. Надеюсь, что нескоро.

[@dmitriyvaulin]

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

[@yurim7756]

@@dmitriyvaulin Так я про сильный ИИ. Когда человек будет тем самым дураком )

[@dmitriyvaulin]

@@yurim7756 Сильный ИИ можно создать хоть сейчас. Главное дать ему мотивацию и сенсоры. Если что могу поучаствовать в разработке.

[@АлексИванов-ы9ч]

да как же так - полиморфизм без наследования не возможен? возможен! может, конечно, в java по другому, но вроде мы обсуждаем саму концепцию ООП)

[@РайанКупер-э4о]

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

[@yuriy333]

То есть как группы?

[@РайанКупер-э4о]

@@yuriy333, множества объектов, реализующих методы. Группы - это другая штука.

[@ramach6552]

Сергей (надеюсь, что все ещё Немчинский) нужно видео про все 3 элемента ООП)

[@maxlich9139]

так он, кажется, про все рассказывал

[@ДенисКолчев-щ4с]

Ого. Я понимаю о чем речь 😄

[@imhere1.]

я тоже понял но не думаю что всё 🤧

[@alexeyvoronin4651]

Есть такой признак неиспользования полиморфизма и наследования: это наличие больших, разветвленных, иногда многовложенных switch/case или if/then/else .

[@0imax]

А для приведения этого безобразия в человеческий вид есть несколько паттернов для разных ситуаций)

[@ЮрійАндрашко-у8я]

В языках где объекты мутабельны наследование не нужно. Да и в старых языках в большинстве случаев наследование можно заменить на делегирование.

[@РоманДейкаловский]

Сергей, круто. Вроде, ооооп понял.

[@vh3104]

А как мы можем не использовать наследование, когда есть класс Object?

[@corey4448]

А разве полиморфизм это не обеспечение единого интерфейса типам?

[@Yurec10]

Само слово "наследование" неудачное для описания данного явления. Котэ наследуется от родителей и является таким же котэ, как предки. Если в природе было бы наследование как в программировании, то к котэ можно было прикрутить крылья или копыта, заменить метод мяуканье на лай (@Override). Американцы правильно называют extend, то есть класс не наследуется, а расширяет.

[@СергейКондратенко-о9ц]

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

[@0imax]

Можно, но сложнее, и выглядит не так красиво.

[@artursveshnikov7668]

видео о наследовании extends видео от Сергея Немчинского))

[@ivyivy5670]

Я вот рассматриваю Java, как будущее хобби и ещё не написал ни одной серьёзной программы в жизни. Но с каждым подобным роликом т.н. "порог вхождения" для меня становится существенно ниже. Спасибо.

[@JohnDoe-tm1rv]

Какое наследование, если главный язык сейчас это JavaScript?

[@JohnDoe-tm1rv]

@Нахуй Радикальных Гомофобов Это вы эти прототипы имеете в виду, когда можно у обьекта на ходу поменять предка или взять одну функцию открепмть от одного обьекта и исполнить ее в контексте другого... такое себе наследование :)

[@empty7892]

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

[@otkwass]

swift позволяет писать расширения для протоколов ( которые интерфейсы ) и наследование в данной ситуации не нужно вообще.

[@13Balck]

Как насчет того чтобы раскрыть такое понятие как плохой программист?

[@kannsky8812]

вот это действительно годно 👍

[@АртурХаратян-ж6б]

Почему 3 принципа? Что стало с абстракцией?

[@acrrono]

Котлин: интерфейсы со свойствами и дефолтными методами. Немчинский: Наследуемся!

[@artursveshnikov7668]

Сейчас в c# эту хрень запихали

[@acrrono]

@@artursveshnikov7668 наследование тоже когда-то было хренью

[@СергейПресняков-о4р]

Звучит как будто в котлин изобрели абстрактные классы

[@acrrono]

​@@СергейПресняков-о4р да, звучит именно так, для людей которые не понимают чем класс отличается от интерфейса

[@igorgrischenko6518]

8:33 *Как ты угадал, волшебник!?* **плачет**

[@tchrmagic2943]

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

[@kimoterru503]

Наследование в Java очень удобная вещь.

[@Homeleonchik]

Бомбанул знатно, тот, кто по прежнему наш)

[@vatakiller]

Уборщицу повысили до программиста - как входят в IT js'ники.

[@ashimov1970]

🤣👍

[@max_mgtow]

Про голубя помню картинку 🤣👍

[@denisoleksyuk5346]

так и не понял для чего использовать наследование?

[@antonseredin117]

Блин, насколько точно! Мы все любим говнокодить!

[@ИнякинАлександр]

Опять двадцать пять! И снова у нас базовый класс "Жывотное" с методами "есть", "спать", "ходить", "летать" и "гадить" от которого унаследованы все виды животных. Уже лет двадцать программистов тычут носом в этот пример и говорят: "Так делать не надо! Это худший пример ООП". За такие примеры уже пора пинать больно ногами в живот.

[@alexandernikolaev174]

Критикуешь? Предлагай! Свой идеальный пример в студию! А мы уж тут оторвемся. Мы ж любители искать соринки в чужих глазах.

[@shalidor1619]

то-то лет двадцать не код, а сплошные фекальные сталактиты везде

[@melomane-dota]

привет всем !!

[@konstantingeist3587]

Автор часто апеллирует к тому, как плохо писали в 80-х без наследования, но сам застрял в 90-х. Тогда была повальная мода на вариант ООП с наследованием, и Джава дитя той эпохи (как и C++). Если всю жизнь пишешь на Джаве, в которой из инструментов только единичное наследование, то мозг атрофируется и даже не может предположить, что может быть что-то еще. Как говорится, если в руках молоток, то все кажется гвоздями. Например, полиморфизм можно делать без наследования с помощью 1) structural typing + embedding 2) pattern matching на algebraic data types 3) entity component system 4) multimethods 5) стратегии через интерфейсы 6) traits как в Rust. Конечно, в Джаве ничего этого нет, или требует много писанины. Вообще, при наследовании чаще чем всегда встречается архитектурная дичь вроде приведенного в пример Employee::calculateSalary(). Это не ответственность сотрудника определять какая у него зарплата. Этим занимается бухгалтерия, и тут нужен поиск стратегии на основе данных сотрудника. Т.к. обязанностей/бонусов у сотрудника может быть несколько и при расчете зарплаты нужно учитывать особенности бухгалтерии, которые являются ответственностью бухгалтера (отпускные, больничные, авансы, премии и т.д.). Это полная дичь совать такую логику в класс сотрудника. Автор скорей всего назовет иное "процедурным программированием" (а значит, плохо), но вариант использовать внешний сервис расчета более архитектурно верен и более масштабируем (как с точки зрения рефакторинга, если добавляются новые правила; так и архитектуры at scale, т.к. сервис расчета можно вынести в отдельный микросервис и масштабировать независимо, напр. добавить несколько воркеров-инстансов)

[@shalidor1619]

И потом фиксить баги годами в миллиарде файлов и репозиториев, вместо фикса одного единственного класса

[@vitiok78]

"Реальный мир полон наследования..." Что-то я не встречал в реальном мире абстрактных капибар )))

[@ievgenk.8991]

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

[@vitiok78]

@@ievgenk.8991 У меня нет такой оптики, к сожалению, чтобы так присмотреться ))

[@ievgenk.8991]

@@vitiok78 Видимо такую оптику выдают только самым трушным и преданным адептам ООП)

[@vitiok78]

@@ievgenk.8991 Они её автоматически наследуют же-ж

[@ruslan4598]

ты и реальных не встречал скорее всего. но свойства её описать можешь. магия

[@FigisBadralov]

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