🦊Новый поток Advanced курса Enterprise Patterns стартует уже 1 февраля 2023 года ❗ Регистрация - go.foxminded.ua/3XGhXov

Вообще никогда не писал комментариев к видео в Ютуб. Хочу вас поблагодарить за ваши труды. Очень нравится ваша манера объяснения, ваш раскрепощенный формат, будто вы объясняете не просто студенту, а своему другу. Я C# разработчик и уверенно говорю, что мне очень полезно порой посмотреть и послушать вас (даже интерес всегда увеличивается к программированию). Конкретно сейчас смотрю ваше видео, залитое 1 марта 2016 "Чистый код", а пишу под этим видео, чтобы вы заметили комментарий (м.б. алгоритмы ютуба владельцу канала показывают в первую очередь писанины людей под самым свежим видео). Вы делитесь довольно интересный и актуальным опытом (особенно про индусов из видео "Чистый код"). Большое спасибо, что вы помогаете нам улучшать себя, что делитесь достаточно ценным опытом.

@RasulAbuMuhammadAmin

4 жыл бұрын

Спасибо за наводку, включу пожалуй плейлист "чистый код"

@user-eg5cg3lk3e

Жыл бұрын

А вы про какое? Там 3 плейлиста Clean code

@user-eg5cg3lk3e

Жыл бұрын

@@imhere2264 особенно по этому я удивлен столь быстрому ответу. Спасибо!

@user-oj4rl4ck2o

8 ай бұрын

2016 был 7 лет назад, охренеть

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

@malikvalley

3 жыл бұрын

private static string name = "Сергей Немчинский";

@BrodrickStreams

3 жыл бұрын

@@malikvalley final

@malikvalley

3 жыл бұрын

@@BrodrickStreams я ваш финал не понимать, я C#

@casper1vanes

3 жыл бұрын

@@malikvalley скорее public

@gleb7514

3 жыл бұрын

никчемский

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

вы очень интересно рассказываете) особенно улыбнулась от "по наркоманский" ! спасибо!!

Спасибо! Серия коротких учебных видео - это то, что нужно. Коротко, ясно, простыми словами. Формат - супер! Кстати, толстовка крутая )

@SergeyNemchinskiy

4 жыл бұрын

спасибо)

очень здорово объясняете) все сразу понятно!)

Уже жду ролик про полиморфизм "простым языком". Лайк

@SergeyNemchinskiy

4 жыл бұрын

куда ж без него)

@magellan127

4 жыл бұрын

На почитай и никого никогда не жди, ибо такими темпами если учить , то на учебу java, жизни не хватит) vertex-academy.com/tutorials/ru/chto-takoe-polimorfizm-java/

Всё так, спасибо за выпуск

thanks, good explanation

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

Расскажите про ковариантность и контравариантность, хотелось бы услышать

Расскажите пожалуйста про делегирование. Вы о нём лишь всколь упомянули

@user-botogame

4 жыл бұрын

Как есть в тарелках, а не с кастрюле всей толпой?)))

@malikvalley

3 жыл бұрын

Как я понял это (могу ошибаться). • Наследование : присоединяешь ВСЕ поля, свойства и методы к своему новому классу-наследнику. • Делегирование : присоединяешь ТОЛЬКО ТЕ поля, свойства и методы к новому классу (уже не наследнику), которые тебе требуются. Пример делегирования на C# : Console.WriteLine("Это метод класса Console. Да-да, Console - это класс");

@malikvalley

3 жыл бұрын

@@user-botogame если можете, оцените правильность моего ответа сверху. Мне тоже интересно что это именно и правильно ли я написал.

@user-botogame

3 жыл бұрын

@@malikvalley делегирование, это уже отношение контролёр-модель, где один класс юзает другой класс внутри себя, то есть MVC. Первая попытка где то разместить нервную систему, но неудачная, if-elseif по прежнему хрен знает где. p.s. делегирование уже рост над наследованием, дальше если понять что повторять функции МОЖНО не дублируя... наткнёшься на модульное построение кода.

@malikvalley

