Принципы ООП. 2. Наследование
Вставка
- Опубліковано 4 чер 2020
- Второе видео из небольшого цикла - Принципы ООП. Сегодня поговорим про наследование!
Курсы для новичков:
JAVA - bit.ly/36UEHbo
JAVA Start - bit.ly/2XOKk6J
Инструментарий JAVA - bit.ly/2MhgIcM
Automation QA (Java) - bit.ly/2XThVfB
ANDROID - bit.ly/2ApdXDz
C#/.NET - bit.ly/3gIDTe6
PYTHON - bit.ly/2BfpJRh
FRONT-END - bit.ly/2TZn9FH
WORDPRESS Developer - bit.ly/2MpK7kV
SALESFORCE Developer - bit.ly/2zSfS3t
UI/UX дизайн - bit.ly/3cq6XDC
Project management - bit.ly/2MlfEEY
Обучение на проекте - bit.ly/3cnL5sA
Продвинутые курсы для состоявшихся девелоперов:
GRASP and GoF Design patterns - bit.ly/2yTtFGJ
Enterprise patterns - bit.ly/2XWPePg
Сайт Foxminded: bit.ly/2Xp1V60
Foxminded в ФБ: / foxmindedco
FoxmindEd в Instagram: / foxminded.ua
Foxminded в VK: foxminded
Мой Telegram: t.me/nemchinskiyOnBusiness
Мой блог: www.nemchinsky.me
🦊Новый поток Advanced курса Enterprise Patterns стартует уже 1 февраля 2023 года ❗
Регистрация - go.foxminded.ua/3XGhXov
Вообще никогда не писал комментариев к видео в Ютуб. Хочу вас поблагодарить за ваши труды. Очень нравится ваша манера объяснения, ваш раскрепощенный формат, будто вы объясняете не просто студенту, а своему другу. Я C# разработчик и уверенно говорю, что мне очень полезно порой посмотреть и послушать вас (даже интерес всегда увеличивается к программированию). Конкретно сейчас смотрю ваше видео, залитое 1 марта 2016 "Чистый код", а пишу под этим видео, чтобы вы заметили комментарий (м.б. алгоритмы ютуба владельцу канала показывают в первую очередь писанины людей под самым свежим видео). Вы делитесь довольно интересный и актуальным опытом (особенно про индусов из видео "Чистый код"). Большое спасибо, что вы помогаете нам улучшать себя, что делитесь достаточно ценным опытом.
Спасибо за наводку, включу пожалуй плейлист "чистый код"
А вы про какое? Там 3 плейлиста Clean code
@@imhere2264 особенно по этому я удивлен столь быстрому ответу. Спасибо!
2016 был 7 лет назад, охренеть
вы очень интересно рассказываете) особенно улыбнулась от "по наркоманский" ! спасибо!!
Ролики от Немчинского как всегда понятно, по делу и есть интересные моменты . Спасибо, Сергей!
Спасибо! Серия коротких учебных видео - это то, что нужно. Коротко, ясно, простыми словами. Формат - супер! Кстати, толстовка крутая )
спасибо)
Единственное не понял вас Сергей Немчинский зовут или нет, расскажите об этом в следующих видео)
private static string name = "Сергей Немчинский";
@@malikvalley final
@@BrodrickStreams я ваш финал не понимать, я C#
@@malikvalley скорее public
никчемский
Уже жду ролик про полиморфизм "простым языком". Лайк
куда ж без него)
На почитай и никого никогда не жди, ибо такими темпами если учить , то на учебу java, жизни не хватит) vertex-academy.com/tutorials/ru/chto-takoe-polimorfizm-java/
очень здорово объясняете) все сразу понятно!)
Всё так, спасибо за выпуск
Сергей, со своей колокольни скажу (так сказать взгляд снизу) что вы растёте как блогер точно так же как и люди которых вы в том или ином виде обучаете. Вы явно на правильном пути))) Хотя как тут уже замечали - вполне возможно что на примерах кода было бы понятнее для новичков, а то услышав бы я это всё тогда когда не вообще не понимал что это такое - не факт что бы что-то внятно понял.
thanks, good explanation
Хочется услышать от вас про VR и AR, на чем пишут, и какое будущее в этом направление
Дуже дякую!
Расскажите про ковариантность и контравариантность, хотелось бы услышать
Надо бы готовить схемы /слайды к таким темам.. А то ООП в воздухе обьясняешь и в этом видео и в предыдущем! (надеюсь у вас на курсе это есть)))
Спасибо!
гениально! даже я понял
Расскажите пожалуйста про делегирование. Вы о нём лишь всколь упомянули
Как я понял это (могу ошибаться).
• Наследование : присоединяешь ВСЕ поля, свойства и методы к своему новому классу-наследнику.
• Делегирование : присоединяешь ТОЛЬКО ТЕ поля, свойства и методы к новому классу (уже не наследнику), которые тебе требуются.
Пример делегирования на C# :
Console.WriteLine("Это метод класса Console. Да-да, Console - это класс");
@Белояръ Чайка если можете, оцените правильность моего ответа сверху. Мне тоже интересно что это именно и правильно ли я написал.
@Белояръ Чайка всё равно ничего не понял. Очень много терминов, которых человек учащий ООП впринципе может не знать.
@Светозар Родов шта? мвс то тут причем, может композиция, а?
Сергей, пожалуйста, про полиморфизм с примерами на коде.
List a = new ArrayList;
List b = new LinkedList;
Да да да. Немчинский, спасибо! Подтвердил мои опасения и сомнения. Иногда видишь что здесь явно нужно наследование но много где пишут что использовать надо только композицию, что наследование нарушает инкапсуляцию. Теперь моих сомнений стало меньше
@Белояръ Чайка а как быть если у классов есть общий сценарий но разные типы?
Например сценарий
Собрать запрос
Отправить
Залогировать
И это выполняют 10к классов.
Я вынес общий сценарий в абстрактный класс
Полиморфно определил билдер запросов и логер
И наследовался от этого класса - где каждый наследник передал свой билдер запросов и логер, при этом сценарий определяется родителем(с возможностью переопределения конечно)
спасибо!
Расскажите какими по вашему мнению будут языки программирования через лет 10-15. Как они изменятся, Будут ли появляться новые узконаправленные языки или наоборот языки будут стараться покрыть как можно больше областей применения ?
2:27 с точки зрения логики он и расширяет, и сужает - смотря о чём мы говорим, т.к. в логике понятие имеет 2 характеристики - информация и объём, которые объединены обратной зависимостью - при расширении информации сужается объём и наоборот.
спасибо
"Интерфейс является классом" - сейчас где-то в мире поперхнулся один Егор Бугаенко :)
Егор Бугаенко как адепт строгого объектного дизайна даже на пушечный выстрел не подошел бы к данному каналу. Особенно после фразы "основная мощь ООП - наследование".
Полиморфизм не работает без наследования? как на счет "утиной типизации"?
Зробіть по SOLID відео
Есть целый плейлист
Сергей, спасибо большое за видео.
Скажите, пожалуйста, а почему вы абстракцию не считаете принципом ООП?
ua-cam.com/video/9GdtWiovvIQ/v-deo.html
Вместо слов расширяет/уменьшает(2:30), можно использовать термин "уточняет". Наследник уточняет родительский класс
"Истинный Полиморфизм"?? ) Это сильно. Но об этом в другой лекции.
.
Интерфейс -- это Класс!!?? Это еще сильнее.
.
Не смотря на то, что очень часто Интерфес и Чисто Абстрактный Класс взаимозаменяют, все же Класс и Интерфейс -- это два разных понятия.
.
Класс -- похож на свет! ) Т.е. имеет двойственную "природу". С одной стороны -- это совокупность объектов, обладающих определенными структурой и поведением, а с другой стороны -- это механизм описания такой структуры и поведения, а также механизм управления совокупностью объектов из класса, как одинм целым (т.е. на уровне совокупности).
.
Интерфейс -- это независящий от внутреннего поведения Класса способ взаимодейстия с его экземплярами и Классом, как отдельной сущностью.
.
Когда создается Класс -- определяется Интерфейс. Например, в C++ даже другого способа определить Интерфейс нет. Вместе с тем, создаение интерфейса само по себе не приводит к созданию Класса, т.к. поведение экземпляров, равно, как и поведение Класса как сущности, не описывается.
.
Собственно, унаследоваться можно от Класса, а Интерфейс можно реализовать. В этом смысле, два Класса, реализующие один интерфейс могут быть использованы в полиморфном алгоритме, но при этом эти два класса не связаны наследованием (т.е. у них не будет общего предка)
.
Наследование само по себе кроме "асбтрактного" описания еще имеет и программную реализцию: это, либо VMT, либо цепочки прототипов. Так вот, у Классов с общим предком, VMT должны иметь непустое и не тривиальное пересечение (противное будет обозначать тотальное переопределение наследуемого поведения, а значит неуместность использования наследования). В случае с цепочками прототипов Классы родственники всегда будут иметь непустую и нетривиальную часть цепи общих "предков".
.
Нетривиальность -- это то, что не связано с базовым классом: во многих языках такой класс есть и наследование от него происходит неявным образом, и в этом смысле все Классы в языке родственны.
.
VMT - virtual methods table - картеж (или эквивалентная структура данных) с ссылками на виртуальные методы в структуре Класса (такое себе статическое поле), используемая для опредление того, метод какого именно класса связан конкретно с данным экземпляром (все экземпляры Класса при конструировании получают ссылку на VMT своего Класса). Если в языке есть динамическое наследование, то VMT может содержать ссылку на VMT родителя (и по сути превращается в цепочку прототипов). Если язык поддерживает только статическое наследование, то VMT имеет плоскую структуру и формируется в момент компиляции программы.
.
Интерфейсы, в свою очередь, VMT не имеют. Интерфейсы определяют струтуру VMT, но не значения в ней. В частности поєтому, Интерфейсы при компиляции программы создают, либо только мета-артефакты, либо не создают артефакты вообще.
Про расширение/сужение.
Это же логика уровня средней школы - чем шире содержание понятия, тем уже его объём, и наоборот.
Содержание понятия - это знание о совокупности существенных признаков класса предметов.
Объём понятия - это знание о круге предметов, существенные признаки которых отражены в понятии.
Вот и получается, слово extends расширяет содержание понятия (класса, абстрактного типа данных), но одновременно с этим сужается его объём.
красиво сказал
Про это есть эстонский фильм 2007 года «Класс»
я думаю более правильно понимать, что другой класс реализует интерфейс , потому что по дефолту в интерфейсе не указывается реализация свойств и методов. не знаю про java ,но в c# функция дефолтная реализация интерфейса в интерфейсе появилась в 8.0 версии. и для её использования надо явно апкастить объект к нужному типу интерфейса.
в java тоже есть default методы в интерфейсе.
круто - даешь еще
обязательно)
Я бы назвал это видео: "Нужно ли использовать наследование" или что-то такое. Это для тех, кто уже знает об этом принципе
Наверное ещё стоит сказать, что, проверяя классы на "is a", нужно чтобы они были только "is a", без всяких ограничений, в духе "этот класс - это вот этот класс, только с такими вот особенностями...". В видео про LSP в SOLID был хороший пример с прямоугольником и квадратом на эту тему
Читали ли Столярова А.В. и его Введение в профессию. Азы программирования?
Имеется ввиду, что наследование это "зло" тогда, когда наследуются от класса который может порождать свои сущности и когда потребуется допилить функционал родителя, это с большой вероятностью сломает дочерние классы и приходится так же их переписывать, либо переосмысливать и менять иерархию классов, что никак не помогает в работе и уж тем более не экономит время и деньги. А вот если класс имлпементирует интерфейсы, то все перечисленные Вами проблемы решаются. Но это все еще раз подчеркивает что у джавы далеко не совершенная система типов.
Если изменения в родительском классе сильно ломают дочерние классы, то есть вероятность, что они вообще не родственники, либо архитектура построена неправильно. Но, если отказаться от наследования и делать через имплементацию интерфейсов, то будет куча дублирующегося кода, доставшегося от базового класса.
@@0imax >Если изменения в родительском классе сильно ломают дочерние классы, то есть вероятность, что они вообще не родственники, либо архитектура построена неправильно
Но ведь изменения нельзя предугадать, каким бы замечательным архитектором ты ни был. Поэтому архитектура через наследование плохо масштабируется. Сегодня сущность выглядит как "X is a Y", завтра отдел product development приходит и говорит, что в следующем релизе сущность X будет иметь свойства, которые плохо натягиваются на Y (или наоборот) -- удачи всё это или переписывать, или пытаться впендюрить кривые костыли, чтобы иерархию оставить.
@@0imax >если отказаться от наследования и делать через имплементацию интерфейсов, то будет куча дублирующегося кода, доставшегося от базового класса
В этом и суть делегирования: для избежания дублирования просто делай вызовы в сторонний класс, который иерархией никак не связан с текущим. В случае изменения спеки (особенно когда сущности начинают сильно разъезжаться в поведении) тривиально поменять вызовы на другие методы/классы, так как делегирование приватное, а во многих языках типа Java наследование публичное, поэтому пришлось бы не только рефакторить классы, но и трогать код всех клиентов.
Значит нужно стараться создавать абстрактные классы? Чтобы избежать подобных случаев.
P.S. Я только начал изучать Java.
@@konstantingeist3587 ну если предметная область такая, что объекты то "is a", то нет, а классы всунуты в одно дерево наследования - то тут можно лишь посочувствовать))
Если внесение изменений в родительский класс, ломающее дочерние, случается регулярно, то придётся хорошенько рефакторить это всё дело, разнося классы по разным веткам наследования, дабы будущие изменения коснулись только тех, кого надо, либо до отказа от наследования вообще. Тут уже зависит от конкретной ситуации.
А как насчет полиморфизма на основе интерфейсов? Мы можем имплементировать в классах сотрудников интерфейс с методом getCountForBlabla и отправлять этот интерфейс на вход какого-нибудь метода (как тип данных) класса для расчета больничных/диспансеризации/etc, который бы всех считал. Какие проблемы есть у такого подхода? Спасибо.
Некуда будет сложить общий для этих классов код.
Не совсем понял, что имеется ввиду под "полным отказом от наследования" и "возврату к процедурному программированию из-за отсутствия полиморфизма"? Отказ только от классов, или от классов и интерфейсов? Обычно когда отказываются от наследования, то имеются ввиду только классы, интерфейсы остаются. А раз так, то и полиморфизм никуда не исчезает.
Ещё бы понять что такое делегирование простым языком))) Мне лишь приходит что-то из разряда "делегат", "ссылка на метод" и пр.
Если совсем грубо, то для реализации какой-то функциональности внутри класса А заводится класс В, который выполняет эту функциональность, а класс А просто вызывает его методы.
Неправильный подход - отнаследовать класс А от класса В, чтобы класс А получил методы класса В, и затем их вызывал сам у себя.
Не внутри класса А заводится класс В, а объект класса А параметризуется объектами класса В. Типа:
public class B {
public int getInt(){ return 0; }
}
public class A{
private B b;
public int getInt(){ return b.getInt(); }
}
делегирование - это передача своих обязанностей другому субъекту/объекту. Это как подрядчики и субподрядчики в реальной жизни.Тебя просят что-то сделать, а ты это перекладываешь на другого человека, просишь его сделать это за тебя)
Сергей, куда задавать вопросы?
Если в комменты, то вопрос не по теме видео:
На практике как пользуются гитом (или аналогами)? В плане через консоль или с помощью ide? Некоторые ide позволяют подключиться к репозиторию и управлять ветками, коммитами и всеми необходимыми вещами. Но, слышал, что это не очень хороший тон, и лучше пользоваться напрямую git bash (или аналогами). Что Вы думаете насчет этого?
А что тут думать, на этот вопрос Сергей уже не раз отвечал, нужно просто сесть и выучить, основы гита учатся за день-два
Мне нравится Git Extensions. На работе посоветовали, с тех пор не вижу особого смысла сидеть в консоли гита. Хотя, конечно, если если есть шанс, что придётся юзать Git чисто из консоли, то явно проще учить основы, команды и как его красиво настроить, чтобы бранчи нормального видеть и историю коммитов.
@@tolik8 не совсем понял. А почему такой ответ? Чем обоснован?
Сергей отвечал? На канале есть видео? Хорошо, поищу
@@AllWayToDeath сори, мой косяк, я очень бегло прочитал вопрос и подумал что вопрос: пользоваться гитом или нет
@@tolik8 ааа, ахах, бывает:)))
Сергей, а можете рассказать, почему Абстракция - не принцип ООП?)
Потому что всё программирование - абстракция, и ооп тут никак не выделяется :)
Сергей, ну не серьезно. Где схемы? Одной говорящей головы не достаточно, чтобы такую тему раскрыть.
Пример с сотрудниками в корне некорректен. Если бухгалтер и инженер не являются наследниками класса Person или Employee, совсем не обязательно, что нужно их перебирать как три отдельных списка. Достаточно реализовать интерфейс и приводить их к интерфейсу.
Более того, если они не разделяют какой-то базовой общей логики и состояния, лучше использовать интерфейс.
GOF-паттерны используют в своих примерах наследование, так как на тот момент не нахватали граблей, и это был самый привычный пример переиспользования кода.
Не затронута главная тема, почему не стоит использовать наследование: для наследования класс нужно внимательно проектировать, чтобы не сломать логику работы его наследников. Это подробно рассказано в 4-й главе у Джошуа Блоха, которую читал каждый Java-программист, старше джуниора.
Интерфейс - частичный случай класса, получиться то же наследование.
@@user-xc5cx7lh4l Термин "Наследование" употребляют с интерфейсом, но это не значит, что класс - частный случай интерфейса. Класс подразумевает под собой наличие полей и состояния, коих нет у интерфейсов. Потомок класса и реализация интерфейса, это два разных понятия, и это не мелкая неточность, это ошибка.
В энциклопедии британнике нет чёткого понятия базовых принципов ООП, из-за этого часто бывают споры, зачастую, бестолковые, но пример всё равно тяп-ляп)
@@liamsmith7052 Всё верно. Если у классов сотрудников нет общего кода - делаем через интерфейсы, если есть - через наследование. Обычно он всё-таки есть, поэтому пример вполне норм.
А если пишем на C# то в интерфейсе можем писать приватные методы и базовую реализацию...
Так и не понял чем этот интерфейс будет отличаться от класса, кроме возможности множественной реализации
@@grommaks отсутствием возможности создавать экземпляры и хранить их состояние.
А если использовать вместо наследования классов, имплементацию интерфейсов?
Наследование и имплементация интерфейсов используются для разных целей. Можно и вместо ложки пользоваться вилкой, но...)))
@@0imax Неверно, частично они совпадают. У интерфейса и abstract class много общих паттернов использования. По факту в Java их отделили тупо чтобы реализовать множественное наследование, сгладив проблемы diamond problem
@@konstantingeist3587 В том-то и дело, что частично. Но в последнее время какая-то тенденция избегать наследования даже там, где оно явно должно быть. И начинается: отдельный класс с общими данными, с общими методами, перегонка данных туда-сюда, полиморфизм на интерфейсах и прочие костыли, хотя можно было просто написать extends, и от этого бы никто не умер :)
Можно использовать методы у супер класса который общий для всех и объявлять новые методы которые присущи только этому подклассу.
Все против именно наследование между классами, пример который Вы привели, спокойно наследуемый по Интерфейсам
Но в таком случае общий код некуда будет положить.
@@0imax Общий код можно положить в сторонний класс. Часто вообще бывает, что "общий код" высосан из пальца и не является какой-то осмысленной бизнес-логикой, а просто парой-другой похожих строк тривиального инфраструктурного кода, который можно спокойно продублировать, но из-за которого развели сложную иерархию в погоне за "code reuse". Есть вот premature optimization, тут нужен термин вроде premature code reuse.
@@konstantingeist3587
"Часто вообще бывает, что "общий код" высосан из пальца"
В говнокоде всякое встречается))
@@0imax Ну я вот давно замечаю, что у многих программистов есть такой условно-безусловный рефлекс, при котором завидев две-три одинаковых строчки из разных мест возникает горячейшее желание сделать "code reuse" и создать какой-нибудь нелепый общий метод, иначе ведь дублирование! В итоге со временем общий код обрастает говном и костылями, так как два оригинальных класса в коде начали различаться из-за новых требований, и всё это ещё супербажно т.к. меняя что-то в общем коде под новый кейс для одного класса/функции ненароком меняется поведение для другого класса-клиента и т.д. Поэтому если и выводить в общий код, то только если это осмысленная логика, которую сложно повторить -- и в таких случаях лучше бы подошёл отдельный самодостаточный класс, а не костыли вроде protected-методов в базовом классе или утилитные классы-помойки.
Часы и очки как у Сереги)))может это значить что я тоже программист??))))
это комбо-набор, вместе дают + 100 к интеллекту и +50 к разговору) А да, еще и харизму повышает на 80 пунктов))
надеюсь на ваших курсах объясняют лучше.....
У меня вопрос, а мне на собесе в бубен не дадут, если я скажу что интерфейс это класс?
Зависит от языка. Например, в C++ нет такой языковой структуры, как интерфейс. И роль интерфейса берут на себя классы, при этом не особо даже принято говорить "интерфейс", принято говорить ABC (Abstract Base Class). Есть другие языки, где интерфейс - это языковая конструкция, которая отличается от класса, тем, что от интерфейса нельзя наследоваться.
Использую композицию, и плюю на наследование
Посмотрел 1 раз и понял 10-15% объяснений -) Посмотрю еще раз 10 - наверняка процентов 30 ещё дойдёт
Обалденно когда на курсах для новичков лектор густо сдабривает свою речь специфической профессиональной терминологией, чтобы все слушатели почувствовали себя идиотами, хотя можно было всё просто объяснить на примере лап и хвостов у рыб и змей.
А как его теперь зовут этого мужика?
У семьи есть наследование значит и у кода должно быть наследование
У многих королевских семей не было наследования, особенно после расстрела царской семьи.
@@imho10 всегда найдётся исключение :D
Полностью отказаться от наследования это, конечно, зашквар. Не зря столпы программирования говорят aggregation over inheritance, но не aggregation instead of inheritance. Т.е. следует предпочитать делегирование наследованию.
@Светозар Родов когда за тебя - это делегирование, а наследование - когда ты выполняешь всю ту работу по дому, что и родители, но ещё и в школу ходишь :)
@Светозар Родов В жизни всё так, но в программировании обычно всё через ж.. Как с прямоугольником и квадратом)
1C ТАКОЙ КОД БЕЗ НАСЛЕДОВАНИЯ.
подскажите пожалуйста, как родительский класс персон поможет понять , работает человек в офисе или нет ? нипонятно
Очень просто, любой работнмк может работать в офисе или не в офисе, значит свойство "место работы" логично прицеить к родительскому классу работник, а не к конкретному, инженер, бухгалтер
никак не запомню как вас зовут
🔔Можно ли в конструкторе вызывать сеттер? В интернете мнения разделяются 50 на 50.
Заранее спасибо
По факту в конструкторах не стоит вызывать собственные методы вообще, т.к. во-первых, реализации методов могут ссылаться на ещё не проинициализированные данные (т.к. конструктор ещё не завершил работу), а во-вторых, ситуация усложняется наличием виртуальных методов -- в некоторых языках до завершения работы конструктора будет вызван виртуальный метод базового класса, а не текущего -- что может привести к порче объекта.
@@konstantingeist3587 сеттер не ссылается ведь на какие-то данные. Он лишь устанавливает значение, если оно подходит условиям.
Но как тогда инициализировать данные по условиям, чтобы я не мог ,например, атрибуту "размер" присвоить значение -10 ?
@@avazart614 то есть каждый сеттер обязательно должен бросать исключение, правильно я понял? И если в сеттере находится лишь инициализация атрибутов с проверкой условий, то я могу в конструкторе вызывать сеттер? Как в серьезных проектах решается проблема проверки данных при вызове конструктора?
@@agentr227 Сеттер вполне может ссылаться на данные. Например, у нас есть инвариант "ширина прямоугольника не может быть больше высоты". Польза сеттеров не столько в сокрытии переменной (сокрытие это не самоцель), сколько в возможности валидации инвариантов (бизнес-правил). Т.е. в сеттере установки ширины мы должны провалидивировать инвариант, а сделать мы это можем в нашем случае прочитав значение "высота" и сравнив с новым значением ширины. И если вызывать сеттер в конструкторе, то это не очень безопасно, т.к. объект по факту не до конца ещё проинициализирован, а метод ожидает, что он уже полностью сформирован (т.е. значение высоты может быть ещё не установлено, тогда наша валидация была некорректной).
@@konstantingeist3587 ну почему, если конструктор сложный, то все можно распихать по методам. Хотя абстрактные (они же вроде бы виртуальные) методы в конструкторах... не знаю... насколько это нормально!?
ни че не понял... На каком языке говорили?
Ух сколько лишних проблем в языках со строгой типизацией. В языках с "утиной" типизацией с этим намного проще: взял всех сотрудников и сунул в общий список не зависимо от "класса".
а ещё кто то напихал туда "пельмени" и "самолёты" ) , а ты и думай что на выходе делать.
@@syberskyer А на выход подключаем мясорубку, которая всё это перемалывает в инты)))
В языке Go строгая типизация, но при этом есть утиная типизация в плане приведения структуры к интерфейсу -- если структура ведёт себя как утка, то она утка :) При этом все типы известны на стадии компиляции заранее, что экономит кучу времени. Очень удачный компромис. Это скорее в Java просто излишняя бюрократия/формализм.
@@avazart614 В Go нет шаблонов, хотя сходство определённое есть с шаблонами в C++ в плане статической утиной типизации (в С++ если мы используем метод с сигнатурой S, то шаблон скомпилируется для любого типа T, у которого есть метод с сигнатурой S). Но в Go там немного другое, и попроще. В Go если структура имеет метод foo(int, int), то она автоматически реализует любой интерфейс, определяющий метод foo(int, int). Не нужно писать "implements" как в Java, и это решает множество архитектурных проблем, т.к. можно сделать так, чтобы структура из другого пакета реализовала твой интерфейс, даже не зная, что он существует (напр. полезно когда мы не владеем кодом из стороннего пакета; в Java пришлось бы писать адаптер-класс; также полезно для более элегантного dependency inversion -- т.к. благодаря такому подходу нет строгой привязки классов друг к другу).
Программируйте на уровне интерфейсов а не на уровне реализации)
Бывает что и интерфейса то нет, сразу реализация. Тот-же Thread в Java - это ни**я не интерфейс. Да и частенько нужна именно конкретная реализация, а не некий абстрактный интерфейс. Типа там какой-нибудь класс SomeEntityMySQLDAO и его уже не параметризуешь абстрактным DAOConfig, а прямо указываешь, что он хавает MySQLDAOConfig, иначе какой-нибудь чудик потом засунет в него MongoDBDAOConfig или что-то вроде и удивится происходящему.
@@homo-ergaster Да, сергей как раз и говорил про DAO layer, что не надо там интерфейсы.
Ну нет у нее лап. Извините 😂
Це випадково не ти вчив дітей інформатиці на дошкі, без компів? Десь так в 90х.
Наследование нужно избегать.
Полиморфизм реализуется через Интерфейсы (ну да, это типа наследование, но нет)
Супер класс (базовый класс) может существовать, но никакого упоминания в коде о нем нигде не должно быть, его можно использовать только для уменьшения однотипного кода, но после пару правок придет понимание, что композиция (Делегирование) решает проблему использования кода куда лучше.
При наследовании тестирование становится по сложности как rocket science. Не нужно так :)
Далее если Dependency Ijection поддерживается только в конструктор (PHP Magento, Angular DI) то наследование сделает жизнь адом. По этому в реализациях DI делают инъекцию в setter (в метод). Ведь soLid принцип будет нарушен если переопределять конструктор.
Я из лагеря тех ребят, которые нашли выход в композиции и имеют сотни аргументов чтобы не использовать наследование от базового класса.
Magento 2 (PHP) имеет исходных классов ~25 000, во всех местах классических паттернов не использует наследование вообще, в большинстве мест базовой логики не использует наследование. В проекте на 2000 часов мы не использовали наследование ни разу. Проблем при обновлении нет, проблем поддержки нет, проблем с читаемостью нет.
Magento 1 была построена на принципах наследования и protected модификаторов доступа. Основные расходы времени были на стыковку 3х вендоров в одном проекте...всем нужно было перебить один и тот же класс из ядра системы.
Жду видео про полиморфизм, надеюсь там не будет рекламы наследования ;)
Вообщето наследованием расширяем свойства родительского класса !!!
15-20 уровней наследования - это ведь полный гящь
вы не разделяете наследование и реализацию интерфейса. это только вводит в заблуждение
Видео для бывалых? Я ни слова не понял. Если продаваемый курс так же обьясняется, то, пожалуй, мне данный автор не подходит
Наследование - вообще плохой патерн. Но при этом много чего написано и хрен с ним, пусть будет.
Делигацию никогда не слышал. Композицию знаю.
Наследование вообще не цимис программирования, ООП в том числе. Цимис программирования - это абстракция!!!
Да, понять труднее, но поддержка лучше!!!
Множественное наследование - это вообще жуткий антипатерн!
Немчинский! Ты не программист с большим опытом, а инфоциган, который хочет продать свои курсы.
Рыбы и змея не животные
есть только грибы, растения и животные
@@user-nz2hh9po2r Вирусы ещё.
@@user-um6fj1us4c с вирусами вообще отдельная история)) До сих пор нет строгой договорённости, считать их живыми или нет.
@@0imax Вот если у отдела product development нет строгой уверенности, чем является вирус -- живым или нет, то что делать программисту, любящему иерархию наследования? ЧТД! :)
@@user-um6fj1us4c да, еще и микроорганизмы
Спасибо!