В жизни программиста, подобно рождению, взрослению и смерти просветлению, есть этапы, когда он сначала пишет "Hello World", затем пишет просто говнокод, потом переходит к красивому структурированному ООП или совсем красивому функциональному программированию, и наконец вдали появляется эта неприступная вершина – шаблоны (или, кому нравятся заимствования, паттерны) проектирования.
Попытки взять эту вершину для многих не имеют успеха по одной причине – не понятно абсолютно ничего. Мне довелось почитать вот эту книгу, и она толковая, мне понравилось. Но в большинстве случаев, если вы обратитесь к Википедии или другим образовательным ресурсам, то найдёте там нечто невразумительное. Вам сразу начнут впаривать что-то про абстрактные классы, про фабрики уток и собак, но мозг будет кричать – отпустите меня, зачем всё это? Ответ именно на этот вопрос вы вряд ли получите.
Пришло время разобраться во всём по порядку. Эта часть – вступление, поэтому рассмотрим только общие вопросы.
Что такое шаблоны (паттерны) проектирования?
Это, буквально, шаблоны (то есть готовые рецепты), как решить ту или иную задачу. Причём необязательно даже в программировании. Речь идёт о проектировании, а проектировать, очевидно, можно что угодно.
В программировании есть много типовых проблем, которые возникают в сложных проектах. Из всего того разнообразия софта, который пишется, через боль, ошибки и слёзы выкристаллизовываются некие шаблоны, как наиболее оптимальные способы решить определённую проблему. Эти шаблоны фиксируются, документируются, им даются названия, и они попадает в доступную всем сокровищницу шаблонов. Шаблон – это не код, не программа, это описание решения проблемы.
Какие задачи решают шаблоны?
Здесь не идёт речь о том, как оптимально написать сортировку массива. или как обойти дерево. Речь именно о проектировании системы, в которой есть взаимосвязанные компоненты, и как сделать так, чтобы эта система не рушилась от каждого изменения, легко дорабатывалась и расширялась .
Возьмём пример. Вы начали делать веб-сайт. Вы открываете редактор и пишете код: так, здесь я напишу запрос к базе данных, здесь я выведу данные на страницу, и т.д.
Но вы можете не сразу начать писать код, а сначала задать себе вопросы:
- А что, если вместо mySQL будет Oracle?
- А что, если база будет вообще не SQL?
- А что, если страницы надо будет загружать через Ajax?
- А что, если структура данных в базе поменяется?
- А что, если изменится процесс авторизации пользователя?
Всё это – вызовы, которые бросает реальный мир вашему коду. И ответить на эти вызовы вы можете или заранее, или уже по факту.
Например, вы можете ответить так: НЕТ. Ничего не будет. База не изменится, данные не изменятся, никто ничего не попросит, а если и попросит, то я не буду ничего делать. В этом случае вы счастливый человек.
Если ваш код уже написан и возникает надобность что-то изменить, вы его дорабатываете, переписываете, вставляете костыли и пр. Когда надобность что-то изменить возникла ещё раз, и вам пришлось переписать ещё больше кода и вставить ещё больше костылей, чтобы исправить те костыли, которые были вставлены раньше – значит, проект спроектирован неправильно и дальше будет только хуже.
В какой-то момент вы наконец выработаете такое решение, чтобы с добавлением новых требований вам не приходилось уже делать большие изменения в проекте. Вот в этот момент вы и создали шаблон проектирования.
Да, программист может создавать шаблоны проектирования и пользоваться ими, ничего не зная о концепции шаблонов проектирования.
Но это произойдёт через боль. Наличие уже готового набора шаблонов проектирования позволяет сократить и упростить собственно проектирование. Нужно просто сказать – чтобы разобраться с этой проблемой, я использую такой шаблон...
Почему тогда их так сложно понять?
Часто бывает, что описание шаблона формально понятно, но непонятен его смысл. Дело в том, что для понимания шаблона нужно понимание проблемы, которую он решает. А с этой проблемой вы могли никогда в жизни не столкнуться. Вы просто не знаете о ней. Если вам объяснить решение того, о чём вы не знаете, то оно вам ничего не даст. Вы просто пожмёте плечами и сразу забудете о нём.
Как я писал выше, шаблоны не решают локальные задачи вроде сортировки массива. Они решают проблемы взаимодействия компонентов сложных систем. Если вы пишете относительно небольшую программу, в ней вообще в принципе никогда не возникнут те проблемы, которые решаются шаблонами. Будет банально проще переписать половину кода, чем заморачиваться. То есть в этом случае можете смело забивать на шаблоны.
Я выучил 100 шаблонов, а что дальше?
А ничего. Знание шаблонов наизусть не даёт никаких гарантий, что проект будет спроектирован хорошо. Возможно даже наоборот – получится только хуже. С помощью шаблонов можно что-то спроектировать, но ведь проектирование можно сделать и плохо, и хорошо. Плохо спроектированный проект с использованием шаблонов остаётся плохо спроектированным. И шаблоны в этом не виноваты – они всего лишь инструмент. Так что знание шаблонов не освобождает от необходимости думать.
Что ж, вступление закончено, а в следующих выпусках начнём рассматривать самые простые шаблоны, которые пригодятся даже в небольших задачах и не потребуют особых усилий.
Читайте дальше:
