Шаблоны проектирования. Фетиш программистов.
Автор: Петр Арсентьев
Шаблоны проектирования. Фетиш программистов.
В конце 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 он сможет без подглядывание в книгу.
Эта ситуация натолкнула меня на мысль начинать давать шаблоны проектирования в курсе с самого начала. Потому что шаблоны проектирования - это по сути ООП. А ООП - это базовое понимание программирования. Шаблоны проектирования – это не высший уровень полета, а наоборот это основы программирования, как алгоритмы.
Подведем итог.
Шаблоны проектирования – это примеры решений, а не панацея. Шаблоны проектирования нужно адаптировать под ваши задачи. Это значит, что их нужно изменять, а не принимать как аксиому.Запоминайте идею, заложенную в шаблон проектирования, а не заучивайте код.
Экспериментируйте с шаблонами, изменяйте их, комбинируйте разные шаблоны вместе.