3 жыл бұрын

@@user-botogame всё равно ничего не понял. Очень много терминов, которых человек учащий ООП впринципе может не знать.

Хочется услышать от вас про VR и AR, на чем пишут, и какое будущее в этом направление

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

гениально! даже я понял

Надо бы готовить схемы /слайды к таким темам.. А то ООП в воздухе обьясняешь и в этом видео и в предыдущем! (надеюсь у вас на курсе это есть)))

Дуже дякую!

Спасибо!

"Интерфейс является классом" - сейчас где-то в мире поперхнулся один Егор Бугаенко :)

@vsbff

2 жыл бұрын

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

Сергей, пожалуйста, про полиморфизм с примерами на коде.

@0imax

4 жыл бұрын

List a = new ArrayList; List b = new LinkedList;

Полиморфизм не работает без наследования? как на счет "утиной типизации"?

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

@user-botogame

4 жыл бұрын

Наследование это вообще тема опасная, один класс эксплуатирует другой.))))) статья за тунеядство 100%.))) Наверно изначально хотели сделать вложенные классы. Как например в классе Дом находится класс Туалет со своими ЛИЧНЫМИ атрибутами и ФУНКЦИЯМИ, которые выполнять будет самостоятельно: class ДОМ{ class Туалет{}; class Кухня{}; } $дом = new ДОМ(); $дом->Туалет->помыть();

@slavapush

4 жыл бұрын

@@user-botogame а как быть если у классов есть общий сценарий но разные типы? Например сценарий Собрать запрос Отправить Залогировать И это выполняют 10к классов. Я вынес общий сценарий в абстрактный класс Полиморфно определил билдер запросов и логер И наследовался от этого класса - где каждый наследник передал свой билдер запросов и логер, при этом сценарий определяется родителем(с возможностью переопределения конечно)

спасибо!

Зробіть по SOLID відео

@wtf_nick

4 жыл бұрын

Есть целый плейлист

Вместо слов расширяет/уменьшает(2:30), можно использовать термин "уточняет". Наследник уточняет родительский класс

спасибо

Я бы назвал это видео: "Нужно ли использовать наследование" или что-то такое. Это для тех, кто уже знает об этом принципе

Расскажите какими по вашему мнению будут языки программирования через лет 10-15. Как они изменятся, Будут ли появляться новые узконаправленные языки или наоборот языки будут стараться покрыть как можно больше областей применения ?

@user-botogame

4 жыл бұрын

Уже занимаются. Пример тому: kzread.info/dash/bejne/lmthvJKnisjQibA.html

"Истинный Полиморфизм"?? ) Это сильно. Но об этом в другой лекции. . Интерфейс -- это Класс!!?? Это еще сильнее. . Не смотря на то, что очень часто Интерфес и Чисто Абстрактный Класс взаимозаменяют, все же Класс и Интерфейс -- это два разных понятия. . Класс -- похож на свет! ) Т.е. имеет двойственную "природу". С одной стороны -- это совокупность объектов, обладающих определенными структурой и поведением, а с другой стороны -- это механизм описания такой структуры и поведения, а также механизм управления совокупностью объектов из класса, как одинм целым (т.е. на уровне совокупности). . Интерфейс -- это независящий от внутреннего поведения Класса способ взаимодейстия с его экземплярами и Классом, как отдельной сущностью. . Когда создается Класс -- определяется Интерфейс. Например, в C++ даже другого способа определить Интерфейс нет. Вместе с тем, создаение интерфейса само по себе не приводит к созданию Класса, т.к. поведение экземпляров, равно, как и поведение Класса как сущности, не описывается. . Собственно, унаследоваться можно от Класса, а Интерфейс можно реализовать. В этом смысле, два Класса, реализующие один интерфейс могут быть использованы в полиморфном алгоритме, но при этом эти два класса не связаны наследованием (т.е. у них не будет общего предка) . Наследование само по себе кроме "асбтрактного" описания еще имеет и программную реализцию: это, либо VMT, либо цепочки прототипов. Так вот, у Классов с общим предком, VMT должны иметь непустое и не тривиальное пересечение (противное будет обозначать тотальное переопределение наследуемого поведения, а значит неуместность использования наследования). В случае с цепочками прототипов Классы родственники всегда будут иметь непустую и нетривиальную часть цепи общих "предков". . Нетривиальность -- это то, что не связано с базовым классом: во многих языках такой класс есть и наследование от него происходит неявным образом, и в этом смысле все Классы в языке родственны. . VMT - virtual methods table - картеж (или эквивалентная структура данных) с ссылками на виртуальные методы в структуре Класса (такое себе статическое поле), используемая для опредление того, метод какого именно класса связан конкретно с данным экземпляром (все экземпляры Класса при конструировании получают ссылку на VMT своего Класса). Если в языке есть динамическое наследование, то VMT может содержать ссылку на VMT родителя (и по сути превращается в цепочку прототипов). Если язык поддерживает только статическое наследование, то VMT имеет плоскую структуру и формируется в момент компиляции программы. . Интерфейсы, в свою очередь, VMT не имеют. Интерфейсы определяют струтуру VMT, но не значения в ней. В частности поєтому, Интерфейсы при компиляции программы создают, либо только мета-артефакты, либо не создают артефакты вообще.

