Принципы ООП. 2. Наследование
HTML-код
- Опубликовано: 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
Расскажите про ковариантность и контравариантность, хотелось бы услышать
Расскажите пожалуйста про делегирование. Вы о нём лишь всколь упомянули
Как есть в тарелках, а не с кастрюле всей толпой?)))
Как я понял это (могу ошибаться).
• Наследование : присоединяешь ВСЕ поля, свойства и методы к своему новому классу-наследнику.
• Делегирование : присоединяешь ТОЛЬКО ТЕ поля, свойства и методы к новому классу (уже не наследнику), которые тебе требуются.
Пример делегирования на C# :
Console.WriteLine("Это метод класса Console. Да-да, Console - это класс");
@@user-botogame если можете, оцените правильность моего ответа сверху. Мне тоже интересно что это именно и правильно ли я написал.
@@malikvalley делегирование, это уже отношение контролёр-модель, где один класс юзает другой класс внутри себя, то есть MVC. Первая попытка где то разместить нервную систему, но неудачная, if-elseif по прежнему хрен знает где.
p.s. делегирование уже рост над наследованием, дальше если понять что повторять функции МОЖНО не дублируя... наткнёшься на модульное построение кода.
@@user-botogame всё равно ничего не понял. Очень много терминов, которых человек учащий ООП впринципе может не знать.
Сергей, со своей колокольни скажу (так сказать взгляд снизу) что вы растёте как блогер точно так же как и люди которых вы в том или ином виде обучаете. Вы явно на правильном пути))) Хотя как тут уже замечали - вполне возможно что на примерах кода было бы понятнее для новичков, а то услышав бы я это всё тогда когда не вообще не понимал что это такое - не факт что бы что-то внятно понял.
Дуже дякую!
Хочется услышать от вас про VR и AR, на чем пишут, и какое будущее в этом направление
гениально! даже я понял
Спасибо!
"Интерфейс является классом" - сейчас где-то в мире поперхнулся один Егор Бугаенко :)
Егор Бугаенко как адепт строгого объектного дизайна даже на пушечный выстрел не подошел бы к данному каналу. Особенно после фразы "основная мощь ООП - наследование".
Сергей, пожалуйста, про полиморфизм с примерами на коде.
List a = new ArrayList;
List b = new LinkedList;
Надо бы готовить схемы /слайды к таким темам.. А то ООП в воздухе обьясняешь и в этом видео и в предыдущем! (надеюсь у вас на курсе это есть)))
Полиморфизм не работает без наследования? как на счет "утиной типизации"?
спасибо!
2:27 с точки зрения логики он и расширяет, и сужает - смотря о чём мы говорим, т.к. в логике понятие имеет 2 характеристики - информация и объём, которые объединены обратной зависимостью - при расширении информации сужается объём и наоборот.
спасибо
Расскажите какими по вашему мнению будут языки программирования через лет 10-15. Как они изменятся, Будут ли появляться новые узконаправленные языки или наоборот языки будут стараться покрыть как можно больше областей применения ?
Уже занимаются. Пример тому: ruclips.net/video/d7-Z0nZejYM/видео.html
Сергей, спасибо большое за видео.
Скажите, пожалуйста, а почему вы абстракцию не считаете принципом ООП?
ruclips.net/video/9GdtWiovvIQ/видео.html
В ООП абстракция - это перечисление имён класса. Принципом он может стать, когда будут реализовывать сценарий (if,elseif,wait-click) программы и реализацию сценария отдельно. То есть абстракция как сценарий, изначальный родитель всей программы. А так... сейчас сценарий пишется где попало и как попало.
Да да да. Немчинский, спасибо! Подтвердил мои опасения и сомнения. Иногда видишь что здесь явно нужно наследование но много где пишут что использовать надо только композицию, что наследование нарушает инкапсуляцию. Теперь моих сомнений стало меньше
Наследование это вообще тема опасная, один класс эксплуатирует другой.))))) статья за тунеядство 100%.))) Наверно изначально хотели сделать вложенные классы. Как например в классе Дом находится класс Туалет со своими ЛИЧНЫМИ атрибутами и ФУНКЦИЯМИ, которые выполнять будет самостоятельно:
class ДОМ{
class Туалет{};
class Кухня{};
}
$дом = new ДОМ();
$дом->Туалет->помыть();
@@user-botogame а как быть если у классов есть общий сценарий но разные типы?
Например сценарий
Собрать запрос
Отправить
Залогировать
И это выполняют 10к классов.
Я вынес общий сценарий в абстрактный класс
Полиморфно определил билдер запросов и логер
И наследовался от этого класса - где каждый наследник передал свой билдер запросов и логер, при этом сценарий определяется родителем(с возможностью переопределения конечно)
Зробіть по SOLID відео
Есть целый плейлист
Я бы назвал это видео: "Нужно ли использовать наследование" или что-то такое. Это для тех, кто уже знает об этом принципе
Вместо слов расширяет/уменьшает(2:30), можно использовать термин "уточняет". Наследник уточняет родительский класс
А как насчет полиморфизма на основе интерфейсов? Мы можем имплементировать в классах сотрудников интерфейс с методом getCountForBlabla и отправлять этот интерфейс на вход какого-нибудь метода (как тип данных) класса для расчета больничных/диспансеризации/etc, который бы всех считал. Какие проблемы есть у такого подхода? Спасибо.
Некуда будет сложить общий для этих классов код.
Читали ли Столярова А.В. и его Введение в профессию. Азы программирования?
Про это есть эстонский фильм 2007 года «Класс»
Не совсем понял, что имеется ввиду под "полным отказом от наследования" и "возврату к процедурному программированию из-за отсутствия полиморфизма"? Отказ только от классов, или от классов и интерфейсов? Обычно когда отказываются от наследования, то имеются ввиду только классы, интерфейсы остаются. А раз так, то и полиморфизм никуда не исчезает.
Про расширение/сужение.
Это же логика уровня средней школы - чем шире содержание понятия, тем уже его объём, и наоборот.
Содержание понятия - это знание о совокупности существенных признаков класса предметов.
Объём понятия - это знание о круге предметов, существенные признаки которых отражены в понятии.
Вот и получается, слово extends расширяет содержание понятия (класса, абстрактного типа данных), но одновременно с этим сужается его объём.
красиво сказал
"Истинный Полиморфизм"?? ) Это сильно. Но об этом в другой лекции.
.
Интерфейс -- это Класс!!?? Это еще сильнее.
.
Не смотря на то, что очень часто Интерфес и Чисто Абстрактный Класс взаимозаменяют, все же Класс и Интерфейс -- это два разных понятия.
.
Класс -- похож на свет! ) Т.е. имеет двойственную "природу". С одной стороны -- это совокупность объектов, обладающих определенными структурой и поведением, а с другой стороны -- это механизм описания такой структуры и поведения, а также механизм управления совокупностью объектов из класса, как одинм целым (т.е. на уровне совокупности).
.
Интерфейс -- это независящий от внутреннего поведения Класса способ взаимодейстия с его экземплярами и Классом, как отдельной сущностью.
.
Когда создается Класс -- определяется Интерфейс. Например, в C++ даже другого способа определить Интерфейс нет. Вместе с тем, создаение интерфейса само по себе не приводит к созданию Класса, т.к. поведение экземпляров, равно, как и поведение Класса как сущности, не описывается.
.
Собственно, унаследоваться можно от Класса, а Интерфейс можно реализовать. В этом смысле, два Класса, реализующие один интерфейс могут быть использованы в полиморфном алгоритме, но при этом эти два класса не связаны наследованием (т.е. у них не будет общего предка)
.
Наследование само по себе кроме "асбтрактного" описания еще имеет и программную реализцию: это, либо VMT, либо цепочки прототипов. Так вот, у Классов с общим предком, VMT должны иметь непустое и не тривиальное пересечение (противное будет обозначать тотальное переопределение наследуемого поведения, а значит неуместность использования наследования). В случае с цепочками прототипов Классы родственники всегда будут иметь непустую и нетривиальную часть цепи общих "предков".
.
Нетривиальность -- это то, что не связано с базовым классом: во многих языках такой класс есть и наследование от него происходит неявным образом, и в этом смысле все Классы в языке родственны.
.
VMT - virtual methods table - картеж (или эквивалентная структура данных) с ссылками на виртуальные методы в структуре Класса (такое себе статическое поле), используемая для опредление того, метод какого именно класса связан конкретно с данным экземпляром (все экземпляры Класса при конструировании получают ссылку на VMT своего Класса). Если в языке есть динамическое наследование, то VMT может содержать ссылку на VMT родителя (и по сути превращается в цепочку прототипов). Если язык поддерживает только статическое наследование, то VMT имеет плоскую структуру и формируется в момент компиляции программы.
.
Интерфейсы, в свою очередь, VMT не имеют. Интерфейсы определяют струтуру VMT, но не значения в ней. В частности поєтому, Интерфейсы при компиляции программы создают, либо только мета-артефакты, либо не создают артефакты вообще.
я думаю более правильно понимать, что другой класс реализует интерфейс , потому что по дефолту в интерфейсе не указывается реализация свойств и методов. не знаю про java ,но в c# функция дефолтная реализация интерфейса в интерфейсе появилась в 8.0 версии. и для её использования надо явно апкастить объект к нужному типу интерфейса.
в java тоже есть default методы в интерфейсе.
Сергей, куда задавать вопросы?
Если в комменты, то вопрос не по теме видео:
На практике как пользуются гитом (или аналогами)? В плане через консоль или с помощью ide? Некоторые ide позволяют подключиться к репозиторию и управлять ветками, коммитами и всеми необходимыми вещами. Но, слышал, что это не очень хороший тон, и лучше пользоваться напрямую git bash (или аналогами). Что Вы думаете насчет этого?
А что тут думать, на этот вопрос Сергей уже не раз отвечал, нужно просто сесть и выучить, основы гита учатся за день-два
Мне нравится Git Extensions. На работе посоветовали, с тех пор не вижу особого смысла сидеть в консоли гита. Хотя, конечно, если если есть шанс, что придётся юзать Git чисто из консоли, то явно проще учить основы, команды и как его красиво настроить, чтобы бранчи нормального видеть и историю коммитов.
@@tolik8 не совсем понял. А почему такой ответ? Чем обоснован?
Сергей отвечал? На канале есть видео? Хорошо, поищу
@@AllWayToDeath сори, мой косяк, я очень бегло прочитал вопрос и подумал что вопрос: пользоваться гитом или нет
@@tolik8 ааа, ахах, бывает:)))
Сергей, а можете рассказать, почему Абстракция - не принцип ООП?)
Потому что всё программирование - абстракция, и ооп тут никак не выделяется :)
круто - даешь еще
обязательно)
Наверное ещё стоит сказать, что, проверяя классы на "is a", нужно чтобы они были только "is a", без всяких ограничений, в духе "этот класс - это вот этот класс, только с такими вот особенностями...". В видео про LSP в SOLID был хороший пример с прямоугольником и квадратом на эту тему
Имеется ввиду, что наследование это "зло" тогда, когда наследуются от класса который может порождать свои сущности и когда потребуется допилить функционал родителя, это с большой вероятностью сломает дочерние классы и приходится так же их переписывать, либо переосмысливать и менять иерархию классов, что никак не помогает в работе и уж тем более не экономит время и деньги. А вот если класс имлпементирует интерфейсы, то все перечисленные Вами проблемы решаются. Но это все еще раз подчеркивает что у джавы далеко не совершенная система типов.
Если изменения в родительском классе сильно ломают дочерние классы, то есть вероятность, что они вообще не родственники, либо архитектура построена неправильно. Но, если отказаться от наследования и делать через имплементацию интерфейсов, то будет куча дублирующегося кода, доставшегося от базового класса.
@@0imax >Если изменения в родительском классе сильно ломают дочерние классы, то есть вероятность, что они вообще не родственники, либо архитектура построена неправильно
Но ведь изменения нельзя предугадать, каким бы замечательным архитектором ты ни был. Поэтому архитектура через наследование плохо масштабируется. Сегодня сущность выглядит как "X is a Y", завтра отдел product development приходит и говорит, что в следующем релизе сущность X будет иметь свойства, которые плохо натягиваются на Y (или наоборот) -- удачи всё это или переписывать, или пытаться впендюрить кривые костыли, чтобы иерархию оставить.
@@0imax >если отказаться от наследования и делать через имплементацию интерфейсов, то будет куча дублирующегося кода, доставшегося от базового класса
В этом и суть делегирования: для избежания дублирования просто делай вызовы в сторонний класс, который иерархией никак не связан с текущим. В случае изменения спеки (особенно когда сущности начинают сильно разъезжаться в поведении) тривиально поменять вызовы на другие методы/классы, так как делегирование приватное, а во многих языках типа Java наследование публичное, поэтому пришлось бы не только рефакторить классы, но и трогать код всех клиентов.
Значит нужно стараться создавать абстрактные классы? Чтобы избежать подобных случаев.
P.S. Я только начал изучать Java.
@@konstantingeist3587 ну если предметная область такая, что объекты то "is a", то нет, а классы всунуты в одно дерево наследования - то тут можно лишь посочувствовать))
Если внесение изменений в родительский класс, ломающее дочерние, случается регулярно, то придётся хорошенько рефакторить это всё дело, разнося классы по разным веткам наследования, дабы будущие изменения коснулись только тех, кого надо, либо до отказа от наследования вообще. Тут уже зависит от конкретной ситуации.
А если использовать вместо наследования классов, имплементацию интерфейсов?
Наследование и имплементация интерфейсов используются для разных целей. Можно и вместо ложки пользоваться вилкой, но...)))
@@0imax Неверно, частично они совпадают. У интерфейса и abstract class много общих паттернов использования. По факту в Java их отделили тупо чтобы реализовать множественное наследование, сгладив проблемы diamond problem
@@konstantingeist3587 В том-то и дело, что частично. Но в последнее время какая-то тенденция избегать наследования даже там, где оно явно должно быть. И начинается: отдельный класс с общими данными, с общими методами, перегонка данных туда-сюда, полиморфизм на интерфейсах и прочие костыли, хотя можно было просто написать extends, и от этого бы никто не умер :)
Сергей, ну не серьезно. Где схемы? Одной говорящей головы не достаточно, чтобы такую тему раскрыть.
Ещё бы понять что такое делегирование простым языком))) Мне лишь приходит что-то из разряда "делегат", "ссылка на метод" и пр.
Если совсем грубо, то для реализации какой-то функциональности внутри класса А заводится класс В, который выполняет эту функциональность, а класс А просто вызывает его методы.
Неправильный подход - отнаследовать класс А от класса В, чтобы класс А получил методы класса В, и затем их вызывал сам у себя.
Не внутри класса А заводится класс В, а объект класса А параметризуется объектами класса В. Типа:
public class B {
public int getInt(){ return 0; }
}
public class A{
private B b;
public int getInt(){ return b.getInt(); }
}
@@0imax "заводится класс В" - по русски называется эксплуататор))))
делегирование - это передача своих обязанностей другому субъекту/объекту. Это как подрядчики и субподрядчики в реальной жизни.Тебя просят что-то сделать, а ты это перекладываешь на другого человека, просишь его сделать это за тебя)
Вообще то когда то нужно было делегирование (вложенность) инкапсуляции, но не смогли такое реализовать:
.................................................
//сценарий
function Помывка_ДОМА(){
$дом = new ДОМ();
$дом->помыть_всё();
if($дом->Туалет->чисто == 'нет'){
$дом->Туалет->помыть();
}
if($дом->Кухня->чисто == 'нет'){
$дом->Кухня->помыть();
}
}
//реализация сценария
class ДОМ{
class Туалет{...};
class Кухня{...};
function помыть_всё(){
$this->Туалет->помыть();
$this->Кухня->помыть();
}
}
//выполнение
Помывка_ДОМА();
.................................................
p.s. наследование = тунеядство какого то класса?)))
Пример с сотрудниками в корне некорректен. Если бухгалтер и инженер не являются наследниками класса Person или Employee, совсем не обязательно, что нужно их перебирать как три отдельных списка. Достаточно реализовать интерфейс и приводить их к интерфейсу.
Более того, если они не разделяют какой-то базовой общей логики и состояния, лучше использовать интерфейс.
GOF-паттерны используют в своих примерах наследование, так как на тот момент не нахватали граблей, и это был самый привычный пример переиспользования кода.
Не затронута главная тема, почему не стоит использовать наследование: для наследования класс нужно внимательно проектировать, чтобы не сломать логику работы его наследников. Это подробно рассказано в 4-й главе у Джошуа Блоха, которую читал каждый Java-программист, старше джуниора.
Интерфейс - частичный случай класса, получиться то же наследование.
@@user-xc5cx7lh4l Термин "Наследование" употребляют с интерфейсом, но это не значит, что класс - частный случай интерфейса. Класс подразумевает под собой наличие полей и состояния, коих нет у интерфейсов. Потомок класса и реализация интерфейса, это два разных понятия, и это не мелкая неточность, это ошибка.
В энциклопедии британнике нет чёткого понятия базовых принципов ООП, из-за этого часто бывают споры, зачастую, бестолковые, но пример всё равно тяп-ляп)
@@liamsmith7052 Всё верно. Если у классов сотрудников нет общего кода - делаем через интерфейсы, если есть - через наследование. Обычно он всё-таки есть, поэтому пример вполне норм.
А если пишем на C# то в интерфейсе можем писать приватные методы и базовую реализацию...
Так и не понял чем этот интерфейс будет отличаться от класса, кроме возможности множественной реализации
@@grommaks отсутствием возможности создавать экземпляры и хранить их состояние.
У меня вопрос, а мне на собесе в бубен не дадут, если я скажу что интерфейс это класс?
Зависит от языка. Например, в C++ нет такой языковой структуры, как интерфейс. И роль интерфейса берут на себя классы, при этом не особо даже принято говорить "интерфейс", принято говорить ABC (Abstract Base Class). Есть другие языки, где интерфейс - это языковая конструкция, которая отличается от класса, тем, что от интерфейса нельзя наследоваться.
🔔Можно ли в конструкторе вызывать сеттер? В интернете мнения разделяются 50 на 50.
Заранее спасибо
По факту в конструкторах не стоит вызывать собственные методы вообще, т.к. во-первых, реализации методов могут ссылаться на ещё не проинициализированные данные (т.к. конструктор ещё не завершил работу), а во-вторых, ситуация усложняется наличием виртуальных методов -- в некоторых языках до завершения работы конструктора будет вызван виртуальный метод базового класса, а не текущего -- что может привести к порче объекта.
@@konstantingeist3587 сеттер не ссылается ведь на какие-то данные. Он лишь устанавливает значение, если оно подходит условиям.
Но как тогда инициализировать данные по условиям, чтобы я не мог ,например, атрибуту "размер" присвоить значение -10 ?
@@avazart614 то есть каждый сеттер обязательно должен бросать исключение, правильно я понял? И если в сеттере находится лишь инициализация атрибутов с проверкой условий, то я могу в конструкторе вызывать сеттер? Как в серьезных проектах решается проблема проверки данных при вызове конструктора?
@@agentr227 Сеттер вполне может ссылаться на данные. Например, у нас есть инвариант "ширина прямоугольника не может быть больше высоты". Польза сеттеров не столько в сокрытии переменной (сокрытие это не самоцель), сколько в возможности валидации инвариантов (бизнес-правил). Т.е. в сеттере установки ширины мы должны провалидивировать инвариант, а сделать мы это можем в нашем случае прочитав значение "высота" и сравнив с новым значением ширины. И если вызывать сеттер в конструкторе, то это не очень безопасно, т.к. объект по факту не до конца ещё проинициализирован, а метод ожидает, что он уже полностью сформирован (т.е. значение высоты может быть ещё не установлено, тогда наша валидация была некорректной).
@@konstantingeist3587 ну почему, если конструктор сложный, то все можно распихать по методам. Хотя абстрактные (они же вроде бы виртуальные) методы в конструкторах... не знаю... насколько это нормально!?
Можно использовать методы у супер класса который общий для всех и объявлять новые методы которые присущи только этому подклассу.
Все против именно наследование между классами, пример который Вы привели, спокойно наследуемый по Интерфейсам
Но в таком случае общий код некуда будет положить.
@@0imax Общий код можно положить в сторонний класс. Часто вообще бывает, что "общий код" высосан из пальца и не является какой-то осмысленной бизнес-логикой, а просто парой-другой похожих строк тривиального инфраструктурного кода, который можно спокойно продублировать, но из-за которого развели сложную иерархию в погоне за "code reuse". Есть вот premature optimization, тут нужен термин вроде premature code reuse.
@@konstantingeist3587
"Часто вообще бывает, что "общий код" высосан из пальца"
В говнокоде всякое встречается))
Когда нужна вложенность инкапсуляции, то видимо хотели (но не смогли) так реализовать:
class ДОМ{
class Туалет{};
class Кухня{};
}
$дом = new ДОМ();
$дом->Туалет->помыть();
@@0imax Ну я вот давно замечаю, что у многих программистов есть такой условно-безусловный рефлекс, при котором завидев две-три одинаковых строчки из разных мест возникает горячейшее желание сделать "code reuse" и создать какой-нибудь нелепый общий метод, иначе ведь дублирование! В итоге со временем общий код обрастает говном и костылями, так как два оригинальных класса в коде начали различаться из-за новых требований, и всё это ещё супербажно т.к. меняя что-то в общем коде под новый кейс для одного класса/функции ненароком меняется поведение для другого класса-клиента и т.д. Поэтому если и выводить в общий код, то только если это осмысленная логика, которую сложно повторить -- и в таких случаях лучше бы подошёл отдельный самодостаточный класс, а не костыли вроде protected-методов в базовом классе или утилитные классы-помойки.
Часы и очки как у Сереги)))может это значить что я тоже программист??))))
это комбо-набор, вместе дают + 100 к интеллекту и +50 к разговору) А да, еще и харизму повышает на 80 пунктов))
Посмотрел 1 раз и понял 10-15% объяснений -) Посмотрю еще раз 10 - наверняка процентов 30 ещё дойдёт
надеюсь на ваших курсах объясняют лучше.....
Использую композицию, и плюю на наследование
подскажите пожалуйста, как родительский класс персон поможет понять , работает человек в офисе или нет ? нипонятно
Очень просто, любой работнмк может работать в офисе или не в офисе, значит свойство "место работы" логично прицеить к родительскому классу работник, а не к конкретному, инженер, бухгалтер
За счёт взаимодействия между сущностями. перефразирую: как виндусу понять что запущена такая то программа. ответ: функцией в виндосе "проверка запущенной программы". / как проверить что собака не сдохла - ткнуть палкой, по результату тыкания делать выводы.
А как его теперь зовут этого мужика?
Обалденно когда на курсах для новичков лектор густо сдабривает свою речь специфической профессиональной терминологией, чтобы все слушатели почувствовали себя идиотами, хотя можно было всё просто объяснить на примере лап и хвостов у рыб и змей.
1C ТАКОЙ КОД БЕЗ НАСЛЕДОВАНИЯ.
никак не запомню как вас зовут
ни че не понял... На каком языке говорили?
У семьи есть наследование значит и у кода должно быть наследование
У многих королевских семей не было наследования, особенно после расстрела царской семьи.
@@imho10 всегда найдётся исключение :D
Полностью отказаться от наследования это, конечно, зашквар. Не зря столпы программирования говорят aggregation over inheritance, но не aggregation instead of inheritance. Т.е. следует предпочитать делегирование наследованию.
Наследование, это когда кто то за тебя выполняет твои функции. В СССР раньше был срок за такое , как за тунеядство.)))))
@@user-botogame когда за тебя - это делегирование, а наследование - когда ты выполняешь всю ту работу по дому, что и родители, но ещё и в школу ходишь :)
@@0imax странно написал. В школу можно ходить и при делегировании и при наследовании. Только при наследовании телефон тебе подарили, а при делегировании дали на время. И если во втором случае разобьёшь - получишь щелбан. А в первом случае два. И если выше брать, то родители лишь делегировали школе свои полномочия на ребёнка.
@@user-botogame В жизни всё так, но в программировании обычно всё через ж.. Как с прямоугольником и квадратом)
@@0imax не через ж, а супротив авторитетства программирования. Медведев назвал правильное слово: разнотык. Я называю это дискредитацией. Словно бултыхание в болоте.
Ух сколько лишних проблем в языках со строгой типизацией. В языках с "утиной" типизацией с этим намного проще: взял всех сотрудников и сунул в общий список не зависимо от "класса".
а ещё кто то напихал туда "пельмени" и "самолёты" ) , а ты и думай что на выходе делать.
@@syberskyer А на выход подключаем мясорубку, которая всё это перемалывает в инты)))
В языке Go строгая типизация, но при этом есть утиная типизация в плане приведения структуры к интерфейсу -- если структура ведёт себя как утка, то она утка :) При этом все типы известны на стадии компиляции заранее, что экономит кучу времени. Очень удачный компромис. Это скорее в Java просто излишняя бюрократия/формализм.
@@avazart614 В Go нет шаблонов, хотя сходство определённое есть с шаблонами в C++ в плане статической утиной типизации (в С++ если мы используем метод с сигнатурой S, то шаблон скомпилируется для любого типа T, у которого есть метод с сигнатурой S). Но в Go там немного другое, и попроще. В Go если структура имеет метод foo(int, int), то она автоматически реализует любой интерфейс, определяющий метод foo(int, int). Не нужно писать "implements" как в Java, и это решает множество архитектурных проблем, т.к. можно сделать так, чтобы структура из другого пакета реализовала твой интерфейс, даже не зная, что он существует (напр. полезно когда мы не владеем кодом из стороннего пакета; в Java пришлось бы писать адаптер-класс; также полезно для более элегантного dependency inversion -- т.к. благодаря такому подходу нет строгой привязки классов друг к другу).
Це випадково не ти вчив дітей інформатиці на дошкі, без компів? Десь так в 90х.
Наследование нужно избегать.
Полиморфизм реализуется через Интерфейсы (ну да, это типа наследование, но нет)
Супер класс (базовый класс) может существовать, но никакого упоминания в коде о нем нигде не должно быть, его можно использовать только для уменьшения однотипного кода, но после пару правок придет понимание, что композиция (Делегирование) решает проблему использования кода куда лучше.
При наследовании тестирование становится по сложности как rocket science. Не нужно так :)
Далее если Dependency Ijection поддерживается только в конструктор (PHP Magento, Angular DI) то наследование сделает жизнь адом. По этому в реализациях DI делают инъекцию в setter (в метод). Ведь soLid принцип будет нарушен если переопределять конструктор.
Я из лагеря тех ребят, которые нашли выход в композиции и имеют сотни аргументов чтобы не использовать наследование от базового класса.
Magento 2 (PHP) имеет исходных классов ~25 000, во всех местах классических паттернов не использует наследование вообще, в большинстве мест базовой логики не использует наследование. В проекте на 2000 часов мы не использовали наследование ни разу. Проблем при обновлении нет, проблем поддержки нет, проблем с читаемостью нет.
Magento 1 была построена на принципах наследования и protected модификаторов доступа. Основные расходы времени были на стыковку 3х вендоров в одном проекте...всем нужно было перебить один и тот же класс из ядра системы.
Жду видео про полиморфизм, надеюсь там не будет рекламы наследования ;)
"Magento 2 (PHP) имеет исходных классов ~25 000" Класс Дом, класс Квартира, класс Дом2, класс КвартираN и т.д. до кучи наркоманского раздрая вложенности. А ведь ещё там запрятан сценарий программы...
Вообще то когда то нужна была вложенность инкапсуляции, но не смогли такое реализовать:
class ДОМ{
class Туалет{...};
class Кухня{...};
function помыть_всё(){
$this->Туалет->помыть();
$this->Кухня->помыть();
}
}
$дом = new ДОМ();
$дом->помыть_всё();
$дом->Кухня->помыть();
Программируйте на уровне интерфейсов а не на уровне реализации)
Бывает что и интерфейса то нет, сразу реализация. Тот-же Thread в Java - это ни**я не интерфейс. Да и частенько нужна именно конкретная реализация, а не некий абстрактный интерфейс. Типа там какой-нибудь класс SomeEntityMySQLDAO и его уже не параметризуешь абстрактным DAOConfig, а прямо указываешь, что он хавает MySQLDAOConfig, иначе какой-нибудь чудик потом засунет в него MongoDBDAOConfig или что-то вроде и удивится происходящему.
@@homo-ergaster Да, сергей как раз и говорил про DAO layer, что не надо там интерфейсы.
Абстракция заключена в написании сценария (if-elseif-wait-click) программы, который и будет дергать ООП за ниточки.
Ну нет у нее лап. Извините 😂
вы не разделяете наследование и реализацию интерфейса. это только вводит в заблуждение
15-20 уровней наследования - это ведь полный гящь
Видео для бывалых? Я ни слова не понял. Если продаваемый курс так же обьясняется, то, пожалуй, мне данный автор не подходит
Вообщето наследованием расширяем свойства родительского класса !!!
Наследование - вообще плохой патерн. Но при этом много чего написано и хрен с ним, пусть будет.
Делигацию никогда не слышал. Композицию знаю.
Наследование вообще не цимис программирования, ООП в том числе. Цимис программирования - это абстракция!!!
Да, понять труднее, но поддержка лучше!!!
Множественное наследование - это вообще жуткий антипатерн!
Немчинский! Ты не программист с большим опытом, а инфоциган, который хочет продать свои курсы.
Рыбы и змея не животные
есть только грибы, растения и животные
@@user-nz2hh9po2r Вирусы ещё.
@@user-um6fj1us4c с вирусами вообще отдельная история)) До сих пор нет строгой договорённости, считать их живыми или нет.
@@0imax Вот если у отдела product development нет строгой уверенности, чем является вирус -- живым или нет, то что делать программисту, любящему иерархию наследования? ЧТД! :)
@@user-um6fj1us4c да, еще и микроорганизмы
Спасибо!