Шаблоны проектирования. Фетиш программистов.

Автор: Петр Арсентьев

Design pattern

Шаблоны проектирования. Фетиш программистов.

В конце 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 он сможет без подглядывание в книгу.

Эта ситуация натолкнула меня на мысль начинать давать шаблоны проектирования в курсе с самого начала. Потому что шаблоны проектирования - это по сути ООП. А ООП - это базовое понимание программирования. Шаблоны проектирования – это не высший уровень полета, а наоборот это основы программирования, как алгоритмы.

Подведем итог.

Шаблоны проектирования – это примеры решений, а не панацея. Шаблоны проектирования нужно адаптировать под ваши задачи. Это значит, что их нужно изменять, а не принимать как аксиому.

Запоминайте идею, заложенную в шаблон проектирования, а не заучивайте код.

Экспериментируйте с шаблонами, изменяйте их, комбинируйте разные шаблоны вместе.