Шаблоны проектирования. Фетиш программистов.
В конце 2018 года я переделывал модуль Шаблоны проектирования в курсе
Java. C нуля до трудоустройства.
Прочитывания книги по шаблонам проектирования ко мне пришло осознание о том, что шаблоны проектирования противоречивая субстанция. Ниже изложено мое виденье проблемы.
Все программисты знают про шаблоны проектирования. Про них ходят легенды, придумывают мифы. Кто-то обожает их, кто-то ненавидит.
Давайте сначала разберемся, что же такое шаблоны проектирования и зачем они нужны.
При проектировании любой системы программист должен исходить из рационального смысла и решить несколько базовых задач.
- Проект должен просто поддерживаться. Изменения, внесенные в один модуль проекта, не должны влиять на работу других модулей.
- Проект должен просто расширяться. Добавление нового кода не влияет на уже созданный код.
- Проект должен просто масштабироваться.
Здесь на сцене и появляются шаблоны проектирования.
Шаблоны проектирования – это набор решений конкретных задач. Из шаблонов убраны детали предметной области, поэтому их можно применять в любых языках программирования.
Показанные решения в шаблонах: просты, четки и понятны. В этом и прелесть шаблонов. У каждого программиста под рукой есть набор готовых решений практически на любую задачу проектирования.
С другой стороны здесь кроется основная проблема.
Неопытные программисты начинают заучивать код шаблонов и пытаются их использовать везде.
Бездумное применение шаблонов привод к усложнению восприятия кода и запутыванию логики.
Некоторые шаблоны хоть и носят разное название, внутри все же базируется на одной и той же идее.
Другая крайность из-за отсутствия уверенности в своих знаниях начинающие программисты боятся их применять, чтобы не выглядит глупо со стороны более опытных программистов.
У более
опытных программистов с шаблонами проектирования возникает другая история.
Они воспринимают шаблоны проектирования как аксиому.
Такой программист будет четко следовать приведенной в книге UML схеме.
Создаст все интерфейсы и вспомогательные классы, так как указано в книге.
К каждому реализованному шаблону будет добавлен постфикс о том, какой шаблон тут используется. Например: HibernateSingleton, UserAbstFactory.
Код в этом случае становится избыточным, громоздким.
Книга «Банды четырех» была издана в 1994 году. К этому времени большинство языков программирования модернизировалось. В связи с этим часть шаблонов устарела, часть шаблонов уже поддерживается на уровне самого языка.
Поэтому шаблоны проектирования не нужно заучивать. К шаблонам проектирования нужно относиться, как к примерам использования ООП. Смотреть на шаблон проектирования как на композицию объектов, а не как на готовое решение.
При решении любых задач в первую очередь руководствуйтесь принципом Оккама.
Не следует привлекать новые сущности без самой крайней на то необходимости.
Если использованный шаблон в вашем конкретном случае нужно изменить или упростить, смело меняйте и упрощайте код.
Никогда не указываейте в именах классов или в документации, что тут используется тот или иной шаблон.
Пример HibernateSingleton, UserAbstFactory. Постфиксы ничего не говорят о назначении вашего класса.
Они только создают шум при чтении кода.
Так же при проектировании руководствуйтесь принципами SOLID.
Single responsibity, Open-close, Liskov, Interface sugregution, dependency inversition.
Как изучать шаблоны проектирования.
Научится хорошо проектировать и программировать, можно только через практику.
В книгах по шаблонам проектирования приводятся простые и очевидные задачи.
В реальном же проекте львиная доля времени тратится на декомпозицию.
К сожалению переосмысленных книг по шаблонам проектирования еще не написали.
Большинство статей или курсов просто пересказывают книгу «Банды четырех».
Поэтому единственное правильное решение - это смотреть на проекты с открытым исходным кодом и разбирать архитектурные решения.
Начните с вашей любимой библиотеки. Найдите репозиторий проекта.
Постарайтесь понять архитектуру проекта, найдите используемые шаблоны в проекте.
Посмотрите, как их применили. Повторюсь, не заучивайте код, а черпайте идею, о том как взаимодействуют объекты, классы и интерфейсы.
В моем курсе по программированию в части задач нужно использовать шаблон проектирования Singleton.
Модуль про шаблоны проектирования, где рассказывается, как его нужно реализовывать, находился в курсе после этих задач. В курсе была проблема последовательности изложения. Первоначально я полагал, что найти материал по шаблону Singleton не составит труда.
Часть учеников применяла этот шаблон с ошибками.
Потом я понял, в чем кроется причина. В источниках,
где они находили описание данного шаблона, упускалась базовая идея реализации шаблона в языке Java.
Для того, чтобы реализовать шаблон Singleton в Java, нужно понимать, как JVM загружает классы. Если программист понимает, как это происходит, то реализовать код шаблона Singleton он сможет без подглядывание в книгу.
Эта ситуация натолкнула меня на мысль начинать давать шаблоны проектирования в курсе с самого начала.
Потому что шаблоны проектирования - это по сути ООП. А ООП - это базовое понимание программирования.
Шаблоны проектирования – это не высший уровень полета, а наоборот это основы программирования, как алгоритмы.
Подведем итог.
Шаблоны проектирования – это примеры решений, а не панацея.
Шаблоны проектирования нужно адаптировать под ваши задачи. Это значит, что их нужно изменять, а не принимать как аксиому.
Запоминайте идею, заложенную в шаблон проектирования, а не заучивайте код.
Экспериментируйте с шаблонами, изменяйте их, комбинируйте разные шаблоны вместе.