Шаблоны разработки ПО. Шаблоны GRASP
ฝัง
- เผยแพร่เมื่อ 20 ต.ค. 2013
- Шаблоны разработки ПО. (Design patterns).Шаблоны GRASP
Повторение предыдущего курса для другой группы. Более сжато и надеюсь не менее информативно.
Весь плей-лист: • Шаблоны разработки ПО....
Обучение Wordpress Developer bit.ly/2TNZtCA
Обучение Solidity developer bit.ly/2AqLny5
Сайт учебного центра: bit.ly/2IlVIPq
![อาจารย์ยอด : ลุงแว่วเล่าเรื่องผี [ผี]](http://i.ytimg.com/vi/Fd2Qsy4dqpM/mqdefault.jpg)
Пересмотрел почти все Ваши лекции. Лекции про паттерны одни из самых лучших, если не самые лучшие. Рассказ про соль программирования. Рассказать об этом может только тот, кто съел ее много...
Все что откопал на ютубе нормального это вот этот курс, лайк!
Периодически просматриваю курс по паттернам и хочу сказать БОЛЬШОЕ СПАСИБО за четкостью и доступность лекций. Спасибо Вам Сергей что делитесь знаниями в столь-доступном формате
04:24 - Information Expert
13:52 - Creator
19:41 - Controller
27:20 - Low Coupling
41:30 - Polymorphism
Классная лекция! Рассказано живо и с глубоким пониманием (возможных) проблем на практике!
2008 - да наверно сейчас просматривается с ностальгией, и как тренинг читался и как слушался - уже наверно зубатые лиды, а тогда просто прознавали паттерны )
Огромное Спасибо за лекцию!
С нетерпением жду продолжения.
Очень хорошо объясняете. Спасибо большое!
Thanks so much for this video tutorial.
кайф, спасибо!
19:00 я против формулировки того, что класс должен отвечать только за одно. Попробуем смоделировать кота - он может кушать, прыгать, охотиться. Или современный телефон: он умеет звонить, запускать приложения, снимать на камеру и т.п. Это не противоречит ни принципам clean, ни принципам OOD. Там формулировка другая: класс должен иметь только одну причину для изменения. Или: нужно объединять единицы функционала, которые изменяются по одним причинам и разъединять функционалы, которые меняются по разным причинам
32:17 Насчёт объектов типа "Helper", aka "Утилитный класс". 33:26 А почему не использовать паттерн "Декоратор"? Например, как вот тут как раз про строки человек объясняет: th-cam.com/video/tipsMlJK6ek/w-d-xo.html
1:04:00 "Для того, чтобы провести хороший рефакторинг чужого сложного и запущенного кода..."
Нужно написать end-to-end, integration и unit тесты на весь этот кринж, и переписать весь этот кринж, используя TDD(вначале опираясь только на end-to-end, integration и unit тесты кринж кода, а потом все больше опираясь на свои unit, integration и end-to-end тесты, написанные при переписываниии кода с использованием методологии TDD), Clean Code и Clean Architecture Дяди Боба. А потом рефакторить как хошь.
В конце получаешь чистый протестированный код, написанный при помощи методологии TDD, который точно работает правильно, и ты это знаешь. И все остальные это знают. А тем, кто не знают и не верят, ты можешь доказать это без слов при помощи сети автоматизированных тестов в течение нескольких секунд.
про потоки в Controller подходит объяснение только для многопоточных языков, для PHP это не актуально например.
Спасибо большое за видео.
Очень познавательно и интересно, однако как мне кажется, кроме УМЛ Диаграмм не было бы лишним показывать код (правильный/не правильный)
***** согласен с Денисом , отличное видео но с кодом всегда
понятнее о чём конкретно идёт речь.
Спасибо.
а можно попросить Вас сбросить предлагаемый слушателям реферат по шаблонам. совершенно не хочется прерываться на конспектирование, уж очень интересно рассказываете.
спасибо.
Мне вот интересно, вы сами то представляете кусок кода весом в 300 МиБ, тем более индусского?
Мне кажется, Марк Симан в своей книге "Внедрение зависимостей в .NET" паттерн Creator назвал главным антипаттерном для DI/IoC под названием Control Freak и призвал всячески избегать его. Смысл в том, чтобы вынести все зависимости (создание и внедрение объектов ) на верх иерархии в Composition Root ,например, в ASP.NET MVC это фабрика контроллеров. И там, используя контейнер DI/IoC создавать и внедрять зависимости. Сергей, что Вы об этом думаете?
***** Я ввел Вас в заблуждение дотнетом. Это имеет такое же отношение и к Java. Вот пример. На уровне бизнес-логики нам нужно использовать объект из уровня доступа к данным. Исходя из шаблона Creator и собственной логики, мы создаем объект и используем его. Но вот незадача - уровень доступа к данным делает Ваш сосед и он не готов. Да и протестировать наш объект не очень получается. Так вот Марк Симан советует создать объект из уровня доступа к данным где-нибудь в Main() ака Composition Root, и внедрить этот объект ,например, через конструктор в наш объект бизнес логики. Теперь и отсутствие уровня доступа к данным не мешает и вообще полный TDD. На самом деле и объект бизнес-логики создается в Main(), чтобы разорвать связь с уровнем UI. Кстати созданием и уничтожением объектов в таком случае должен заниматься контейнер DI/IoC. Похоже, что постепенно некоторые паттерны отмирают. Еще недавно Фаулер говорил о Service Locator и вот Симан его объявляет антипаттерном. То есть выходит, что и Service Locator и Dependency Injection являются подмножествами Inversion of Control, но SL по отношению к DI является антипаттерном. Может я книжек перечитал?
Service Locator действительно является в некотором роде антипаттерном, тк он по сути своей God object и позволяет создавать кучу зависимостей в одном классе, нарушая при этом инкапсуляцию. Конечно этого можно избежать строго передав зависимости в конструктор класса, но сама возможность такого поворота событий и делает его антипаттерном. Возвращаясь к первому вопросу, шаблон Creator по моему субъективному мнению он помогает указать (особенно в сущностях ORM), кто за кого отвечает. Таким образом четко проводятся границы ответственности между классами, не позволяя (по соглашению, конечно) создавать экземпляры по всему приложения без логически связанных классов.
Нет, вы молодец
А можно поподробнее про интерфейсы?
Допустим у меня есть класс(NetworkEnvironment), который в зависимости от входящих параметров инициализируется с теми или иными переменными окружения.
Его наследует интерфейс аторизации пользователя.
Интерфейс реализуют два класса. Например UserSQL и UserNoSql
Кто собственно выбирает какую из реализаций использовать?
Судя по картинке, этим занимается интерфейс, но для этого в нём должен быть реализован тот же свич, что нереально.
* Интерфейс пользователя
классы должны выбираться на основании наименования окружения, определенного в NetworkEnvironment
Все замечательно. Спасибо огромное, но Cohesion произносится не так. Ухо режет...
почему то старые лекции по этой же теме больше нравятся, хотя там информацию и хуже видно
нет, в том то и дело что формально подача материала в новых видео как минимум не хуже, но в старых лекциях вы больше учитель, а в новых больше преподаватель. в старых вам интересен процесс обучения учеников(вы в процессе, потоке, возможно это и от студентов зависит), в новых появилось ощущение рутины и усталости некоторой, это влияет на легкость усвоение и просмотра лекций. в старых лекциях вам процесс был в удовольствие в большей степени, рассказали шаблон и смотрите на скрипение в мозгах у студентов, а в новых вы говорите - я понимаю что вам трудно. старые, пока только 2 серии посмотрел, они как сериал на одном дыхании смотрятся как любимый сериал. в любом случае лучше ваших лекций я не видел
а есть платные лекции по другим темам? в смысле не тренинги а именно standalone записи? где смотреть информацию? на email писать?