Про расширение/сужение. Это же логика уровня средней школы - чем шире содержание понятия, тем уже его объём, и наоборот. Содержание понятия - это знание о совокупности существенных признаков класса предметов. Объём понятия - это знание о круге предметов, существенные признаки которых отражены в понятии. Вот и получается, слово extends расширяет содержание понятия (класса, абстрактного типа данных), но одновременно с этим сужается его объём.

@vladimirkravtsov8927

4 жыл бұрын

красиво сказал

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

@0imax

4 жыл бұрын

kzread.info/dash/bejne/a3uY1rmin9ncebQ.html

@user-botogame

4 жыл бұрын

В ООП абстракция - это перечисление имён класса. Принципом он может стать, когда будут реализовывать сценарий (if,elseif,wait-click) программы и реализацию сценария отдельно. То есть абстракция как сценарий, изначальный родитель всей программы. А так... сейчас сценарий пишется где попало и как попало.

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

@0imax

4 жыл бұрын

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

@konstantingeist3587

4 жыл бұрын

@@0imax >Если изменения в родительском классе сильно ломают дочерние классы, то есть вероятность, что они вообще не родственники, либо архитектура построена неправильно Но ведь изменения нельзя предугадать, каким бы замечательным архитектором ты ни был. Поэтому архитектура через наследование плохо масштабируется. Сегодня сущность выглядит как "X is a Y", завтра отдел product development приходит и говорит, что в следующем релизе сущность X будет иметь свойства, которые плохо натягиваются на Y (или наоборот) -- удачи всё это или переписывать, или пытаться впендюрить кривые костыли, чтобы иерархию оставить.

@konstantingeist3587

4 жыл бұрын

@@0imax >если отказаться от наследования и делать через имплементацию интерфейсов, то будет куча дублирующегося кода, доставшегося от базового класса В этом и суть делегирования: для избежания дублирования просто делай вызовы в сторонний класс, который иерархией никак не связан с текущим. В случае изменения спеки (особенно когда сущности начинают сильно разъезжаться в поведении) тривиально поменять вызовы на другие методы/классы, так как делегирование приватное, а во многих языках типа Java наследование публичное, поэтому пришлось бы не только рефакторить классы, но и трогать код всех клиентов.

@ksander4386

4 жыл бұрын

Значит нужно стараться создавать абстрактные классы? Чтобы избежать подобных случаев. P.S. Я только начал изучать Java.

@0imax

4 жыл бұрын

@@konstantingeist3587 ну если предметная область такая, что объекты то "is a", то нет, а классы всунуты в одно дерево наследования - то тут можно лишь посочувствовать)) Если внесение изменений в родительский класс, ломающее дочерние, случается регулярно, то придётся хорошенько рефакторить это всё дело, разнося классы по разным веткам наследования, дабы будущие изменения коснулись только тех, кого надо, либо до отказа от наследования вообще. Тут уже зависит от конкретной ситуации.

