Хороший пример про рабочего коня, который делает все за всех). Только вот настоящий Тим-лид вроде должен только координировать и делегировать работу в команде.
Легче было бы привести всех разработчиков к общему интерфейсу и в классе реализации сеньора добавить метод кодРевью и внедретить в преопределённый метод интерфейса, а тут добавляем целый класс, чтобы добавить функциональность. Иногда использование паттерна избыточно.
Заебись пример, тем кому непонятно -> прочитайте пару статей на википедии, а потом сюда. там вам и диаграмки и выгоды использования покажут,,, а на ютубчике только код посмотреть можно. Еще раз спасибо автору
Если посмотришь книжки там всегда идет сначала мотивация на паттерн. Непонятно почему не сделать просто иерархию. Непонятно почему интерфейс developer а не класс
потому что с помощию только иерархии вы не сможете выполнить добавить к объекту некоторую дополнительную функциональность, которая будет выполняться до, после или вместо основной функциональности (логирование и прочее)
@@ivanandreev9571 Показанное в видео больше похоже на Wrapper. Декоратор должен иметь ровно тот же интерфейс что и декорируемый объект, хорошим примером может быть что-то вроде: Text text = new Capitalized(new Concatenated(new StringText("Hello, "), new FileText(new File("./world.txt")))); text.toString(); // HELLO, WORLD!
@@ksviety так декоратор в видео и имеет тот же интерфейс, а ещё если судить по книжке банды 4 wrapper и decorator два разных названия одного паттерна...
Это все мне очень напомнило: Вот дом, Который построил Джек. А это пшеница, Которая в тёмном чулане хранится В доме, Который построил Джек. А это весёлая птица-синица, Которая часто ворует пшеницу, Которая в тёмном чулане хранится В доме, Который построил Джек. Вот кот, Который пугает и ловит синицу, Которая часто ворует пшеницу, Которая в тёмном чулане хранится В доме, Который построил Джек. Вот пёс без хвоста, Который за шиворот треплет кота, Который пугает и ловит синицу, Которая часто ворует пшеницу, Которая в тёмном чулане хранится В доме, Который построил Джек. А это корова безрогая, Лягнувшая старого пса без хвоста, Который за шиворот треплет кота, Который пугает и ловит синицу, Которая часто ворует пшеницу, Которая в тёмном чулане хранится В доме, Который построил Джек. А это старушка, седая и строгая, Которая доит корову безрогую, Лягнувшую старого пса без хвоста, Который за шиворот треплет кота, Который пугает и ловит синицу, Которая часто ворует пшеницу, Которая в тёмном чулане хранится В доме, Который построил Джек. А это ленивый и толстый пастух, Который бранится с коровницей строгою, Которая доит корову безрогую, Лягнувшую старого пса без хвоста, Который за шиворот треплет кота, Который пугает и ловит синицу, Которая часто ворует пшеницу, Которая в тёмном чулане хранится В доме, Который построил Джек. Вот два петуха, Которые будят того пастуха, Который бранится с коровницей строгою, Которая доит корову безрогую, Лягнувшую старого пса без хвоста, Который за шиворот треплет кота, Который пугает и ловит синицу, Которая часто ворует пшеницу, Которая в тёмном чулане хранится В доме, Который построил Джек.
Может было бы лучше не создавать отдельные классы для SeniorJavaDeveloper и JavaTeamLead, а просто создать SeniorDeveloper и TeamLead ? А то получается, для каждого разработчика, который использует другой стек, нужно создавать отдельный класс ? Всё равно же у них есть поле Developer, значит не нужно привязывать класс конкретно к джава разработчику и джава тимлиду ?
Привет, автор. у тебя ошибка с точки зрения ООП. DeveloperDecorator должен бысть абстрактным, он является суперклассом для JavaTeamLead и SeniorJavaDeveloper. вот отрывок из книги: "AbstractWrapper. Абстрактный класс, выступающий в этой роли, - это общий суперкласс для классов-оберток. Экземпляры этого класса содержат такке ссылку на объект AbstractServiceIF, которому объекты ConcreteWrapper! делегируют операции." МАРК ГРАНД "шаблоны проектирования в JAVA" (для новичков поясню. AbstractWrapper это тот же декоратор) закрепи пожалуйста мой коммент или напиши свой. так, как ты это делал в прошлом видео
Я перечитал GoF по этому поводу и на данный момент, не вижу нарушений классического паттерна. С Марк Гранд не знаком, насколько я знаю GoF считается наиболее авторитетным изданием в контексте паттернов проектирования. Классы Developer, DeveloperDecorator и JavaDeveloper представляют основные компоненты паттерна декоратор. Developer - это интерфейс, определяющий базовые операции для разработчика. DeveloperDecorator - это абстрактный класс-декоратор, расширяющий Developer и предоставляющий базовую реализацию обертки для компонента. JavaDeveloper - это конкретная реализация компонента. Классы JavaTeamLead и SeniorJavaDeveloper представляют конкретные декораторы. Они расширяют DeveloperDecorator и добавляют дополнительное поведение к компоненту. JavaTeamLead добавляет функциональность отправки еженедельного отчета, а SeniorJavaDeveloper добавляет функциональность код-ревью. Класс Task демонстрирует использование паттерна декоратор. Он создает цепочку декораторов, начиная с JavaDeveloper, затем SeniorJavaDeveloper и, наконец, JavaTeamLead. Вызов метода makeJob() на объекте developer приведет к выполнению задания с добавленной функциональностью каждого декоратора. Если есть дополнительные замечания, обязательно просмотрю. Еще раз спасибо за комментарий.
Я тоже. Легче было бы привести всех разработчиков к общему интерфейсу и в классе реализации сеньора добавить метод кодРевью и внедретить в преопределённый метод интерфейса, а тут добавляем целый класс, чтобы добавить функциональность.
Уважаемый автор! А объясните пожалуйста, а почему вы систематически пишете Developer developer = new JavaDeveloper(); а не JavaDeveloper developer = new Javadeveloper(); Какие преимущества такая запись даёт? Она же более непонятная.
Уважаемый подписчик, объясняю :) Предположим, что у нас есть некий класс Project, который содержит коллекцию разработчиков разной специализации (т.е. наследников класса Developer - JavaDeveloper, CppDeveloper, PhpDeveloper). Для этого мы создаём List developers, в котором можем хранить любой класс, который является наследником Developer. Думаю дальнейшие преимущества понятны. Тоже самое исользуется и для самих коллекций, например: List strings = new ArrayList(); Set stingSet = new HashSet(); и т.д.
Иногда нет смысла обьяснять, у тебя будет класс с какой то библиотеки, который ты ну никак не можешь изменить, у тебя нет доступа к этому. Но тебе хочется, чтоб класс этот делал не только то, что он умеет, а чуточку больше, и у тебя в голове вспомнится про декоратор.
@@MrDepava то есть это по сути костыли. У нас, к сожалению, иногда предпочитают использовать странные решения, зато без "костылей" даже в виде паттернов.
так быстро и просто, что я нифига не понял. Посмотрю ещё раз
Евгений, спасибо большое за ваш труд!
Компактно, но информативно. Спасибо)
Было бы более понятно если сначала написать без патерна, а потом показать как то же самое можно решить с помощью декоратора
Если не в состоянии сами написать этот код до использования декоратора, тогда вам еще рано смотреть это видео.
Отличные видео. Коротко и ясно!
Спасибо за отзыв!
Спасибо, всё очень доступно!
Спасибо за отзыв!
Отличное видео.
Я бы показал еще результат вывода на печать при смене местами в Таск: Синьора и ТимЛида.
Спасибо за отзыв!
Хороший пример про рабочего коня, который делает все за всех). Только вот настоящий Тим-лид вроде должен только координировать и делегировать работу в команде.
Шутка, юмор … :)
Легче было бы привести всех разработчиков к общему интерфейсу и в классе реализации сеньора добавить метод кодРевью и внедретить в преопределённый метод интерфейса, а тут добавляем целый класс, чтобы добавить функциональность.
Иногда использование паттерна избыточно.
Очень круто! спасибо! сохранил на всякий случай!)
Заебись пример, тем кому непонятно -> прочитайте пару статей на википедии, а потом сюда. там вам и диаграмки и выгоды использования покажут,,, а на ютубчике только код посмотреть можно. Еще раз спасибо автору
Мой любимый структурный паттерн
Если посмотришь книжки там всегда идет сначала мотивация на паттерн. Непонятно почему не сделать просто иерархию. Непонятно почему интерфейс developer а не класс
Потому что наследование это ужасно, а так в видео паттерн вообще не правильно показан
@@ksviety почему неправильно?
потому что с помощию только иерархии вы не сможете выполнить добавить к объекту некоторую дополнительную функциональность, которая будет выполняться до, после или вместо основной функциональности (логирование и прочее)
@@ivanandreev9571 Показанное в видео больше похоже на Wrapper. Декоратор должен иметь ровно тот же интерфейс что и декорируемый объект, хорошим примером может быть что-то вроде:
Text text = new Capitalized(new Concatenated(new StringText("Hello, "), new FileText(new File("./world.txt"))));
text.toString(); // HELLO, WORLD!
@@ksviety так декоратор в видео и имеет тот же интерфейс, а ещё если судить по книжке банды 4 wrapper и decorator два разных названия одного паттерна...
Спасибо большое за видео!
Это все мне очень напомнило:
Вот дом,
Который построил Джек.
А это пшеница,
Которая в тёмном чулане хранится
В доме,
Который построил Джек.
А это весёлая птица-синица,
Которая часто ворует пшеницу,
Которая в тёмном чулане хранится
В доме,
Который построил Джек.
Вот кот,
Который пугает и ловит синицу,
Которая часто ворует пшеницу,
Которая в тёмном чулане хранится
В доме,
Который построил Джек.
Вот пёс без хвоста,
Который за шиворот треплет кота,
Который пугает и ловит синицу,
Которая часто ворует пшеницу,
Которая в тёмном чулане хранится
В доме,
Который построил Джек.
А это корова безрогая,
Лягнувшая старого пса без хвоста,
Который за шиворот треплет кота,
Который пугает и ловит синицу,
Которая часто ворует пшеницу,
Которая в тёмном чулане хранится
В доме,
Который построил Джек.
А это старушка, седая и строгая,
Которая доит корову безрогую,
Лягнувшую старого пса без хвоста,
Который за шиворот треплет кота,
Который пугает и ловит синицу,
Которая часто ворует пшеницу,
Которая в тёмном чулане хранится
В доме,
Который построил Джек.
А это ленивый и толстый пастух,
Который бранится с коровницей строгою,
Которая доит корову безрогую,
Лягнувшую старого пса без хвоста,
Который за шиворот треплет кота,
Который пугает и ловит синицу,
Которая часто ворует пшеницу,
Которая в тёмном чулане хранится
В доме,
Который построил Джек.
Вот два петуха,
Которые будят того пастуха,
Который бранится с коровницей строгою,
Которая доит корову безрогую,
Лягнувшую старого пса без хвоста,
Который за шиворот треплет кота,
Который пугает и ловит синицу,
Которая часто ворует пшеницу,
Которая в тёмном чулане хранится
В доме,
Который построил Джек.
проорал)
Может было бы лучше не создавать отдельные классы для SeniorJavaDeveloper и JavaTeamLead, а просто создать SeniorDeveloper и TeamLead ? А то получается, для каждого разработчика, который использует другой стек, нужно создавать отдельный класс ? Всё равно же у них есть поле Developer, значит не нужно привязывать класс конкретно к джава разработчику и джава тимлиду ?
Спасибо!
А разве этот шаблон не противоречит Single Responsibility Principle?
Привет, автор.
у тебя ошибка с точки зрения ООП.
DeveloperDecorator должен бысть абстрактным, он является суперклассом для JavaTeamLead и SeniorJavaDeveloper.
вот отрывок из книги:
"AbstractWrapper. Абстрактный класс, выступающий в этой роли, - это общий
суперкласс для классов-оберток. Экземпляры этого класса содержат такке
ссылку на объект AbstractServiceIF, которому объекты ConcreteWrapper!
делегируют операции."
МАРК ГРАНД "шаблоны проектирования в JAVA"
(для новичков поясню. AbstractWrapper это тот же декоратор)
закрепи пожалуйста мой коммент или напиши свой. так, как ты это делал в прошлом видео
Сверюсь с первоисточником и отпишусь. Большое спасибо за комментарий!!!
Я перечитал GoF по этому поводу и на данный момент, не вижу нарушений классического паттерна.
С Марк Гранд не знаком, насколько я знаю GoF считается наиболее авторитетным изданием в контексте паттернов проектирования.
Классы Developer, DeveloperDecorator и JavaDeveloper представляют основные компоненты паттерна декоратор. Developer - это интерфейс, определяющий базовые операции для разработчика. DeveloperDecorator - это абстрактный класс-декоратор, расширяющий Developer и предоставляющий базовую реализацию обертки для компонента. JavaDeveloper - это конкретная реализация компонента.
Классы JavaTeamLead и SeniorJavaDeveloper представляют конкретные декораторы. Они расширяют DeveloperDecorator и добавляют дополнительное поведение к компоненту. JavaTeamLead добавляет функциональность отправки еженедельного отчета, а SeniorJavaDeveloper добавляет функциональность код-ревью.
Класс Task демонстрирует использование паттерна декоратор. Он создает цепочку декораторов, начиная с JavaDeveloper, затем SeniorJavaDeveloper и, наконец, JavaTeamLead. Вызов метода makeJob() на объекте developer приведет к выполнению задания с добавленной функциональностью каждого декоратора.
Если есть дополнительные замечания, обязательно просмотрю.
Еще раз спасибо за комментарий.
Добрый день, подскажите что за плагин для диаграмм
Дима Артюхов - это встроенные диаграммы для платной версии программы(Enterprise Edition)
не поняла в чем преимущество шаблона
Я тоже. Легче было бы привести всех разработчиков к общему интерфейсу и в классе реализации сеньора добавить метод кодРевью и внедретить в преопределённый метод интерфейса, а тут добавляем целый класс, чтобы добавить функциональность.
top
Уважаемый автор! А объясните пожалуйста, а почему вы систематически пишете
Developer developer = new JavaDeveloper();
а не JavaDeveloper developer = new Javadeveloper();
Какие преимущества такая запись даёт? Она же более непонятная.
Уважаемый подписчик, объясняю :)
Предположим, что у нас есть некий класс Project, который содержит коллекцию разработчиков разной специализации (т.е. наследников класса Developer - JavaDeveloper, CppDeveloper, PhpDeveloper).
Для этого мы создаём List developers, в котором можем хранить любой класс, который является наследником Developer.
Думаю дальнейшие преимущества понятны.
Тоже самое исользуется и для самих коллекций, например:
List strings = new ArrayList();
Set stingSet = new HashSet();
и т.д.
То есть вы хотите сказать, что в List developers можно запихнуть все объекты, реализующие интерфейс developer? Тогда понятно. И очень доступно.
Именно.
Всегда пожауйста, Andy.
@@AndreyDeveloper механизм upcast-а
Привет, подскажи на 6 минуте видео ты как-то открыл диаграмму своих классов, как это сделать? Нужен планиг какой-то?
Нет, это стандартный плагин idea ultimate
@@EugeneSuleimanov Понял, спасибо
Тема не раскрыта. Пример то понятный. Но понять для чего это используется самое главное. Но приведённый пример не объясняет ничего.
Иногда нет смысла обьяснять, у тебя будет класс с какой то библиотеки, который ты ну никак не можешь изменить, у тебя нет доступа к этому. Но тебе хочется, чтоб класс этот делал не только то, что он умеет, а чуточку больше, и у тебя в голове вспомнится про декоратор.
@@MrDepava то есть это по сути костыли. У нас, к сожалению, иногда предпочитают использовать странные решения, зато без "костылей" даже в виде паттернов.
Т.е. используется, если нужно добавить какую-то дополнительную функциональность.
Да, все верно.
Delegate ?
как в IntelliJ IDEA показывать Диаграммы?
Это стандартный плагин для Ultimate edition
@@EugeneSuleimanov а для Community?
Кто-то что-то понял?))
эм... не понял, еще раз. :)
джаб - называют японцев. А работа - это джоб ! в простонародье вджобывать.
В американском акценте говорится ближе к "а". Например, никто не говорит в США hot как хот, они говорят хат.