Comments
На мой взгляд основная польза от них — простое описание, понятное другим, универсальный язык. Декоратор, фабрика, посетитель, и т.д.
да, слово "паттерн" оно как раз хорошо отражает их суть: это не темплейты, по которым хорошо делать много экземпляров чего-то, а именно паттерны, которые используются для распознавания. Смотришь на код — и видишь не несколько взаимодействующих классов, а фабрику или там обзервер. Ну и соответственно они порождают общую терминологию: вместо того, чтобы кому-то объяснять, как у тебя классы взаимодействуют, ты просто говоришь "у меня здесь фабрика" и всем всё понятно.
Но чего-то большего от них ожидать, по-моему, не надо.
К сожалению когда в программировании возникает какой-то тренд, то все начинают эту трендовую концепцию пихать по делу и без.
Эта участь не обошла и паттерны. Поэтому части паттерны применяются не для решения конкретных задач и\или проблем, а просто для самовыражения программиста. Это видно даже по статьям на Хабре.
Я думаю к каждому применению паттрена надо задавать вопрос (возможно себе) "какую проблему он решает?", без внятного ответа паттерн скорее всего не нужен.
Кстати о правильном применении паттренов есть книга Дж.Криевски "Refactoring to Patterns". Без нее изучение GoF может нанести вред.
Паттерны документировались на основе имеющейся кодовой базы. На тот момент наиболее популярны были комплексные программные решения с годами разработки и поддержки, оставаясь в рамках выбранного функционала. Процессы разработки таких систем требовали и требуют как квалификации разработчиков, так и эффективности общения. И эти задачи паттерны прекрасно продолжают выполнять и поныне.
НО! Современная разработка это по большей части собрать в красивый веб-интерфейс 100500 пакетов и библиотек, набрать аудиторию, продать компанию большому игроку на рынке и уйти в закат на Мальдивы.
В контексте таких продуктов ни знание, ни использование паттернов и прочих практик не имеет смысла для бизнеса.
Искать применение и целесообразность паттернам надо в фундаментальных местах, а не в CRUD бэкэнде. Банально, Command ранее реализовался паттерном из книги, и работал локально, и позволял добавлять новые команды в продукты масштаба MS Office. В Веб-ориентированных продуктах - давайте просто в базу положим запись и все. А если надо откатить действие, положим новую запись отката и фронтенд просто отобразит последнее состояние из базы. Так быстрее и дешевле на короткой дистанции.
GoF в своей книге говорили, что они взяли паттерны из архитектуры, соответственно это искусство. С точки зрения сопровождения кода, язык паттернов это утопия. Чтобы код было удобно сопровождать у него должно быть описание не хуже, чем GoF описывают свои паттерны в книге. Для понимания необходимо расставить ценностные маркеры, то есть при написании кода во главе угла вот эта идея и поэтому вот эти решения. Иначе друг друга понять очень тяжело. В книге Влиссидеса о дополнительных штрихах к паттернам глава про обсуждение паттерна multicast просто шедевр описания спора программистов.
Есть ли польза от GoF-паттернов?
Да, есть.
Оказалось, что положительно влияя на одни характеристики, паттерны оказывают негативное влияние на другие составляющие качества кода.
"Оказалось"... Чтобы сделать такой вывод, исследование не нужно. Топор тоже гораздо проще бензопилы в устройстве и обслуживании. А полуторка АМО проще, чем современный дизельный тягач. А отвар из ивовой коры проще, чем синтез и производство аспирина.
Давайте что ли напишем статью "есть ли польза от бензопил на лесоповале"? Не, таких статей мы почему-то не пишем. Всем как-то интуитивно понятно, что чем больше плюшек приносит технология, тем она замороченнее. Тем более парадоксально, что когда программистам предлагают писать более замороченный, но более надежный код (кстати, писать по готовым рецептам), то сразу поднимается дискуссия "а надо ли", "а не слишком ли сложно", "мой брат писал по паттернам и заболел".
По мне только запутывает технарей. Начиная с самого названия, которое ничего не обещает
"бандa четырёх". И кончая отсутвием деталей, например бинарного интерфейса, который например предусмотрен в более проработанной модели COM.
GoF в свое время предложили классную идею - документировать типовые решения типовых проблем в дизайне ПО. В качестве иллюстраций они взяли примеры из своего опыта разработки текстового редактора.
Но сообщество по большей части пропустило суть мимо ушей, а иллюстрации восприняло как догмы, бросившись как очумелые внедрять где надо и где не надо, спрашивать на собеседованиях и преподавать в ВУЗах. У итоге хорошая идея превратилась в фарс.
К счастью, у GoF появились последователи, применившие подход к своим доменам в книжках: enterprise integration patterns, reactive design patterns, service design patterns, и т.п. - подальше от программирования и ближе к design или архитектуре, где они и должны быть.
В программировании же их место постепенно отгрызает математика (FP, Category theory, ADT и т.п.), дающая более строгии и надёжные гарантии в плане композиции и валидации решений.
спрашивать на собеседованиях и преподавать в ВУЗах
Мне так никто и не может объяснить, что в этом плохого.
Допустим, есть задача, когда один источник отправляет данные нескольким получателям. Число получателей растет и иногда даже в рантайме. Стандартное ее решение это паттерн паб-саб. Костыльно-велосипедное решение это при появлении новых получателей снова и снова дописывать строки кода в какой-то бесконечный метод, который по очереди вызывает получателей. Вопрос: что криминального, если я хочу на собесе услышать суть данного паттерна и его применение в реальных условиях?
А если вместо pub\sub скажет что это Observer? Или скажет что надо использовать список коллбеков или events?
Вопрос: что криминального, если я хочу на собесе услышать суть данного паттерна и его применение в реальных условиях?
GoF оставили за скобками как минимум две важные темы: нефункциональные требования и композицию паттернов между собой.
NFR принципиально влияют на способ реализации. В зависимости от требований к надёжности, гарантиям доставки, задержкам, throughput, и т.п. ваш pub-sub может быть, как вы заметили и шматок лапшекода внутри одного метода, и DSL с кодогенератором, и ООП с классами как у GoF, и брокер сообщений на кафках в нескольких датацентрах по всему миру. Т.е. без дополнительных вводных делать можно как угодно. И какой тогда правильный ответ?
Что касается композиции, то те же https://typelevel.org/cats/typeclasses.html дают кусочки решения и конкретные правила что, с чем и как соединять, имея в бэкграунде вполне конкретную математику (у вас нет скалы, перепишите на джаваскрипте, будет плюс-минус то же самое), с возможностью статически проверить решение. GoF в этом смысле как художественная литература, дающая лирические советы как делать правильно, но без каких-либо намеков почему именно так правильно и как это на практике проверять.
Pattern не является Best practice и абстрактные формулировки только усложняют понимание. Например, Вы пишете подсистему логгирования и основное требование , чтобы она минимально влияла на исполняемый код, но при этом отражала последовательность событий во времени при праллельной обработке
Какой паттерн вам нужно применить? Facade? Если читать литературу как минимум несколько подойдут. При этом Pattern не содержит знаний о BestPractice реализации такого решения. Вот найти бы хороший источник где собираются BestPractice по архитектуре это было бы ценно. Чтобы не наступать на одни и теже грабли
Есть ли польза от GoF-паттернов?