я думаю более правильно понимать, что другой класс реализует интерфейс , потому что по дефолту в интерфейсе не указывается реализация свойств и методов. не знаю про java ,но в c# функция дефолтная реализация интерфейса в интерфейсе появилась в 8.0 версии. и для её использования надо явно апкастить объект к нужному типу интерфейса.

@NummeSpnet

4 жыл бұрын

в java тоже есть default методы в интерфейсе.

Про это есть эстонский фильм 2007 года «Класс»

А как насчет полиморфизма на основе интерфейсов? Мы можем имплементировать в классах сотрудников интерфейс с методом getCountForBlabla и отправлять этот интерфейс на вход какого-нибудь метода (как тип данных) класса для расчета больничных/диспансеризации/etc, который бы всех считал. Какие проблемы есть у такого подхода? Спасибо.

@0imax

3 жыл бұрын

Некуда будет сложить общий для этих классов код.

Наверное ещё стоит сказать, что, проверяя классы на "is a", нужно чтобы они были только "is a", без всяких ограничений, в духе "этот класс - это вот этот класс, только с такими вот особенностями...". В видео про LSP в SOLID был хороший пример с прямоугольником и квадратом на эту тему

Читали ли Столярова А.В. и его Введение в профессию. Азы программирования?

Сергей, а можете рассказать, почему Абстракция - не принцип ООП?)

@0imax

3 жыл бұрын

Потому что всё программирование - абстракция, и ооп тут никак не выделяется :)

Сергей, куда задавать вопросы? Если в комменты, то вопрос не по теме видео: На практике как пользуются гитом (или аналогами)? В плане через консоль или с помощью ide? Некоторые ide позволяют подключиться к репозиторию и управлять ветками, коммитами и всеми необходимыми вещами. Но, слышал, что это не очень хороший тон, и лучше пользоваться напрямую git bash (или аналогами). Что Вы думаете насчет этого?

@tolik8

4 жыл бұрын

А что тут думать, на этот вопрос Сергей уже не раз отвечал, нужно просто сесть и выучить, основы гита учатся за день-два

@SleePokeR

4 жыл бұрын

Мне нравится Git Extensions. На работе посоветовали, с тех пор не вижу особого смысла сидеть в консоли гита. Хотя, конечно, если если есть шанс, что придётся юзать Git чисто из консоли, то явно проще учить основы, команды и как его красиво настроить, чтобы бранчи нормального видеть и историю коммитов.

@AllWayToDeath

4 жыл бұрын

@@tolik8 не совсем понял. А почему такой ответ? Чем обоснован? Сергей отвечал? На канале есть видео? Хорошо, поищу

@tolik8

4 жыл бұрын

@@AllWayToDeath сори, мой косяк, я очень бегло прочитал вопрос и подумал что вопрос: пользоваться гитом или нет

@AllWayToDeath

4 жыл бұрын

@@tolik8 ааа, ахах, бывает:)))

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

Пример с сотрудниками в корне некорректен. Если бухгалтер и инженер не являются наследниками класса Person или Employee, совсем не обязательно, что нужно их перебирать как три отдельных списка. Достаточно реализовать интерфейс и приводить их к интерфейсу. Более того, если они не разделяют какой-то базовой общей логики и состояния, лучше использовать интерфейс. GOF-паттерны используют в своих примерах наследование, так как на тот момент не нахватали граблей, и это был самый привычный пример переиспользования кода. Не затронута главная тема, почему не стоит использовать наследование: для наследования класс нужно внимательно проектировать, чтобы не сломать логику работы его наследников. Это подробно рассказано в 4-й главе у Джошуа Блоха, которую читал каждый Java-программист, старше джуниора.

@user-xc5cx7lh4l

4 жыл бұрын

Интерфейс - частичный случай класса, получиться то же наследование.

@liamsmith7052

4 жыл бұрын

