Є ідея гри чи геймінг-сервісу? Реєструйся на онлайн-хакатон 7.08! Призовий фонд — $3000
×Закрыть

Нужны советы по GOF паттернам

Привет коллеги по тачпаду и клавиатуре!
У меня к вам чисто техническое обращение.
Сейчас прорабатываю курс по шаблонам дизайна. Да, те самые которые GOF, которых 23 штуки и все что с ними связанно.

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

Мне очень сильно нужна ваша помощь.
Подскажите что следует в него добавить/изменить/убрать.
Как в теории так и в практике курса.

Интересует как мнение Junior разработчиков, с точки зрения базового понимания вещей. Так и уровня Senior/Architect, повидавшие все круги адского кода :), с точки зрения мега опыта колбасни с большим кол-вом разных проектов.

Сейчас имеею следующее.
Теория:
— Сами 23 шаблона в детальном разборе.
— Все оснащено не только абстарктыи UML примерами, но и на базе предметной области, с привязанными к контексту именами.
— Пример шаблона из JDK
— Недостатки каждого шаблона
— Немного про OOD и GRASP
— Немного примеров оснащены кодом решения задачи без использования шаблона и уже с шаблоном. Что бы наглядно увидеть преимущество использования паттерна. Нужно ли это делать для каждого шаблона?

Практика:
— решение контретной задачи с помощью шаблона. По 40-60 мин на задачу. На языке Java.
— Большая часть заданий включает в себя комбинирования шаблонов на базе одного мини проекта. Т.е. сначала решаем одну задачу в проекте одним шаблоном, потом другую, уже другим шаблоном. Таким образом проекта обрастаем 3-4 шаблонами.
И так далее, для другой группы шаблонов.

Может кто то встречал уже какие то удачные примеры комбинирования шаблонов?
А как насчет неудачного применения шаблона?
Может добавить не GOF шаблон, но кторый очень популярен?

Вообще очень хочу услышать все ваши мысли по этому поводу. Заранее всем благодарен.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Думаю, що було б корисно навести приклад вдалого використання та невдалого використання. Тут круто б не абстрактні приклади, а з чогось реального, з того ж jdk, якщо є можливість.

Джуны — сейчас под этим понимается человек, который читал и думает что понял.
А шаблоны это для «от одного года практики». Чтобы человек понимал что он писал вот так, а можно проще. А главное такой код будут понимать другие, знакомые с шаблонами.

В самом простом случае можно взять книгу Head First Design Patterns и прорешать её с группой.

Увидел что вы еще S.O.L.I.D. добавили. Вообще не представляю как вы это объясните, людям которые читали, но «еще не попробовали»)

Выложите 1 проработанный шаблон с заданием из вашего трейнинга. Тогда объективно можно будет оценить что вы хотите донести и в каком виде.

Я пока что не волшебник(программист), только учусь. А можно получить материалы курса? Хоть в сыром виде. Хоть не все.
За мной будет должок (когда стану программистом :))
Заранее благодарен!
P.S. mra8@mail.ru, orlylankin@gmail.com.

Евгений, на днях будет анонс на сайте becomejavasenior.com — сможете даже записаться на сам тренинг ;)

очень люблю эту книгу, одна из лучших по шаблонам. Можно сказать разработчиком для разработчиков.

Если для джуниоров, то, на мой взгляд, был бы хорош такой подход.
1. Поставить задачу.
2. Показать, как она решается «в лоб».
3. Показать, к каким проблемам это приводит. Основных вижу две: это постоянная модификация существующего кода и затруднённое его тестирование. В результате, тесты не пишутся вообще, работает ли новый функционал и не поломался ли старый — неизвестно.
4. Применить шаблон проектирование. Показать, что проблемы из предыдущего пункта решились.
5. Как вишенку на торте, рассказать, какие появились новые :-)

Видел статьи, в которых пункты 2 и 3, для краткости, выбрасывались. Дескать, делать надо так, а почему — должно быть очевидно. А для джуниоров это не очевидно.

