Шаблоны разработки. Шаблоны GoF 5
Vložit
- čas přidán 22. 08. 2024
- Обновленный курс GRASP and GoF Design patterns - bit.ly/3AG79eG
💪 ПРОКАЧАЙ СВОИ ХАРД-СКИЛЛЫ ЗА 2 МЕСЯЦА!
Продолжение курса "Шаблоны разработки программного обеспечения". Шаблоны GOF 5
Плейлист • Шаблоны разработки. Вв...
Все материалы курса лекций (включая конспект лекций) на моем канале на SlideShare:www.slideshare....
Изучение C#/.Net bit.ly/2DXGAIt
Изучение WP Develope bit.ly/2DWTnuZ
![Налог на незнание JavaScript - [Hamster Kombat]](/img/n.gif)
Сергей, ваши лекции - это то, что я очень долго искал, просто открытие! Спасибо большое за ваш труд!
Совершенно бесподобно рассказано про MVC даже для текущей реальности 2021. Даже несмотря на новые расширения MVVM, MVP и прочие. Сергей произносит слова (иногда вскользь - как бы между делом) так важные для "окончательного" понимания! Спасибо, Сергей!
Огромное вам спасибо за лекции! вы очень крутой! одно удовольствие смотреть лекции
Шикарные лекции
Хороший пример для цепочки обязанностей - распаковка многократно инкапсулированных данных.
На примере TCP/IP:
Есть базовый класс Layer
Цепочка для tcp пакета:
EtherLayer -> IpLayer -> TcpLayer
Каждый Layer получает PDU с (которым он умеет работать), извлекает хидеры (из которых определяет чьи это данные) и PDU который передает ответственному обработчику.
00:04 State как делать таблицу переходов
06:58 Strategy
13:20 Прыжок в сторону (или как программист читает код)
16:24 Strategy заключение
17:32 Chain of Responsibility
32:32 Template method
40:51 MVC
Как обычно, очень полезно!
Напишите плиз, 3,5 или 7 паттернов, которые надо знать обязательно (из Вашего опыта) ?
Единственный момент, то, что сейчас пробуют вместо MVC использовать MV-VC
Сергей, планируются ли видео по энтерпрайз шаблонам?
Здравствуйте! Когда Вы рассказывали о паттерне Шаблонный метод, Вы сказали, что когда мы выносим родительский класс, то он обязательно должен быть абстрактным и не может быть интерфейсом. В Java 8 в интерфейсах появились дефолтные методы, следовательно этот класс можно делать интерфейсом.
Сергей, а что было в третьей части? А то после второй - пятая..
"Ни один компилятор не скажет, что вы припустили переход в состояние..." - это так, но ведь TDD практика приходит на помощь?
Здравствуйте! Вы говорили о том что шаблон State избавляет нас от скопления ифов, но получается что мы от части декомпозируем эти ифы по классам ну и уменьшем их колличество для удобства чтения, но полностью они не исчезают. Ведь все равно нам придется написать if для выбора какую конкретно стратегию выбрать(даже если этот выбор будет в отдельном классе)... И если вариантов много то вязанка может быть не маленькая. Или я что-то не так понял?
Хоть и совсем немного но я надеялся на чудо избавления от if else))). Большое спасибо за ответ.
Огромное спасибо за лекции.
Но по поводу MVC, я с вами не соглашусь.
А как же MVP? Работая с фрэймворком GWTPlatform, я убедился в мощи MVP на клиенте. MVP позволяет сделать иерархию из презентеров, например презентер главной страницы может подключить в себя презентер меню (при этом выбрать какой именно), презентер шапки или правого блока. Причем каждый из вышеописанных презентеров может иметь любую глубину вложенности. В классическом MVC это весьма затруднительно сделать, есть конечно HMVC, но он намного сложнее, и на мой взгляд, является костылем.
А как же компонентная архитектура используемая в агуляре 2,4?
Для настольного приложения MVC может и панацея, но для веба там дофига косяков.
Вообще, рассказывая о MVC, вы нарисовали какого-то сферического коня в вакууме. Вы нарисовали то, что сейчас на википедии лежит, но это статья за последние пару лет переписывалась раза 3 точно и как только эти стрелочки не рисовали.
А что касается реальной жизни, то Zend, Symfony, Yii, OnPHP реализуют это не так. Сложный веб-бэкенд писал только на PHP, как на других языках это делается не знаю, но OnPHP содран с какого-то из джава фрэймворков.
По поводу стрелки от C к V, вот пример:
пользователь бронирует апартаменты, и на клиенте это действие происходит пошагово. В случае валидации шага контроллер возвращает ответ клиенту, причем иногда сообщает ошибку, а это данные. Боле того, в данном примере в городе, который ввел пользователь, может апартаментов не оказаться, и проверить это - задача контроллера (в противном случае V напрямую запрашивает M), таким образом это получается еще стрелка от M к С.
Поправьте меня, пожалуйста, если я ошибаюсь.
По поводу стрелки от C к V
Смотря как организовывать контроллер. Если он просто превращает запросы пользователя в вызовы модели, то я бы поместил валидацию введенных данных в методы модели, и тогда никаких стрелочек от C к V не появляется. Ведь модель лучше знает, какие ей нужны данные, и когда проверка живёт там же, где эти данные обрабатываются, при изменении в модели не придётся лазить в контроллер и что-то там менять. А если в контроллере дофига кода, то насовывать в него ещё и проверки... Мне вариант с проверками в модели нравится больше.
Подскажите, можно ли немного видоизменять паттерны под свою задачу? Скажем, если в моей бизнес-задаче строго 2 наблюдателя, можно ли реализовать Observer без addObserver/removeObserver методов и передать наблюдателей сразу через конструктор?
Спасибо за ответ.
Можно все, но надо точно знать что количество наблюдателей и способи подписки будут одинаковими. Ну или наблюдателей не станет больше
Я понимаю, что прошло 3 года, и вы уже вероятно решили свою задачу, но что, если воспользоваться паттерном посредник (mediator)?