@@user-xc5cx7lh4l Термин "Наследование" употребляют с интерфейсом, но это не значит, что класс - частный случай интерфейса. Класс подразумевает под собой наличие полей и состояния, коих нет у интерфейсов. Потомок класса и реализация интерфейса, это два разных понятия, и это не мелкая неточность, это ошибка. В энциклопедии британнике нет чёткого понятия базовых принципов ООП, из-за этого часто бывают споры, зачастую, бестолковые, но пример всё равно тяп-ляп)

@0imax

4 жыл бұрын

@@liamsmith7052 Всё верно. Если у классов сотрудников нет общего кода - делаем через интерфейсы, если есть - через наследование. Обычно он всё-таки есть, поэтому пример вполне норм.

@grommaks

4 жыл бұрын

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

@liamsmith7052

4 жыл бұрын

​@@grommaks отсутствием возможности создавать экземпляры и хранить их состояние.

Ещё бы понять что такое делегирование простым языком))) Мне лишь приходит что-то из разряда "делегат", "ссылка на метод" и пр.

@0imax

4 жыл бұрын

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

@homo-ergaster

4 жыл бұрын

Не внутри класса А заводится класс В, а объект класса А параметризуется объектами класса В. Типа: public class B { public int getInt(){ return 0; } } public class A{ private B b; public int getInt(){ return b.getInt(); } }

@user-botogame

4 жыл бұрын

@@0imax "заводится класс В" - по русски называется эксплуататор))))

@maxlich9139

3 жыл бұрын

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

Вообще то когда то нужно было делегирование (вложенность) инкапсуляции, но не смогли такое реализовать: ................................................. //сценарий function Помывка_ДОМА(){ $дом = new ДОМ(); $дом->помыть_всё(); if($дом->Туалет->чисто == 'нет'){ $дом->Туалет->помыть(); } if($дом->Кухня->чисто == 'нет'){ $дом->Кухня->помыть(); } } //реализация сценария class ДОМ{ class Туалет{...}; class Кухня{...}; function помыть_всё(){ $this->Туалет->помыть(); $this->Кухня->помыть(); } } //выполнение Помывка_ДОМА(); ................................................. p.s. наследование = тунеядство какого то класса?)))

Сергей, ну не серьезно. Где схемы? Одной говорящей головы не достаточно, чтобы такую тему раскрыть.

А если использовать вместо наследования классов, имплементацию интерфейсов?

@0imax

4 жыл бұрын

Наследование и имплементация интерфейсов используются для разных целей. Можно и вместо ложки пользоваться вилкой, но...)))

@konstantingeist3587

4 жыл бұрын

@@0imax Неверно, частично они совпадают. У интерфейса и abstract class много общих паттернов использования. По факту в Java их отделили тупо чтобы реализовать множественное наследование, сгладив проблемы diamond problem

@0imax

3 жыл бұрын

@@konstantingeist3587 В том-то и дело, что частично. Но в последнее время какая-то тенденция избегать наследования даже там, где оно явно должно быть. И начинается: отдельный класс с общими данными, с общими методами, перегонка данных туда-сюда, полиморфизм на интерфейсах и прочие костыли, хотя можно было просто написать extends, и от этого бы никто не умер :)

круто - даешь еще

@SergeyNemchinskiy

4 жыл бұрын

обязательно)

Все против именно наследование между классами, пример который Вы привели, спокойно наследуемый по Интерфейсам

@0imax

4 жыл бұрын

Но в таком случае общий код некуда будет положить.

@konstantingeist3587

4 жыл бұрын

@@0imax Общий код можно положить в сторонний класс. Часто вообще бывает, что "общий код" высосан из пальца и не является какой-то осмысленной бизнес-логикой, а просто парой-другой похожих строк тривиального инфраструктурного кода, который можно спокойно продублировать, но из-за которого развели сложную иерархию в погоне за "code reuse". Есть вот premature optimization, тут нужен термин вроде premature code reuse.

@0imax

4 жыл бұрын

​@@konstantingeist3587 "Часто вообще бывает, что "общий код" высосан из пальца" В говнокоде всякое встречается))

@user-botogame

4 жыл бұрын

