Дякую таким людям, які так легко все показують і розказують. Тепер не треба читати море інфи, щоб розібратись з кожним із патернів. Задумка чудова. Величезне дякую )))
Спасибо, объяснение хорошее. Только больно оторвано от реальности. Можно было рассказать о практическом применении шаблона, для вызова событий, например. Конечно об этом было вскользь упомянуто про c#, но можно было примером кода на java показать. Буду смотреть дальше, надеюсь, будет больше примеров из "жизни" программистов ))
Могу ошибиться, но ваш пример это уже почти паттерн "прокси". То есть клиент юзает обьект, унаследованный от неткорого интрефейса, а он в свою очередь юзает другой обьект, НО тоже унаследованный от этого же интрефейса.
Семантически художник это не фигура графики, тут логика будет тогда страдать Либо называть по другому интерфейсы, чтобы было понятно что да как Либо не нужно считать художника фигурой графики
Пример с официантом отличный. Потом повара делегируют пацанам сбегать за морковкой, те делегируют фермерам вырастить морковку, бац! - И планета крутится вокруг клиента.
Что делать если например если несколько классов у которых есть похожие методы, но одни из них принимают аргумент, а другие нет? Если шаблон Command, мне показалось, что он ровно про то же, что и Delegate. Но в моей программе есть команды которые принимают какой-то объект и есть те, что работают без агрумента. Как в этом случае быть?
Понимаю, что ответ запоздал, но все же может кто то задаётся таким же вопросом, поэтому отвечу. Различие есть, хоть и этот пример может подойти и под стратегию. Пример с поваром неплох, в нем повар перекладывает обязанности по приготовлению салата на поваренка и тем самым как бы сам готовит салат, но пользуясь чужими силами. А стратегия, в контексте салата, скорее бы выглядела так, что повар сам мог приготовить салат, нарезов при этом овощи по разному, например соломкой или квадратиком и т. д. И в дальнейшем если бы его попросили нарезать салат кругами, то он мог бы это вполне реализовать. Суть паттерна в том чтобы дополнить функционал чего либо, какой то новой реализацией, обойдясь при этом малой кровью.
В многих книгах паттерна Делегат не существует, это просто принцип проектирование "делегирование" а не паттерн "Делегирование". А на видео просто описан паттерн Стратегия.
Первый пример наглядный и простой и понятный. Во-втором ковариантность, попробуй объясни каким образом получилось передача интерфейса, который знает только названия без реализации в потомка? ))) Т.е. при передачи интерфейса, в более абстрактный тип кладется более конкретный, это классическая ковариантность. ))) Без этого понимания вся логика просто теряется, почему об этом не сказано, не знаю, это совсем не очевидно.
Лучше бы реализовал пример с кафе, который рассказал на словах. сразу был бы виден результат и смысл применения паттерна. То что было заказано с фигурами без полезно... можно было сразу в мейне создавать интерфейс и подкладывать в него объекты....
автор, твои уроки просто космос, только у меня вопрос : Почему нельзя было сразу в методе setGraphics на объекте "g" вызвать метод draw? Зачем лишний метод draw создавать в классе painter?
Хороший урок, но пример с рисованием не очень подходящий так как своей абстракцией уводить от главного смысла паттерна - содержать инстанс и вызывать его методы. Начальный пример с "А" и "В" получился нагляднее.
Как было не понятно в каких случаях и зачем применять делегаты, так и после просмотра осталось не понятно. А слбо подготовиться перед тем как снимать видео? Конкретно 10:55 на строке 13 ты передаешь аргументом нев Квадрат(), так если здесь уже есть объект Квадрат он може и нарисовать себя. Нахрена делегировать в чем преимущество делегирования пример не раскрывает. Так же видел оъяснение ооп. Мы можем умножить 2*2, а в ооп мы должны создать 2 класса а в третьем классе реализуем умножение. Здорово!? Да? Показано как, но не показано зачем, и очень хорошо показано "да ну его нафиг, можно прще".
Нет, тут наследования нет. Если разбирать пример с художником, то: 1. Создается интерфейс с каким-то методом. 2. Создаются классы, имплементирующиеся от интерфейса, реализующие его метод каждый по-своему (полиморфизм). 3. Создается класс, который должен реализовать метод каждого из ранее написанные классов. 4. Чтобы не прописывать заново все реализации, которые в реальном коде будут гораздо сложнее, создается объект класса и сеттер, который реализует этот объект тем, что в него передали. 5. Теперь нам нужно просто создать новый объект последнего класса, вызвать его сеттер и передать в него новый экземпляр того класса, метод которого мы хотим вызвать (круг, треугольник, квадрат) после этого. 6. Вызываем метод. Таким образом мы обошли наследование, которое не всегда возможно использовать (например наш класс уже имеет родителя, а наследование от 2х классов в Java нет), обошли копирование и переписание многих строчек кода, сделали код понятным и читаемым, менее ресурсоемким.
Лол. Оказывается я всё это время использовал Делигат. (Вообще, как-то бессмысленно это называть паттерном. До этого же легко додуматся. Кто вообще, будет два раза один и тот же метод писать?)
Капец, не понимаю, зачем придумали столько "кодовых имен" - шаблонов для названия само собой разумеющихся базовых вещей? Еще понять не могу, в чем смысл всех этих геттеров и сеттеров, которые пишут джависты, если существует ключевое слово final? Может кто-то внятно объяснить, зачем нужно генерировать столько мусорного кода, который только усложняет простые вещи?
Доброго времени суток. Столько "мусорного кода" требуется для того, чтобы обеспечить принципы инкапсуляции. Для чего нужно обеспечивать принципы инкапсуляции и какие последствия их необеспечения могут быть в проекте, можно посмотреть в гугле. Хорошая статья в avolberg.ru/theory/oop/encapsulation
Чего вообще? Ключевое слово final существует для того, чтобы что-то создавать в "замороженном" состоянии. К примеру переменную, которая не будет изменяться. Обычно, когда хотят создать константу в джаве пишут два модификатора - static final. static дает понять, что переменная или объект будет создан в памяти 1 раз. Причем тут геттеры и сеттеры? Геттеры и сеттеры можно сравнить с конструктором класса. Но причем тут final я чето не могу додуматься. Геттеры и сеттеры выполняют роль конструктора класса, только это более гибкий инструмент. Сеттеры устанавливают значения для экземпляра класса, геттеры возвращают эти значения.
При чем тут final? Представь, что нам , например, нужно чтоб переменная double имела только два знака после точки. Что лучше - делать округление в каждый раз или один раз написать сеттер?
Сам того не ведая шикарным образом объяснил идею *полиморфизма*
Круто!
Дякую таким людям, які так легко все показують і розказують. Тепер не треба читати море інфи, щоб розібратись з кожним із патернів. Задумка чудова. Величезне дякую )))
Можеш ще тут подивитися:th-cam.com/video/aKbSlgi5h68/w-d-xo.html або тут: th-cam.com/video/vNHpsC5ng_E/w-d-xo.html
8 лет назад, карл. всё еще пригождается людям!
Внутри каждого официанта живет маленький повар.
Отличное объяснение, спасибо!
Йо, на здоровье, скоро еще будет))
+9999999999999 лайков за то что нет в видосе рекламы + понятное объяснение. Спасибо за видео:)
Просто супер, очень рад что нашел Ваш канал! Спасибо огромное!
Хороший пример, автор объясняет все доходчиво. Спасибо
Спасибо за Ваш труд! Здоровья Вам процветания!
Не, в конце пример с кафе это больше про команду и взаимодействие посетителя-официанта-повара. Это из Head First и он у них просто шикарно описан
спасибо! в принципе, лучше было сразу юзать пример официанта. а вообще очень доступно поясняете! :)
Спаибо за видео, довольно доходчиво)
Про коктейльщика в голос))
Спасибо, объяснение хорошее. Только больно оторвано от реальности.
Можно было рассказать о практическом применении шаблона, для вызова событий, например. Конечно об этом было вскользь упомянуто про c#, но можно было примером кода на java показать.
Буду смотреть дальше, надеюсь, будет больше примеров из "жизни" программистов ))
Очень доходчиво! Благодарю за урок!
Шикарный урок! Спасибо огромное!
А ведь тут по сути и сам painter является реализацией graphics. Почему б тогда не сделать void draw(Graphics g){ g.draw() }
Могу ошибиться, но ваш пример это уже почти паттерн "прокси". То есть клиент юзает обьект, унаследованный от неткорого интрефейса, а он в свою очередь юзает другой обьект, НО тоже унаследованный от этого же интрефейса.
Семантически художник это не фигура графики, тут логика будет тогда страдать
Либо называть по другому интерфейсы, чтобы было понятно что да как
Либо не нужно считать художника фигурой графики
уже 2019, офигенное видео, огромное спасибо
2020 вообще-то
Пример с официантом отличный. Потом повара делегируют пацанам сбегать за морковкой, те делегируют фермерам вырастить морковку, бац! - И планета крутится вокруг клиента.
Что делать если например если несколько классов у которых есть похожие методы, но одни из них принимают аргумент, а другие нет? Если шаблон Command, мне показалось, что он ровно про то же, что и Delegate. Но в моей программе есть команды которые принимают какой-то объект и есть те, что работают без агрумента. Как в этом случае быть?
Спасибо за урок!
Отлично! Спасибо, лайк и подписка )
Спасибо! С первого раза понял!
А почему нельзя в классе Painter сделать метод draw(Graphics g) { g.draw; }? И в клиенте сразу обращаться painter.draw(new Square);?
а разве последний пример не является полиморфизмом?
Чем "Делегат" отличается от "Стратегии" ?
Понимаю, что ответ запоздал, но все же может кто то задаётся таким же вопросом, поэтому отвечу. Различие есть, хоть и этот пример может подойти и под стратегию. Пример с поваром неплох, в нем повар перекладывает обязанности по приготовлению салата на поваренка и тем самым как бы сам готовит салат, но пользуясь чужими силами. А стратегия, в контексте салата, скорее бы выглядела так, что повар сам мог приготовить салат, нарезов при этом овощи по разному, например соломкой или квадратиком и т. д. И в дальнейшем если бы его попросили нарезать салат кругами, то он мог бы это вполне реализовать. Суть паттерна в том чтобы дополнить функционал чего либо, какой то новой реализацией, обойдясь при этом малой кровью.
@@eugene8863 ахахах, поваренка
@@kek_pupold ну эт такой младший работник кухни. Хотя возможно нет, я далёк от общепита.
В многих книгах паттерна Делегат не существует, это просто принцип проектирование "делегирование" а не паттерн "Делегирование". А на видео просто описан паттерн Стратегия.
Первый пример наглядный и простой и понятный. Во-втором ковариантность, попробуй объясни каким образом получилось передача интерфейса, который знает только названия без реализации в потомка? ))) Т.е. при передачи интерфейса, в более абстрактный тип кладется более конкретный, это классическая ковариантность. ))) Без этого понимания вся логика просто теряется, почему об этом не сказано, не знаю, это совсем не очевидно.
Лучше бы реализовал пример с кафе, который рассказал на словах. сразу был бы виден результат и смысл применения паттерна. То что было заказано с фигурами без полезно... можно было сразу в мейне создавать интерфейс и подкладывать в него объекты....
Да, это принцип ООП - полиморфизм. Теперь знаю, что это - паттерн делегат.
автор, твои уроки просто космос, только у меня вопрос : Почему нельзя было сразу в методе setGraphics на объекте "g" вызвать метод draw? Зачем лишний метод draw создавать в классе painter?
Из примера непонятно зачем нужна данная прослойка, тем не менее спасибо за пример с официантом
Супер! Спасибо!
а как сделать автодописывание для system.out.println? задолбался постояно писать эту строку и еще ln постоянно дописывать?)
"sout" + ctrl + space в NetBeans. В других IDE смотри горячие клавиши.
ну и на том спасибо)
это называется автокомплит. Под контретной ОС и ИДЕ в интернете много информации.
syso и ctr+пробил
Если будешь юзать интел идею - пиши sout и он тебе допишет
Привет! Хотелось бы узнать, какой ноут у тебя?
макбук про 2012 года 15 ретина
Спасибо.
Alex N надеюсь, ты меня не собрался взламывать)))
Я не волшебник))) просто не знаю, какой взять, мнений много и про mac и про другие.
могу посоветовать.
Хороший урок, но пример с рисованием не очень подходящий так как своей абстракцией уводить от главного смысла паттерна - содержать инстанс и вызывать его методы. Начальный пример с "А" и "В" получился нагляднее.
Respekt
5:40
Как было не понятно в каких случаях и зачем применять делегаты, так и после просмотра осталось не понятно.
А слбо подготовиться перед тем как снимать видео?
Конкретно 10:55 на строке 13 ты передаешь аргументом нев Квадрат(), так если здесь уже есть объект Квадрат он може и нарисовать себя. Нахрена делегировать в чем преимущество делегирования пример не раскрывает.
Так же видел оъяснение ооп. Мы можем умножить 2*2, а в ооп мы должны создать 2 класса а в третьем классе реализуем умножение. Здорово!? Да?
Показано как, но не показано зачем, и очень хорошо показано "да ну его нафиг, можно прще".
Круто, но медленно
Полиморфичненько.
КОКТЕЙЛЬЧИК)
Klass!!!!!
thx
Так это же просто наследование, нет?
Нет, тут наследования нет.
Если разбирать пример с художником, то:
1. Создается интерфейс с каким-то методом.
2. Создаются классы, имплементирующиеся от интерфейса, реализующие его метод каждый по-своему (полиморфизм).
3. Создается класс, который должен реализовать метод каждого из ранее написанные классов.
4. Чтобы не прописывать заново все реализации, которые в реальном коде будут гораздо сложнее, создается объект класса и сеттер, который реализует этот объект тем, что в него передали.
5. Теперь нам нужно просто создать новый объект последнего класса, вызвать его сеттер и передать в него новый экземпляр того класса, метод которого мы хотим вызвать (круг, треугольник, квадрат) после этого.
6. Вызываем метод.
Таким образом мы обошли наследование, которое не всегда возможно использовать (например наш класс уже имеет родителя, а наследование от 2х классов в Java нет), обошли копирование и переписание многих строчек кода, сделали код понятным и читаемым, менее ресурсоемким.
Вот, честно. Объясняете хорошо, но примеры ужасные. Нужно брать реалистичные примеры, когда и где их можно использовать
Круто, но тут опасность NPE...
Лол. Оказывается я всё это время использовал Делигат. (Вообще, как-то бессмысленно это называть паттерном. До этого же легко додуматся. Кто вообще, будет два раза один и тот же метод писать?)
Не слишком ли много памяти уходит на создание бесполезной копии объекта? И к тому же! А кто очищать будет?! Это ж какая утечка идёт у вас.
+GrafMKristo garbage collector не слышал?
ParaBellum199316 слышал. Только не знал, что на Яве тоже реализован.
Вот так, прокоментировал, лишь бы прокоментировать - не разобравшись.
Капец, не понимаю, зачем придумали столько "кодовых имен" - шаблонов для названия само собой разумеющихся базовых вещей? Еще понять не могу, в чем смысл всех этих геттеров и сеттеров, которые пишут джависты, если существует ключевое слово final? Может кто-то внятно объяснить, зачем нужно генерировать столько мусорного кода, который только усложняет простые вещи?
Доброго времени суток.
Столько "мусорного кода" требуется для того, чтобы обеспечить принципы инкапсуляции.
Для чего нужно обеспечивать принципы инкапсуляции и какие последствия их необеспечения могут быть в проекте, можно посмотреть в гугле.
Хорошая статья в avolberg.ru/theory/oop/encapsulation
может тебе вообще не стоит программировать если ты задаешь такие вопросы?
Чего вообще? Ключевое слово final существует для того, чтобы что-то создавать в "замороженном" состоянии. К примеру переменную, которая не будет изменяться. Обычно, когда хотят создать константу в джаве пишут два модификатора - static final. static дает понять, что переменная или объект будет создан в памяти 1 раз. Причем тут геттеры и сеттеры? Геттеры и сеттеры можно сравнить с конструктором класса. Но причем тут final я чето не могу додуматься. Геттеры и сеттеры выполняют роль конструктора класса, только это более гибкий инструмент. Сеттеры устанавливают значения для экземпляра класса, геттеры возвращают эти значения.
При чем тут final? Представь, что нам , например, нужно чтоб переменная double имела только два знака после точки. Что лучше - делать округление в каждый раз или один раз написать сеттер?
что такое кома?