0,0
рейтинг
20 февраля 2013 в 19:01

Разработка → Для чего нужны шаблоны проектирования

Все чаще и чаще я слышу от разработчиков и читаю в статьях, что шаблоны проектирования (они же дизайн-паттерны) никому не нужны. Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное — это код рабочий написать, да побыстрее. На умные толстые книжки ни у кого нет времени, разве что для прохождения собеседования. Тех, кто хочет обсудить данную тему, прошу под кат.



Немного воспоминаний из молодости



Когда я учился в университете, нам преподавали в рамках одного из курсов шаблоны проектирования. На тот момент они казались мне чем-то наподобие сферического коня в вакууме, потому что практического опыта их применения я не имел (это был третий или начало четвертого курса много лет назад). Запомнить кто из них кто тоже было достаточно сложно, не говоря уже о тонкостях и деталях. Тем не менее, вопросы по шаблонам проектирования задавали в обязательном порядке на каждом собеседовании на работу. Кандидатам приходилось раздувать щеки и доказывать как круты разные шаблоны (особенно Singleton), видя их в жизни максимум раз-другой на страницах книжек.

Но ведь совсем не глупые люди придумали шаблоны проектирования:

  • В 70-ые годы архитектор Кристофер Александр начал дело и сформулировал набор шаблонов проектирования.
  • Его дело в IT подхватили в далеком 1987 году небезызвестные Кент Бэк и Вард Каннингем, составив шаблоны проектирования для популярного языка программирования Smalltalk.
  • Еще один легендарный в IT человек Эрих Гамма написал докторскую диссертацию на эту тему в 1988-1990.
  • И наконец, в начале 90-ых известная «банда четырех» в составе все того же Эриха Гаммы, Ричарда Хелма, Ральфа Джонсона и Джона Влиссидсома опубликовала легендарную книгу «Design Patterns: Elements of Reusable Object-Oriented Software».


Дальше продолжать исторические хроники смысла нет. Это была первая книга, из которой наше поколение черпало свои знания по шаблонам проектирования и пыталось применять их в своей работе. Она считается классикой в этой тематике и обязательна к прочтению.

Через некоторое время работы я начал замечать, что даже теоретические знания шаблонов проектирования помогают мне понять чужой код гораздо быстрее. А это особенно важно на старте вашей карьеры, когда вам надо вникать в существующие проекты без опыта работы. Например, встречая класс с суффиксом Builder, я понимал, что его добавили с целью упрощения и изоляции логики построения сложных объектов. Я сразу легко находил как им пользоваться и применять в своем коде. Повсюду были разбросаны представители шаблона Singleton, совершить ошибку при инициализации которых так легко без знаний правил применения. В коде, с которым я работал, обильно встречались Facade, Visitor, Chain of Responsibility, Iterator, Adapter, Decorator, Proxy, Strategy, Template Method и прочие популярные шаблоны проектирования.

Я осознал, как много времени я экономлю, применяя свои скудные книжные знания шаблонов проектирования и даже в душе зауважал их авторов. Мне было легко не только понимать чужой код, но и расширять его своими решениями, а также добавлять новые.

А как без шаблонов?



Время шло… Я достаточно быстро привык к повсеместному применению шаблонов проектирования и мне стало сложно работать без них. Я начал понимать для чего на собеседовании у кандидатов спрашивают о них (конечно, если не просто «для галочки»). Тут речь даже не об обязательном применении шаблонов проектирования, а об упрощении общения между разработчиками. А это тот процесс, который занимает ключевое место в разработке — обсуждение архитектуры и дизайна конкретного решения задачи.

Первый важный параметр — это время, которое тратится на обсуждение и принятие решения (я надеюсь, что у вас решения принимает не один бородатый Senior Senior Global Product Software Architect). Представьте себе как сложно было бы быстро объяснить кому-то, что нужно реализовать Decorator: «нам нужно сделать класс, которому мы передадим в конструкторе экземпляр другой реализации того же интерфейса и который будет добавлять логику к вызову этих методов, не меняя их основного поведения...» А ведь еще за кадром остались куча мелочей и нюансов. И это для мелкой детали вашего дизайна, которых в большинстве решений десятки, а то и сотни. Мы даже не трогаем сложные и серьезные архитектурные шаблоны.