Когда нужна вложенность инкапсуляции, то видимо хотели (но не смогли) так реализовать: class ДОМ{ class Туалет{}; class Кухня{}; } $дом = new ДОМ(); $дом->Туалет->помыть();

@konstantingeist3587

4 жыл бұрын

@@0imax Ну я вот давно замечаю, что у многих программистов есть такой условно-безусловный рефлекс, при котором завидев две-три одинаковых строчки из разных мест возникает горячейшее желание сделать "code reuse" и создать какой-нибудь нелепый общий метод, иначе ведь дублирование! В итоге со временем общий код обрастает говном и костылями, так как два оригинальных класса в коде начали различаться из-за новых требований, и всё это ещё супербажно т.к. меняя что-то в общем коде под новый кейс для одного класса/функции ненароком меняется поведение для другого класса-клиента и т.д. Поэтому если и выводить в общий код, то только если это осмысленная логика, которую сложно повторить -- и в таких случаях лучше бы подошёл отдельный самодостаточный класс, а не костыли вроде protected-методов в базовом классе или утилитные классы-помойки.

Можно использовать методы у супер класса который общий для всех и объявлять новые методы которые присущи только этому подклассу.

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

надеюсь на ваших курсах объясняют лучше.....

Посмотрел 1 раз и понял 10-15% объяснений -) Посмотрю еще раз 10 - наверняка процентов 30 ещё дойдёт

У меня вопрос, а мне на собесе в бубен не дадут, если я скажу что интерфейс это класс?

@user-um6fj1us4c

4 жыл бұрын

Зависит от языка. Например, в C++ нет такой языковой структуры, как интерфейс. И роль интерфейса берут на себя классы, при этом не особо даже принято говорить "интерфейс", принято говорить ABC (Abstract Base Class). Есть другие языки, где интерфейс - это языковая конструкция, которая отличается от класса, тем, что от интерфейса нельзя наследоваться.

Использую композицию, и плюю на наследование

Часы и очки как у Сереги)))может это значить что я тоже программист??))))

@maxlich9139

3 жыл бұрын

это комбо-набор, вместе дают + 100 к интеллекту и +50 к разговору) А да, еще и харизму повышает на 80 пунктов))

А как его теперь зовут этого мужика?

🔔Можно ли в конструкторе вызывать сеттер? В интернете мнения разделяются 50 на 50. Заранее спасибо

@konstantingeist3587

4 жыл бұрын

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

@agentr227

4 жыл бұрын

@@konstantingeist3587 сеттер не ссылается ведь на какие-то данные. Он лишь устанавливает значение, если оно подходит условиям. Но как тогда инициализировать данные по условиям, чтобы я не мог ,например, атрибуту "размер" присвоить значение -10 ?

@agentr227

4 жыл бұрын

@@avazart614 то есть каждый сеттер обязательно должен бросать исключение, правильно я понял? И если в сеттере находится лишь инициализация атрибутов с проверкой условий, то я могу в конструкторе вызывать сеттер? Как в серьезных проектах решается проблема проверки данных при вызове конструктора?

@konstantingeist3587

4 жыл бұрын

​@@agentr227 Сеттер вполне может ссылаться на данные. Например, у нас есть инвариант "ширина прямоугольника не может быть больше высоты". Польза сеттеров не столько в сокрытии переменной (сокрытие это не самоцель), сколько в возможности валидации инвариантов (бизнес-правил). Т.е. в сеттере установки ширины мы должны провалидивировать инвариант, а сделать мы это можем в нашем случае прочитав значение "высота" и сравнив с новым значением ширины. И если вызывать сеттер в конструкторе, то это не очень безопасно, т.к. объект по факту не до конца ещё проинициализирован, а метод ожидает, что он уже полностью сформирован (т.е. значение высоты может быть ещё не установлено, тогда наша валидация была некорректной).

@maxlich9139

3 жыл бұрын

@@konstantingeist3587 ну почему, если конструктор сложный, то все можно распихать по методам. Хотя абстрактные (они же вроде бы виртуальные) методы в конструкторах... не знаю... насколько это нормально!?

