Тоже хотел спросить про этот момент: по спецификации ES6 через static определяются только методы, не свойства. Это новая спецификация или что? Явно не работает в стабильной ноде, зачем вы это используете?
Есть несколько спорных моментов в понимании автором паттернов: 1. Декоратор. Автор описал скорее порождающий паттерн, похожий на Прототип. Основная особенность декоратора - возможность навесить на объект несколько штук одновременно, при этом каждый из них будет расширять возможности базового класса. Например: на стандартный вывод лога в файл можно навесить декораторы отправляющий данные по почте, в телеграм, в слак. Причем повесить можно динамически в любой комбинации. 2. Фасад. Описана скорее Фабрика. Пример фасада: вы берете некую библиотеку (например компрессия видео) в которой милион методов, параметров и т.п. Но вам это все не нужно, поэтому вы делаете фасад с одним методом compress(filename, format) и уже внутри настраиваете сжатие или даже выполняете его в несколько проходов. 3. Flyweight. Здесь автор на верном пути, но пример не показывает самого главного - паттерн нужен для экономии памяти. Пример: нужно отобразить большой список автомобилей (объект Car) и рядом с каждой отобразить логотип. Логотип - это картинка, которая повторяется у разных объектов, но при этом занимает больше всего памяти. И вот картинку и нужно выделить из Car и хранить отдельно и уникально. Тогда отображая даже тысячу объектов нам возможно придется хранить только 1-2 картинки. 4. Chain of Responsibility. Тут автор дал маху и описал Method chaining, ничего общего с заявленным паттерном не имеющий. 5. Command. Похоже что автор вывернул шаблон на изнанку... :) т.к. обычно объект вызывает команду, а не команда объект. Смысл паттерна в том, чтобы унифицировать интерфейс команды и облегчить динамическое связывание объектов с разными командами. Например: ajax сохранение документа (как в Google Docs) можен происходить по нажатию на кнопку, по комбинации клавиш и по таймеру. Все эти элементы связываются с одной командой и вызывают ее метод execute. Таким образом алгоритм сохранения находится в одном месте - в команде. Но главное - нет никаких трудностей в присоединении этой же команды, например, к жесту мышью (gesture). 6. State. Здесь автор не решил проблему, а наоборот ее создал. Представим себе большое количество состояний, которые еще и меняются в зависимости от роли пользователя. Метод change сразу превращается в жестокий набор десятков if и даже хуже. Так вот паттерн State как-раз и предназначен решить создаваемую автором проблему. А решает он ее тем, что как-раз state определяет какое состояние будет следующим! Т.е. именно GreenLight должен решать какой свет будет после него и менять состояние светофора. Кстати, обратите внимание, что у автора после зеленого сигнала включается красный, хотя должен быть желтый. 7. Strategy. В целом автор все описал правильно, за исключение одного, однако же, принципиального момента: стратегия должна храниться внутри контекста (Commute). Здесь нужно понимать, что стратегия - это то, что выбирается и какое-то время используется в основном алгоритме. В нужно время стратегию можно изменить. Таким образом Commute как-раз и предназначен для того, чтобы вызвать стратегию, не упоминая ее саму (Commute.travel()). Тоесть в приложении будет всего несколько мест где стратегия будет выбираться или изменяться, во всех остальных (сотнях) мест мы вызываем ее опосредованно через контекст (Commute). И вот это как-раз и является целью данного паттерна. 8. Template. Такой поведенческий паттерн мне не известен, однако известен "Template Method". В данной части автор рассматривает простое наследование классов, не имеющее к поведенческим паттернам никакого отношения. Автору спасибо за возможность вспомнить и повторно проанализировать цели использования паттернов! :)
Дай бог вам здоровья. Я думал я один идиот и не вдуплил почему фабрика и фасад в этом примере одно и тоже почти, темплейт просто обычное наследование и так далее. Только начинаю погружаться в особенности паттернов в js, трудно найти живые примеры. Вы в 1 комментарии объяснили часть вопросов, которые возникали в процессе видео. 👍
Обычно паттерны, это ты смотришь на статью и после нескольких строк кода отпадает желание читать. А изучить нужно) Здесь настолько очевидные примеры, написаные на es6, что инфа сама влетает в голову. Причем все подходы начинают казаться очевидными. Ловишь себя на мысле, что так логично делать. Правда, видео смотрел на 1.5 скорости, но это никак не минус) Спасибо!
@@igorkugaudo8212 Другая логика. В слушателе, он сделал какой-то узконаправленный код, который не универсальный. Ниже ссылка на вики, можно сравнить (внизу es6). С синглтоном вообще ужасное объяснение, слышал звон, не знает где он. Синглтон нужен, приминительно к бд (как у него), что бы не создавать лишних подключений. Про это ни слова. И так во всем. Код у него работает, конечно. но шаблоны - это прежде всего понимание задачи которую он решает, грамотное применение для оптимизации, не дублирования и так далее. ru.wikipedia.org/wiki/%D0%9D%D0%B0%D0%B1%D0%BB%D1%8E%D0%B4%D0%B0%D1%82%D0%B5%D0%BB%D1%8C_(%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)
Паттерны по программированию Constructor, Factory, Prototype, Singleton, Adapter, Decorator, Façade, Flyweight, Proxy, Chain of Responsibility, Command, Iterator, Mediator, Observer, State, Strategy, Template. Для меня это взрыв мозга, их нужно выучить или просто знать об их существовании, есть вещи которые просто не укладываются в голове. Владилен Спасибо Тебе.
Понравилось как в твоём IDE автоматом выводит название переданных параметров в функции. Если кому интересно как так сделать в VS Code просто установите расширение JS Parameter Annotations.
если нужно изменить цвет названия этих параметров под вашу тему: то просто в settings.json добавьте нужный цвет: "workbench.colorCustomizations": { "jsannotations.annotationForeground": "#697098" },
Chain of responsibility, показанный тут, на самом деле является паттерном под названием "Builder". "Chain of responsibility" сам по себе подразумевает, что у нас есть разные классы, совместно выполняющие какую-то сложную задачу, и реализован механизм передачи данных от одного класса к другому по мере обработки данных.
Как обычно, спасибо за видео) Но Chain of responsibility - это явно что-то другое. На мой взгляд, в этом видеоролике просто показан fluent API в классе MySum, основанный на method chaining
Никто не знает с чем столкнется в реальности. Все примеры уникальные, по опыту скажу, что далеко не всегда реальный пример может помочь в дальнейшем. Среди проектов куча легаси и костылей. Так что такие примеры как бальзам на душу.
Отличные уроки на темы которые давно надо было осветить в таком ключе. Такой контент беспорно очень тяжело готовить и объяснять. Я бы только предложил во время объяснения чего-либо давать чуть больше реальных примеров из жизни, где это можно было бы применить, давай больше кейсов чтоли. Такая проблема у всех, кто объясняет JS - часто примеры оторваны от реальности, пока сам 40 раз не напишешь - не поймешь. Т.е. я смотрю к примеру про прокси, да это круто и волшебно, но как встроить в текущую работу - не очень понятно. Тоже с паттернами, давно хотел ознакомится с ними подробнее и из видео к сожалению не очень понял, как мне здесь и сейчас использовать некоторые из них. А так все видео - 5 баллов и это лучший контент, что я видел на данную тему. На днях куплю курс по Fullstack разработке. Большое спасибо и успехов!
владилен часто в твоих видео встречаю "создаем что-то и оно будет стейтом...", вот хочется как-то по проще что ли, ну и было бы практичнее если бы ты разбирал на более живых примерах, в духе при работе в домом, но опять же на твой вкус и такие голые примеры тоже очень полезны, спасибо за контент)
Видео отличное! То, что нужно, для подготовки к собесу. Удивили комменты в стиле "а где точка с запятой?" "а не говорите нам 'господа'" - вы правда из видео только это смогли подчерпнуть?! а че не спрашиваете 'почему отступ в 2 пробела, а не 4' ? Владилен, терпения Вам и не терять мотивацию для создания нового контента. Ну, и 1000 лайков на 16000 просмотров - камон, ребята, вам лень нажать на "пальчик"? Будьте щедрее на лайки)))
Очень вскользь, хотелось бы поподробней, с несколькими примерами. Либо хотя бы больше уточнений, например какие бывают декораторы, что декорировать можно не только класс. Но в целом очень круто, ничего подобного на русском не видел.
кстати было бы прикольно видео (там даже получилась бы серия видосов если многое охватывать) по алгоритмам и так же по юнит тестированию в частности Jest и Enzyme к примеру запилить... Народу понравилось бы точно
Очень полезно для меня, как раз собирался изучить теорию по паттернам и затем практиковаться с одним проектом. Начал смотреть на другом канале, но проблема в том, что примеры слишком упрощённые и не понятно, где многие шаблоны вообще можно использовать. Спасибо за полезные видео.
как новичок, могу сказать, что лично мне в данном видео тоже нихера не понятно, как это все может быть использовано в реальности. Зачем создавать 3 класса, а потом создавать 4й, который будет разруливать косяки первых трех, если ... можно было изначальн сделать просто 1 нормальный класс?)) Зачем мутить какую-то дичь с observer, чтобы плюсануть циферку на 1?
Думал смотреть долго , не буду ... Думал почитаю топ 10 паттернов и дело в шляпе , ну и примерчики посмотрю и все ... НО после первого паттерна я понял что нужно искать тетрадку и записывать все по его словам , потому что этот человек приводит жизненные примеры которые ну очень важны ! Удачи тебе Vladilen !
Здравствуйте Владилен, в Singleton (25:30) относительно - "Database.instance = this", в developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Classes нашел нечто подобное, "Статические (class-side) свойства и свойства прототипа должны быть определены за рамками тела класса: Rectangle.staticWidth = 20;" Но это не то что у Вас. Подскажите пожалуйста, где найти материал на тему, создать поле (свойство) класса использую имя класса, например - Database.instance ? Спасибо.
Спасибо за твои видео, на ютубе много курсов по базовому ЖС а вот по такому продвинотуму намного меньше (если вообще есть), продолжай делать такие видосики) и еще по продвинотому ангуляру (практикум какой то), спасибою
Владилен здравсвуйте, подскажите пожалуйста, что бы посоветовали почитать по основам ООП в контексте JS. Я Сейчас как раз на стадии изучения классов и прототипов, далее в планах React. Спасибо
спасибо за видео! 14:50 - для чего указывать в 30 строчке ... || MemberFactory.list.simple , если до этого в 29 строчке для параметра type указали значение по умолчанию "simple"?
Владилен, скажи пожалуйста, а почему ты не ставишь точку с запятой в конце строки, я просто читал в интернете про то, что если проект большой, то в некоторых случаях, перенос строки JS не будет интерпретировать, как её окончание. Насколько это вероятно (правдоподобно)? И стоит ли над этим заморачиваться? Заранее большое спасибо
Владилен, а насколько часто на работе приходится ими пользоваться? Ты показал достаточно много паттернов, значит, ты ими пользовался в реальной разработке?
Я думаю, было бы лучше, если бы ты сделал вместо одного большого видео целый плейлист по шаблонам проэктирования. Во-первых, было бы больше просмотров(суммарно) и удержание было бы выше. Во-вторых, можно было бы больше уделить внимания конкретному паттерну. В-третьих, было бы удобней юзерам, так как не пришлось бы перематывать или спускаться в коменты к тайммапу, чтобы вспомнить или узнать про конкретный паттерн. В-четвёртых, привлеклось бы больше новых сабов. Хотя, в последствии, времени на съёмку ушло бы больше)
Прототип не верная реализация, прототип это посути просто добовление методов клон к своим объектам и всё, не больше не меньше, смысл в том чтобы созданием клона занимался сам объект. Про фабрику можно было добавить, что когда мы в фабрике ставим новые свойства это уже патерн строитель, тое ваша реализация это комбинация 2х паттернов. Chain of Responsibility вообще не то, цепочка обязанностей это когда у нас классы с большой вложенностью, дочерний вызывает какой нибудь эрор, и все классы по цепочке вызывают эрор у себя и у родителя, и каждый на своем уровне что то делает, ну или не делает, а потом просто вызывает родительский super.error(...arg), то есть в этом патерне метод который цепочный обязательно должен быть у всех классов потомков, а то что вы показали это просто каррирование на классе. Паттерн команда, а описываете стратегию, команда это по сути просто небольшой рефакторинг когда мы класс "кнопка удаления" делаем просто "кнопка" более универсальная штука, с полем команда в которую засунули нашу функцию как поле класса, которая что то удаляет. В медиаторе нужно было добавить, что его смысл в том что юзеры друг с другом вообще не взаимодействуют у них нет никакого механизма общения и всё они делают через посредника, это основная его задача для наглядности обычно делают 3 класса разных чтобы было понятно, что 1 общается с 3 тока через 2. Это реально важно потому что этот паттерн реализуют обычно когда уже у нас зоопарк сущностный связанных друг с другом хз как и чтобы как то упорядочить делают всех связанными только с одним медиатором а он уже разруливает. Стратегия у вас это просто наследование хз я патерна не 1 из существующих не уловил. В целом интересно было посмотреть, и вообще пофиг как что называется главное это помнить сам паттерны а не названия, мне например знание названий тока на собесе помогло)
Меня еще в реализации паттерна "состояние" смущеает, что светофор знает про все свои состояния и управляет логикой их переключения (например, если он в состоянии "желтый", он знает, что нужно переключиться в состояние "зеленый"). Я не уверен, возможно такие варианты исполнения тоже существуют, но тогда смысл от всех этих классов с состояниями? Они же призваны убрать логику из основного класса, а не просто хранить в себе кусочки кода.
Владилен, спасибо огромное за данное видео, оно было очень полезно! Но у меня возник вопрос: является паттерн "модуль" в JS до сих пор актуальным? Ибо одни говорят о том, что ES6 решил эту проблему описанную в паттерне, другие говорят о том, что он до сих пор востребован. Хотелось услышать ваше мнение на этот счёт, заранее спасибо.
Владилен, если не секрет где ты работаешь? Фрилансишь на апворке или в компании. B сколько ты зарабатываешь в месяц? Просто интересно))) И сколько лет ты уже в программировании? Хочу просто понять сколько нужно потратить лет чтобы иметь такой опыт и сколько можно зарабатывать в перспективе
Объяснение паттрена адаптер никак не проясняет момент "зачем". Другими словами зачем мне создавать новый класс что бы использовать старый класс? Какой от этого профит кроме оверкодинга с целью заюзать паттерн? Еще более другими словами - не раскрывается смысл и плюсы от создания адаптера. Еще совсем другими словами - ты вызываешь один и тот же метод .operations с одним и тем же интерфейсом на разных инстансах. В чем смысл? По мне так если есть некий новый класс с новым интерфейсом то он должен использовать класс Адаптер которые подгоняет интерфейс старого класса под новый. В примере этого нету.
Ну как теория для собеседования сойдет, практический новичку будет нереально сложно понять где какой из этих паттернов использовать и как их использовать. Можно снять получасовое видео по самым наиболее популярным паттернам с использованием в разработке какого нибудь приложения. Вот идея для видео
Спасибо за видео! В 14_observer можно добавить отписку. Позволит в ручную удалить подписчиков вместе с уничтожаемым классом/компонентой. В результате - чистая память (или без утечек памяти, aka memory leak) без бесхозных подписчиков.
Отлично, доступно и интересно. Хотелось бы услышать Ваше экспертное мнение по поводу PWA-приложений. Их роль, перспективы ну и по возможности примерчик. Спасибо.
Привет, спасибо за отличный видос, есть вопрос по паттерну фасад. Куда сохраняются все жалобы из переменной complaints в родительском классе? нужно делать геттер чтобы их получить?
Еще бы хорошо: 1) Abstract Factory или Factory Method, Builder (какой с них Factory с урока) 2) Bridge, Composite 3) Interpreter, Memento, Visitor Акаунт у вас на facebook или linkedin есть ?
Владилен, спасибо за видео! Но шаблон Цепочка Обязанностей описан вами неверно. Цепочка обязанностей - это поведенческий паттерн проектирования, который позволяет передавать запросы последовательно по цепочке обработчиков. Каждый последующий обработчик решает, может ли он обработать запрос сам и стоит ли передавать запрос дальше по цепи. refactoring.guru/ru/design-patterns/chain-of-responsibility
Примеры были бы гораздо более понятны, если бы ты не только по ходу написания кода давал комментарии, что происходит, но и в самом начале бы объяснял, что вообще мы хотим сделать. Потому что сейчас получается: я создам класс такой-то (зачем?), у него будет метод такой-то(зачем?) и он будет возвращать то-то (зачем?). И только в самом конце примера, человек начинает догадываться зачем все это делалось (вот теперь понятно для чего). И теперь сравни степень понимания, если бы ты сначала объяснил что конкретно мы будем делать, а потом: я создам класс такой-то (понятно для чего), у него будет метод такой-то (понятно для чего) и он будет возвращать то-то (понятно для чего). В том же chain of responsibility. Сказал бы: наша задача сделать так, чтобы была возможность делать так sum1.add(1).add(2).add(3), для этого мы создадим класс MySum у которого будет этот самый метод .add() ... А то получается, что "текст задачи" у тебя в самом конце примера, и пока ты показываешь и рассказываешь "решение" - не понятно самое главное: решение ЧЕГО?
скажите пожалуйста, какие плагины используете в редакторе кода? интересует именно то, когда имена аргументов отображаются при вызове функций и создании экземпляров классов?