На примере с Decorator легко понять второй важный параметр — одинаковое понимание дизайна решения задачи в головах всех членов команды. При размытости формулировки каждый может понять решение по-разному, а это чревато проблемами. Ведь реализация может сильно отличаться от обсуждаемой задумки. А это приведет к дополнительному времени на ревью кода и переделки.

Третий важный параметр — понимание работы сторонних инструментов и библиотек. На данный момент практически в каждом проекте используется множество сторонних решений. Чтобы их использовать правильно и не наступать на грабли, архитектор и разработчик должны понимать как что устроено. А для этого используются общеизвестные шаблоны, которые призваны сильно упростить понимание и сравнить с альтернативными решениями.

В жизни мы активно используем примеры для описания ситуаций, предметов, поступков. Чтобы объяснить кому-то какую-то концепцию, мы базируемся на общеизвестных знаниях и выстраиваем примеры на их основе. «Такой же здоровый как Вася», «так же тяжело как после 5 км пробежки», «плохо как с бодуна», «кислый как лимон» и т.д. Подобные выражения мы используем в своей речи постоянно и даже не замечаем этого. Для нас их применение проще чем детальное описание и это позволяет вашему собеседнику лучше вас понять.

Следующий уровень



Если вы заметили, что вы не пытаетесь вспомнить детали реализации шаблона проектирования, а просто можете изложить детали его применения своими словами, то вы переросли уровень Shu в известной восточной философии Shuhari (я когда-то давно писал о ее применимости к Agile подходам и практикам). На уровне Shu вы просто следуете шаблонам и не можете осознать их полезность, тонкости и влияние. На уровне Ha вы уже все осознаете и можете сознательно отказываться от определенных шаблонов, критиковать решения на их базе, видоизменять некоторые шаблоны под конкретную ситуацию и контекст.

На уровне Ha я настоятельно рекомендую прочитать отличную книгу «Refactoring to Patterns» от Джошуа Кериевски. В ней рассказывается о том, как находить в коде неподходящие или плохо примененные шаблоны проектирования, а потом посредством рефакторинга приводить их к верным и подходящим решениям. Эту книгу стоит читать именно на уровне Ha, потому что до этого она будет для вас просто пустым звуком.

У как же уровень Ri? На этом уровне вы и вовсе перестаете задумываться о применении шаблонов. Решения рождаются натурально на базе ваших знаний и навыков, которые вы накопили с годами. Где-то вырисовываются одни шаблоны, где-то ваши собственные наработки, которые стали для вас шаблонами в данном контексте. В голове у вас перестает работать цепочка «от шаблона к решению» и остается только «от решения к шаблону». Тогда вместо вопросов о конкретных шаблонах проектирования на собеседовании вы переходите к открытым вопросам о применимости данного инструмента и примерах из реальной жизни…

Заключение



Шаблоны проектирования — это один из инструментов разработчика, который помогает ему сэкономить время и сделать более качественное решение. Как и любой другой инструмент, в одних руках он может принести много пользы, а в других — один только вред. Я попытался донести на примерах, что конкретно дадут вам шаблоны проектирования и как к ним стоит относиться. Надеюсь, мне это удалось…