У семьи есть наследование значит и у кода должно быть наследование

@imho10

3 жыл бұрын

У многих королевских семей не было наследования, особенно после расстрела царской семьи.

@UzaiXlebXD

3 жыл бұрын

@@imho10 всегда найдётся исключение :D

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

@tolik8

4 жыл бұрын

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

@user-botogame

4 жыл бұрын

За счёт взаимодействия между сущностями. перефразирую: как виндусу понять что запущена такая то программа. ответ: функцией в виндосе "проверка запущенной программы". / как проверить что собака не сдохла - ткнуть палкой, по результату тыкания делать выводы.

Полностью отказаться от наследования это, конечно, зашквар. Не зря столпы программирования говорят aggregation over inheritance, но не aggregation instead of inheritance. Т.е. следует предпочитать делегирование наследованию.

@user-botogame

4 жыл бұрын

Наследование, это когда кто то за тебя выполняет твои функции. В СССР раньше был срок за такое , как за тунеядство.)))))

@0imax

3 жыл бұрын

@@user-botogame когда за тебя - это делегирование, а наследование - когда ты выполняешь всю ту работу по дому, что и родители, но ещё и в школу ходишь :)

@user-botogame

3 жыл бұрын

@@0imax странно написал. В школу можно ходить и при делегировании и при наследовании. Только при наследовании телефон тебе подарили, а при делегировании дали на время. И если во втором случае разобьёшь - получишь щелбан. А в первом случае два. И если выше брать, то родители лишь делегировали школе свои полномочия на ребёнка.

@0imax

3 жыл бұрын

@@user-botogame В жизни всё так, но в программировании обычно всё через ж.. Как с прямоугольником и квадратом)

@user-botogame

3 жыл бұрын

@@0imax не через ж, а супротив авторитетства программирования. Медведев назвал правильное слово: разнотык. Я называю это дискредитацией. Словно бултыхание в болоте.

Ух сколько лишних проблем в языках со строгой типизацией. В языках с "утиной" типизацией с этим намного проще: взял всех сотрудников и сунул в общий список не зависимо от "класса".

@syberskyer

4 жыл бұрын

а ещё кто то напихал туда "пельмени" и "самолёты" ) , а ты и думай что на выходе делать.

@0imax

4 жыл бұрын

@@syberskyer А на выход подключаем мясорубку, которая всё это перемалывает в инты)))

@konstantingeist3587

4 жыл бұрын

В языке Go строгая типизация, но при этом есть утиная типизация в плане приведения структуры к интерфейсу -- если структура ведёт себя как утка, то она утка :) При этом все типы известны на стадии компиляции заранее, что экономит кучу времени. Очень удачный компромис. Это скорее в Java просто излишняя бюрократия/формализм.

@konstantingeist3587

4 жыл бұрын

​@@avazart614 В Go нет шаблонов, хотя сходство определённое есть с шаблонами в C++ в плане статической утиной типизации (в С++ если мы используем метод с сигнатурой S, то шаблон скомпилируется для любого типа T, у которого есть метод с сигнатурой S). Но в Go там немного другое, и попроще. В Go если структура имеет метод foo(int, int), то она автоматически реализует любой интерфейс, определяющий метод foo(int, int). Не нужно писать "implements" как в Java, и это решает множество архитектурных проблем, т.к. можно сделать так, чтобы структура из другого пакета реализовала твой интерфейс, даже не зная, что он существует (напр. полезно когда мы не владеем кодом из стороннего пакета; в Java пришлось бы писать адаптер-класс; также полезно для более элегантного dependency inversion -- т.к. благодаря такому подходу нет строгой привязки классов друг к другу).

никак не запомню как вас зовут

1C ТАКОЙ КОД БЕЗ НАСЛЕДОВАНИЯ.

ни че не понял... На каком языке говорили?

Программируйте на уровне интерфейсов а не на уровне реализации)

@homo-ergaster

4 жыл бұрын