На ютюбе когда-то видел хороший ролик, который заодно ТДД демонстрировал. Автор показывал пример калькулятора с арифметическими действиями. Сначала написал тесты, потом реализовал операции через if-ы, потом перешёл к фабрике.

Я б ще додав SOLID, або хоча б якісь з цих букв.

Есть SOLID

sourcemaking.com/design_patterns и еще была книженция с кучей рисунков, Head first которая

О, спасибо. А

Head first
была проработана плотно, хорошая книга.

Ещё может быть полезным раскрыть паттерны с точки зрения фп
www.ibm.com/...rworks/ru/library/j-ft10
www.ibm.com/...rworks/ru/library/j-ft11
www.ibm.com/...rworks/ru/library/j-ft12

Да, отсюда в основном и брал примеры.

Один сниппет кода лучше тысячи слов...
И на всякий случай пример конкретной задачи и проблем, которые решает паттерн.

С примерами согласен полностью. Сниппет как может в этом слуге выглядеть?

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

Понял, есть такие примеры. Значит правильно мыслю.

Не нужно упираться в абсолютное знание всех паттернов, главное практическая применимость.
Abstract Factory/Factory Method, Builder, Facade, Strategy, Template method, Observer маст хэв остальное так себе.
Если вы не можете придумать внятный пример из реальной жизни на какой-то паттерн, то скорее всего он не нужен.

я бы больше заморочился принципами написания хорошего кода. тот же SOLID

добавьте что-нибудь про наборы принципов SOLID и STUPID :-)
williamdurand.fr/...rom-stupid-to-solid-code

STUPID — бэкроним, набор антипаттернов, характеризующих код как г...но :
Singleton
Tight Coupling
Untestability
Premature Optimization
Indescriptive Naming
Duplication

SOLID — тоже будет, забыл его упомянуть в теме. Это вообще фундамент всех шаблонов :)

STUPID
 — это что то новое, спасибо, покапаю.

GOF устарел на десяток (если не меньше) лет. От них больше вреда, чем пользы.

ряд паттернов GoF это проверенная временем классика

А ряд других — костыли для обхода корявостей той же Джавы. И ещё ряд конкретно так был улучшен в последнее время (например, observer => react).

Вред не от них. Вред от людей, которые это возвели в ранг религии и молятся (с риском разбить лоб).

Про вред тоже буду рассказывать. Шаблон это не панацея, и на принятие решения применять его тут или нет, разработчик должен тратить даже больше времени чем на придумывание имени классам и методам :)
Шаблон это тупо решение проблемы. Как может быть вред от решения проблемы?
Только если применить не к той проблеме ;)

Вред лечится посто: если без паттерна обойтись можно не нарушая SOLID, то он не нужен.

Так и есть. Весь прикол что бы это увидеть :)

На чем основано данное мнение. Первоисточник плиз.

Я бы добавил еще и антипаттерны (хотя бы классические из habrahabr.ru/post/59005 ) с примерами того, к каким проблемам они могут привести.
Ну и ИМХО для некоторых паттернов стОит показывать к чему может привести бездумное их применение (такое как приколачивание жидкими гвоздями Стратегии там, где было бы достаточно обычного if / else ). Ну и SOLID добавил бы в начало курса — чтобы было понятнее зачем это всё вообще нужно.

Муки выбора между стратегией и if/else проходят с опытом. А это дело исключительно наживное, тут никакие видеоуроки не помогут.

Да, «Стратегия» это популярный подход. Подумаю что него больше времени уделить.
PS это будет живой тренинг, никакой видеоурок тут толком не разъяснит всех деталей. ИМХО.

java-design-patterns.com вот тут даже по сложности сгруппированы.

Супер, то что искал. Кроме GOF еще другие популярные описаны.

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

Принял. В целом согласен, поэтому буду рекомендовать этот курс прежде всего мидлам. Они лучше всего поймут боль и ее решение с помощью шаблона.

Подписаться на комментарии