P.S. На одном из моих тренингов хвалили книгу по шаблонам проектирования для начинающих «Head First Design Patterns». Лично сам не читал, потому как достаточно владел темой из других источников и недоверительно отношусь к такого формата книгам.
Николай Алименков @xpinjection
карма
23,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (44)

  • 0
    «Head First Design Patterns» мне лично не понравилась — много лишних слов, не особо наглядные примеры.
    • 0
      Перестарались они со стилем изложения материала.
      При чтении книги меня постоянно клонило в сон :)
      • +1
        воды многовато, зато они там и по основам CI прошлись
    • +2
      А по мне для старта — то, что надо + сразу дают задания попрактиковаться. Хотя вряд ли этого будет достаточно, поэтому, прочитав Head First, купил еще и классику от банды четырех :)
    • 0
      Ну вот, первым же комментом опустили замечательное введение в предмет для новичков. Просто «Head First Design Patterns» написана совсем не для той аудитории для которой предназначена GOF. Нельзя же с одних и тех же позиций оценивать, к примеру, «Занимательную физику» Перельмана и «Справочник по физике для инженеров и студентов вузов». Каждая из них сияет в своей области.
  • 0
    Спасибо, книгу как-то стороной обошел. Обязательно теперь прочитаю.
  • 0
    «Refactoring to Patterns» от Джошуа Кериевски.

    Как раз эта книга помогла мне лучше понять некоторые сложные паттерны которые остались недопоняты на уровне Shu :).
  • +9
    Фраза «Шаблонное мышление» в свете Вашей статьи приобретает иной смысл прям таки ).
    • 0
      Мыслить шаблонами и шаблонное мышление — не совсем одно и то же.
      Если ты мыслишь шаблонами — ты понимаешь, что есть что-то и помимо шаблонов.
      Если у тебя шаблонное мышление — увы, у тебя нет этого понимания.
  • +1
    Большое спасибо за статью! Вы сформулировали и дополнили мои мысли :)
    Недавно я маленький комментарий на эту же тему писал: habrahabr.ru/post/166113/#comment_5738499
  • –1
    Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное — это код рабочий написать, да побыстрее

    Пытаться вести дискуссию с такими людьми это то же самое что и пытаться объяснить что нехорошо и неправильно чистить семечки на пол в метро, человеку, который это уже делает. Да и вообще страшно представить, что бы произошло с миром программирования, если бы все программисты стермились побыстрее написать код и проповедовали бы это «мне главное решить задачу! Я — решатель задач!» и тому подобное.
    • 0
      Страшный мир уже не за горами, несется к нам на полном ходу! «Решение» задач становится очень даже популярной целью молодых программистов…
      • 0
        Страшный мир всегда вокруг Вас.
        Достаточно лишь правильно посмотреть.
        Относитесь к этому проще: это всегда было, и оно от Вас не зависит.
    • 0
      В чем проблема? Программиста и нанимают чтоб он как можно быстрее решал задачи.
      • +1
        Ну не совсем так. Зачастую самое быстрое решение — воткнуть костыль. Раз костыль, два костыль, а потом продукт нереально развивать и поддерживать. Приходится переписывать с нуля или же терять клиентов за счет того, что развитие идет слишком медленно. Точечная скорость не всегда важнее стабильности скорости.
        • 0
          Безусловно. Цель — решать задачи как можно быстрее. В том числе в будущем.
          Об этом иногда забывают. Тогда получается архитектура ради архитектуры.
      • –1
    • +1
      Решение задачи это необходимое, а не достаточное условие. Программист, который костылями решает задачу, мало кому нужен, но программист, который ее не решает вообще, не нужен никому.
  • 0
    Правильно понимаю, что не существует нормальной, не сканированной, электронной версии «A Pattern Language» Кристофера Александра?
    • +2
      Если вы про пиратскую копию, то вроде нету.
      А если за деньги, то пожалуйста — на сайте www.patternlanguage.com/leveltwo/patterns.htm есть доступ к электронной версии за символические членские взносы в виде 5$/месяц.
      Только, вы уверены что вам именно эту книгу надо? там шаблоны городской застройки, архитектуры, дизайна — тоже очень интересно, но некоторые разочарованно говорят «у-у-у, обманули...»
      • +2
        Я бы и купил с радостью. Мне именно архитектура интересна.

        Если вам известны более подходящие книги — посоветуйте. Я ничего не смыслю в этой науке, но временами останавливаюсь, осматриваю дома, мимо которых хожу ежедневно, и удивляюсь количеству деталей, которых я никогда раньше не замечал.
  • +2
    С людьми, которые сначала не понимают прелесть того или иного шаблона проблем нет. Проблемы начинаются с товарищами, вчера прочитавших про три-четыре новых шаблона и втыкающих их повсеместно и беспорядочно.
    В частности, для C++ крайне опасно всё фабричное, ибо в большинстве случаев полезет в Heap за памятью, что не есть дёшево.
    • 0
      Это и есть та цепочка, которую я называл «от шаблона к решению». Прочитал о шаблонах проектирования -> впечатлился -> надо применять знания на практике -> айда подводить все проблемы под шаблоны -> на выходе шаблонно-костыльный код… Неприятная дорожка!
      • 0
        Она неприятна для человека, который потом с этим кодом работает. Первоначальный костылеписец получил массу фана и скорее всего уже не жаждет поддерживать то страшилище, что получилось на выходе.
    • 0
      А как вы поступали, когда только прочитали про шаблоны?
      • 0
        Я лично стал придумывать, как их можно использовать в моем проекте.
        И удивлялся, как они гармонично сочетаются друг с другом :-)
        Но тогда я еще не знал о принципе KISS.
  • 0
    Согласен с автором. Паттерны проектирования нужны. Без них ни как. Более того, считаю что в настоящее время в большинстве случаев архитектурная проблема является главной в разработке ПО (в сравнении например с оптимизацией или алгоритмической проблемой), т.к. пользователь скорее выберет тормозящее и ограниченное, но корректно и стабильно работающее ПО. Невозможно построить крупную систему без хорошей архитектуры, иначе после определенного критического объема она просто развалится.
    P.S. Все выше сказанное лишь субъективные наблюдения. Являясь сисадмином я не занимаюсь разработкой ПО профессионально. Однако в свободное время создаю ПО для души, уделяя бОльшую часть времени архитектурным вопросам.
    • 0
      В области бухгалтерского софта безусловно, но если говорить про что то серьёзное: системы проектирования, симуляции, компьютерной графики, то я бы так легко «алгоритмическую» проблему не списывал (а так-же математическую или физическую) В этих областях без решения этих задач никакая архитектура не поможет.
      • 0
        Вот в первую очередь в сложных системах и нужна архитектура для придания им гибкости, модульности и тестируемости. Паттерны достаточно четко формулируют где и как их использовать чтобы этого добиться. Но надо помнить, что это не панацея.
        • 0
          Я в своём комментарии нисколько не умалял роль архитектуры, я писал что не стоит так недооценивать роль алгоритмов. Сложный софт это комбинация хороших алгоритмов и хорошей архитектуры и одного компонента недостаточно. Плохие алгоритмы не спасет никакая архитектура.
  • 0
    Плохо когда разработка превращается в pattern-driven программирование — есть у меня знакомые, которые и HelloWorld раздуют в нечто невообразимое, зато все по GOFу
    • 0
      Вы на 100% правы. Именно поэтому стоит давать волю шаблонотворчеству только на уровне Ha. А до этого команда с помощью ревью кода и совместного обсуждения дизайна контролирует страсти по шаблонам у особо ярых их сторонников.
    • 0
      Уметь применить тридцать два паттерна в HelloWorld надо, даже если это не пригодится в реальной практике.
      • 0
        Не согласен. Нет смысла уметь нечто бессмысленное.
        Посмотрите легенду об ученике, который научился ходить по воде :-)
  • +1
    Мой любимый паттерн — это Слабое связывание [ Low Coupling ].

    Его принцип прослеживается во многих паттернах.

    Мне, например, легче применять один основной принцип, чем пытаться оперировать целой кучей шаблонов.
    • 0
      Можно сказать, что все паттерны состоят из 3 компонент — полиморфизм, инкапсуляция, наследование
      Даже вроде бы статья про это была на Хабре
      • 0
        Я бы сказал — не только.
        Есть еще cohesion и coupling.
        Есть принцип единой ответственности.
        Есть процедурный, объектно-ориентированный и функциональный подходы.
        И есть еще много чего, и все это, примененное в гармонии, вызывает в нас чувство прекрасного.
        Паттерны — это не только голые скелеты указанных трех компонент. Они описывают форму, но не содержание.
        Кстати, именно поэтому есть даже пара паттернов, имеющих совершенно одинаковую структуру. Предлагаю Вам найти их самостоятельно, чтобы понять, что Вы упуская, размышляя предложенным Вами способом.

        Не все так просто,
        Как нам кажется порою,
        Не все так сложно,
        Как логический узор,

        Все гармонично,
        Только кинь иначе взор — И глубина тотчас
        Открыта пред тобою,

        Лишь улови… (с)
  • 0
    Отличная мотивирующая статью. Короткая конечно, но это можно и к плюсам отнести.
    Читая, сразу вспомнил книгу «PHP. Объекты, шаблоны и методики программирования» — как мне кажется, Мэтт Зандстра максимально полно передал преимущества использования шаблонов, да и вообще правильные подходы объектного проектирования. Очень советую прочитать, и не только PHP-программистам!
  • –1
    Через четыре года после GoF была опубликована фундаментальная работа "Шаблоны проектирования в динамических языках", в которой показывалось, что в функциональных языках программирования основные «классические» шаблоны проектирования вырождаются в нечто тривиальное — или вообще элиминируются или превращаются в макрос или функцию. В 2002 году Пол Грэхэм написал, что «шаблоны проектирования» — это частный случай промежуточного результата ручной компиляции с функционального языка типа LISP. Ну, поэтому, я эти «шаблоны проектирования» не замечал довольно долго (хотя и, как потом выяснилось, применял вовсю), так как мыслил в категориях функциональных языков «измысливал» сразу оригинал вместо искажённого образа.
    • 0
      Мыслить функциями высших порядков — это особое чувство познания еще одной бесконечной грани мышления :-)
      Когда впервые испытываешь это чувство неизвестных доселе возможностей… :-)
  • +1
    Интересно, что почти любой инструмент разработки — может стать предметом холивара.

    Давайте сначала — что такое шаблоны проектирования? Вообщето частный случай решения некой задачи. Зная который, Вы можете легче решать задачи в будущем, если они совпадают с той самой «некой». Думаете «шаблоны» — это всего лишь придурь разрабов? Нет, любой инженер знает типовые схемы «чего-то там». Даже у шахматистов и футболистов есть типовые шаблоны поведения.

    так что я считаю — крайне вредны обе крайности. И полное незнание паттернов (вы к ним всё равно прийдёте, просто набьете кучу шишек по дороге), и слепое подчинение паттернам — когда архитектурные изыски создаются ради голых архитетктурных изысков. Да, полученное решение может быть далеко не самым худшим, но, возможно, и лучшим оно не будет. Ведь постоянно появляются новые паттерны, а значит «самый лучший код» — ещё не написан.
    • 0
      Такое впечатление, что большинство комментаторов не читали статьи. Прочтите хотя бы выделенные жирным основные моменты.
      Паттерны нужно изучать не для того, чтобы их применять. Ведь большинство из них очень просты и могут быть «изобретены» на ходу.
      Основные плюсы знания паттернов — коммуникация с другими разработчиками и ускоренное изучение чужого кода.
      • 0
        Основные плюсы знания паттернов, да вообще любого знания — больше вариантов решения.
        Методы, принципы, схемы, паттерны, языки, фреймворки — это всего лишь инструменты.

        Я когда делал ремонт, пользовался перфоратором, шуруповертом, молотком, пилой и т.д.
        Без шуруповерта тоже можно было, в принципе, но с ним проще и быстрее.
        Возможно, можно было сделать ремонт одним перфоратором — и сверлить, и заворачивать шурупы, и забивать гвозди — но у меня было несколько инструментов, и я ими пользовался в тех случаях, когда это было уместно.

        При увеличении поля знаний возрастает вероятность придумать что-то новое, проще решить какую-то задачу, т.к. количество комбинаций растет. С опытом приходит понимание, что и как лучше использовать.

        И да, я согласен, если другой человек знает то же, что и вы, разговаривать проще. Можно не говорить «устройство, которое вращает сверло и одновременно долбит им», а сказать «перфоратор».
  • 0
    «Многие шаблоны проектирования в объектно-ориентированном проектировании можно рассматривать как идиоматическое воспроизведение элементов функциональных языков.» Вики (с). Помню как первый раз увидел шаблоны — думаю, вот это чудо расчудесное. Конечно шаблоны нужны, в шарпе, сях, яве и других похожих языках. Хорошо, что мир придумал и более удачные решения (питон ванлав).

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.