Бывает что и интерфейса то нет, сразу реализация. Тот-же Thread в Java - это ни**я не интерфейс. Да и частенько нужна именно конкретная реализация, а не некий абстрактный интерфейс. Типа там какой-нибудь класс SomeEntityMySQLDAO и его уже не параметризуешь абстрактным DAOConfig, а прямо указываешь, что он хавает MySQLDAOConfig, иначе какой-нибудь чудик потом засунет в него MongoDBDAOConfig или что-то вроде и удивится происходящему.

@Alex11Fox

4 жыл бұрын

@@homo-ergaster Да, сергей как раз и говорил про DAO layer, что не надо там интерфейсы.

@user-botogame

4 жыл бұрын

Абстракция заключена в написании сценария (if-elseif-wait-click) программы, который и будет дергать ООП за ниточки.

Наследование нужно избегать. Полиморфизм реализуется через Интерфейсы (ну да, это типа наследование, но нет) Супер класс (базовый класс) может существовать, но никакого упоминания в коде о нем нигде не должно быть, его можно использовать только для уменьшения однотипного кода, но после пару правок придет понимание, что композиция (Делегирование) решает проблему использования кода куда лучше. При наследовании тестирование становится по сложности как rocket science. Не нужно так :) Далее если Dependency Ijection поддерживается только в конструктор (PHP Magento, Angular DI) то наследование сделает жизнь адом. По этому в реализациях DI делают инъекцию в setter (в метод). Ведь soLid принцип будет нарушен если переопределять конструктор. Я из лагеря тех ребят, которые нашли выход в композиции и имеют сотни аргументов чтобы не использовать наследование от базового класса. Magento 2 (PHP) имеет исходных классов ~25 000, во всех местах классических паттернов не использует наследование вообще, в большинстве мест базовой логики не использует наследование. В проекте на 2000 часов мы не использовали наследование ни разу. Проблем при обновлении нет, проблем поддержки нет, проблем с читаемостью нет. Magento 1 была построена на принципах наследования и protected модификаторов доступа. Основные расходы времени были на стыковку 3х вендоров в одном проекте...всем нужно было перебить один и тот же класс из ядра системы. Жду видео про полиморфизм, надеюсь там не будет рекламы наследования ;)

@user-botogame

4 жыл бұрын

"Magento 2 (PHP) имеет исходных классов ~25 000" Класс Дом, класс Квартира, класс Дом2, класс КвартираN и т.д. до кучи наркоманского раздрая вложенности. А ведь ещё там запрятан сценарий программы... Вообще то когда то нужна была вложенность инкапсуляции, но не смогли такое реализовать: class ДОМ{ class Туалет{...}; class Кухня{...}; function помыть_всё(){ $this->Туалет->помыть(); $this->Кухня->помыть(); } } $дом = new ДОМ(); $дом->помыть_всё(); $дом->Кухня->помыть();

Це випадково не ти вчив дітей інформатиці на дошкі, без компів? Десь так в 90х.

Ну нет у нее лап. Извините 😂

Вообщето наследованием расширяем свойства родительского класса !!!

15-20 уровней наследования - это ведь полный гящь

Видео для бывалых? Я ни слова не понял. Если продаваемый курс так же обьясняется, то, пожалуй, мне данный автор не подходит

вы не разделяете наследование и реализацию интерфейса. это только вводит в заблуждение

Рыбы и змея не животные

@user-nz2hh9po2r

4 жыл бұрын

есть только грибы, растения и животные

@user-um6fj1us4c

4 жыл бұрын

@@user-nz2hh9po2r Вирусы ещё.

@0imax

4 жыл бұрын

@@user-um6fj1us4c с вирусами вообще отдельная история)) До сих пор нет строгой договорённости, считать их живыми или нет.

@konstantingeist3587

4 жыл бұрын

@@0imax Вот если у отдела product development нет строгой уверенности, чем является вирус -- живым или нет, то что делать программисту, любящему иерархию наследования? ЧТД! :)

@user-nz2hh9po2r

4 жыл бұрын

@@user-um6fj1us4c да, еще и микроорганизмы

Спасибо!