Шаблоны разработки ПО. Шаблоны GRASP

[@yuriymykytenko2931]

Пересмотрел почти все Ваши лекции. Лекции про паттерны одни из самых лучших, если не самые лучшие. Рассказ про соль программирования. Рассказать об этом может только тот, кто съел ее много...

[@dayoff8863]

04:24 - Information Expert 13:52 - Creator 19:41 - Controller 27:20 - Low Coupling 41:30 - Polymorphism

[@pashakretsu8951]

Периодически просматриваю курс по паттернам и хочу сказать БОЛЬШОЕ СПАСИБО за четкостью и доступность лекций. Спасибо Вам Сергей что делитесь знаниями в столь-доступном формате

[@ilnurryazhapov]

Все что откопал на ютубе нормального это вот этот курс, лайк!

[@andyrudi]

Классная лекция! Рассказано живо и с глубоким пониманием (возможных) проблем на практике!

[@KulaGGin]

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, который точно работает правильно, и ты это знаешь. И все остальные это знают. А тем, кто не знают и не верят, ты можешь доказать это без слов при помощи сети автоматизированных тестов в течение нескольких секунд.

[@zisoua]

2008 - да наверно сейчас просматривается с ностальгией, и как тренинг читался и как слушался - уже наверно зубатые лиды, а тогда просто прознавали паттерны )

[@gru74ik]

32:17 Насчёт объектов типа "Helper", aka "Утилитный класс". 33:26 А почему не использовать паттерн "Декоратор"? Например, как вот тут как раз про строки человек объясняет: kzbin.info/www/bejne/qprTpICif7Bpm80

[@Fateslav]

19:00 я против формулировки того, что класс должен отвечать только за одно. Попробуем смоделировать кота - он может кушать, прыгать, охотиться. Или современный телефон: он умеет звонить, запускать приложения, снимать на камеру и т.п. Это не противоречит ни принципам clean, ни принципам OOD. Там формулировка другая: класс должен иметь только одну причину для изменения. Или: нужно объединять единицы функционала, которые изменяются по одним причинам и разъединять функционалы, которые меняются по разным причинам

[@ВебМастер-ж5ъ]

Очень хорошо объясняете. Спасибо большое!

[@telmertemp1284]

Огромное Спасибо за лекцию!

[@romantsyupryk3009]

Thanks so much for this video tutorial.

[@gor6821]

С нетерпением жду продолжения.

[@ТимурСафаров-в1ч]

про потоки в Controller подходит объяснение только для многопоточных языков, для PHP это не актуально например.

[@senegal8bit824]

кайф, спасибо!

[@gor6821]

Мне кажется, Марк Симан в своей книге "Внедрение зависимостей в .NET" паттерн Creator назвал главным антипаттерном для DI/IoC под названием Control Freak и призвал всячески избегать его. Смысл в том, чтобы вынести все зависимости (создание и внедрение объектов ) на верх иерархии в Composition Root ,например, в ASP.NET MVC это фабрика контроллеров. И там, используя контейнер DI/IoC создавать и внедрять зависимости. Сергей, что Вы об этом думаете?

[@gor6821]

***** Я ввел Вас в заблуждение дотнетом. Это имеет такое же отношение и к Java. Вот пример. На уровне бизнес-логики нам нужно использовать объект из уровня доступа к данным. Исходя из шаблона Creator и собственной логики, мы создаем объект и используем его. Но вот незадача - уровень доступа к данным делает Ваш сосед и он не готов. Да и протестировать наш объект не очень получается. Так вот Марк Симан советует создать объект из уровня доступа к данным где-нибудь в Main() ака Composition Root, и внедрить этот объект ,например, через конструктор в наш объект бизнес логики. Теперь и отсутствие уровня доступа к данным не мешает и вообще полный TDD. На самом деле и объект бизнес-логики создается в Main(), чтобы разорвать связь с уровнем UI. Кстати созданием и уничтожением объектов в таком случае должен заниматься контейнер DI/IoC. Похоже, что постепенно некоторые паттерны отмирают. Еще недавно Фаулер говорил о Service Locator и вот Симан его объявляет антипаттерном. То есть выходит, что и Service Locator и Dependency Injection являются подмножествами Inversion of Control, но SL по отношению к DI является антипаттерном. Может я книжек перечитал?

[@stepanenkostanislav5877]

Service Locator действительно является в некотором роде антипаттерном, тк он по сути своей God object и позволяет создавать кучу зависимостей в одном классе, нарушая при этом инкапсуляцию. Конечно этого можно избежать строго передав зависимости в конструктор класса, но сама возможность такого поворота событий и делает его антипаттерном. Возвращаясь к первому вопросу, шаблон Creator по моему субъективному мнению он помогает указать (особенно в сущностях ORM), кто за кого отвечает. Таким образом четко проводятся границы ответственности между классами, не позволяя (по соглашению, конечно) создавать экземпляры по всему приложения без логически связанных классов.

[@ВуйловДмитрий]

Нет, вы молодец

[@EshkinKot1980]

Мне вот интересно, вы сами то представляете кусок кода весом в 300 МиБ, тем более индусского?

[@ДмитрийРафалович-ц6ш]

а можно попросить Вас сбросить предлагаемый слушателям реферат по шаблонам. совершенно не хочется прерываться на конспектирование, уж очень интересно рассказываете.

[@ДмитрийРафалович-ц6ш]

спасибо.

[@rijen42]

А можно поподробнее про интерфейсы? Допустим у меня есть класс(NetworkEnvironment), который в зависимости от входящих параметров инициализируется с теми или иными переменными окружения. Его наследует интерфейс аторизации пользователя. Интерфейс реализуют два класса. Например UserSQL и UserNoSql Кто собственно выбирает какую из реализаций использовать? Судя по картинке, этим занимается интерфейс, но для этого в нём должен быть реализован тот же свич, что нереально.

[@rijen42]

* Интерфейс пользователя классы должны выбираться на основании наименования окружения, определенного в NetworkEnvironment

[@DenisG631]

Спасибо большое за видео. Очень познавательно и интересно, однако как мне кажется, кроме УМЛ Диаграмм не было бы лишним показывать код (правильный/не правильный)

[@Lecker9419]

***** согласен с Денисом , отличное видео но с кодом всегда понятнее о чём конкретно идёт речь. Спасибо.

[@mchi-b9l]

Все замечательно. Спасибо огромное, но Cohesion произносится не так. Ухо режет...

[@unclebob7037]

почему то старые лекции по этой же теме больше нравятся, хотя там информацию и хуже видно

[@unclebob7037]

нет, в том то и дело что формально подача материала в новых видео как минимум не хуже, но в старых лекциях вы больше учитель, а в новых больше преподаватель. в старых вам интересен процесс обучения учеников(вы в процессе, потоке, возможно это и от студентов зависит), в новых появилось ощущение рутины и усталости некоторой, это влияет на легкость усвоение и просмотра лекций. в старых лекциях вам процесс был в удовольствие в большей степени, рассказали шаблон и смотрите на скрипение в мозгах у студентов, а в новых вы говорите - я понимаю что вам трудно. старые, пока только 2 серии посмотрел, они как сериал на одном дыхании смотрятся как любимый сериал. в любом случае лучше ваших лекций я не видел

[@unclebob7037]

а есть платные лекции по другим темам? в смысле не тренинги а именно standalone записи? где смотреть информацию? на email писать?