Что такое шаблон проектирования
Для чего нужны шаблоны проектирования
Все чаще и чаще я слышу от разработчиков и читаю в статьях, что шаблоны проектирования (они же дизайн-паттерны) никому не нужны. Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное — это код рабочий написать, да побыстрее. На умные толстые книжки ни у кого нет времени, разве что для прохождения собеседования. Тех, кто хочет обсудить данную тему, прошу под кат.
Немного воспоминаний из молодости
Когда я учился в университете, нам преподавали в рамках одного из курсов шаблоны проектирования. На тот момент они казались мне чем-то наподобие сферического коня в вакууме, потому что практического опыта их применения я не имел (это был третий или начало четвертого курса много лет назад). Запомнить кто из них кто тоже было достаточно сложно, не говоря уже о тонкостях и деталях. Тем не менее, вопросы по шаблонам проектирования задавали в обязательном порядке на каждом собеседовании на работу. Кандидатам приходилось раздувать щеки и доказывать как круты разные шаблоны (особенно Singleton), видя их в жизни максимум раз-другой на страницах книжек.
Но ведь совсем не глупые люди придумали шаблоны проектирования:
Дальше продолжать исторические хроники смысла нет. Это была первая книга, из которой наше поколение черпало свои знания по шаблонам проектирования и пыталось применять их в своей работе. Она считается классикой в этой тематике и обязательна к прочтению.
Через некоторое время работы я начал замечать, что даже теоретические знания шаблонов проектирования помогают мне понять чужой код гораздо быстрее. А это особенно важно на старте вашей карьеры, когда вам надо вникать в существующие проекты без опыта работы. Например, встречая класс с суффиксом 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? На этом уровне вы и вовсе перестаете задумываться о применении шаблонов. Решения рождаются натурально на базе ваших знаний и навыков, которые вы накопили с годами. Где-то вырисовываются одни шаблоны, где-то ваши собственные наработки, которые стали для вас шаблонами в данном контексте. В голове у вас перестает работать цепочка «от шаблона к решению» и остается только «от решения к шаблону». Тогда вместо вопросов о конкретных шаблонах проектирования на собеседовании вы переходите к открытым вопросам о применимости данного инструмента и примерах из реальной жизни…
Заключение
Шаблоны проектирования — это один из инструментов разработчика, который помогает ему сэкономить время и сделать более качественное решение. Как и любой другой инструмент, в одних руках он может принести много пользы, а в других — один только вред. Я попытался донести на примерах, что конкретно дадут вам шаблоны проектирования и как к ним стоит относиться. Надеюсь, мне это удалось…
Паттерны проектирования для новичков
Авторизуйтесь
Паттерны проектирования для новичков
Внимание! Материал был обновлён и разделён на три части. Предлагаем вам ознакомиться с ним по следующим ссылкам:
Если вы когда-либо интересовались, что представляют собой шаблоны проектирования, то добро пожаловать. В этой статье я расскажу, что это такое, зачем они нужны, как их использовать, и приведу примеры наиболее распространенных шаблонов на PHP.
Что такое шаблоны проектирования
Шаблоны проектирования — это проверенные и готовые к использованию решения часто возникающих в повседневном программировании задач. Это не класс и не библиотека, которую можно подключить к проекту, это нечто большее. Шаблон проектирования, подходящий под задачу, реализуется в каждом конкретном случае. Кроме того, он не зависит от языка программирования. Хороший шаблон легко реализуется в большинстве, если не во всех языках, в зависимости от выразительных средств языка. Следует, однако, помнить, что такой шаблон, будучи примененным неправильно или к неподходящей задаче, может принести немало проблем. Тем не менее, правильно примененный шаблон поможет решить задачу легко и просто.
Существует три типа шаблонов:
Структурные шаблоны определяют отношения между классами и объектами, позволяя им работать совместно.
Порождающие шаблоны предоставляют механизмы инициализации, позволяя создавать объекты удобным способом.
Поведенческие шаблоны используются для того, чтобы упростить взаимодействие между сущностями.
Зачем нужны шаблоны проектирования
Шаблон проектирования, по своей сути, это продуманное решение той или иной задачи. Если вы столкнулись с известной задачей, почему бы не использовать готовое решение, проверенное опытом?
Пример
Давайте представим, что вам необходимо объединить два класса, которые выполняют различные операции в зависимости от ситуации. Эти классы интенсивно используются существующей системой, что не позволяет удалить один из них и добавить его функциональность во второй. Кроме того, изменение кода потребует его тщательного тестирования, поскольку такой рефакторинг ведет к неизбежным ошибкам. Вместо этого вы можете реализовать шаблоны «Стратегия» и «Адаптер» и с их помощью решить задачу.
Просто, не правда ли? Давайте посмотрим поближе на шаблон «Стратегия».
Паттерн проектирования «Стратегия»
Стратегия — поведенческий шаблон, который позволяет выбрать поведение программы в процессе выполнения в зависимости от контекста путем инкапсуляции нескольких алгоритмов в разных классах.
Где это можно использовать
Представьте, что вы разрабатываете класс, который может создать или обновить запись в базе данных. В обоих случаях входные параметры будут одни и те же (имя, адрес, номер телефона и т. п.), но, в зависимости от ситуации, он будет должен использовать различные функции для обновления и создания записи. Можно каждый раз переписывать условие if/else, а можно создать один метод, который будет принимать контекст:
Обычно шаблон «Стратегия» подразумевает инкапсуляцию алгоритмов в классы, но в данном случае это излишне. Помните, что вы не обязаны следовать шаблону слово в слово. Любые варианты допустимы, если они решают задачу и соответствуют концепции.
Шаблон «Адаптер»
Адаптер — структурный шаблон, который позволяет использовать класс, реализующий нужные функции, но имеющий неподходящий интерфейс.
Также он позволяет изменить некоторые входные данные для совместимости с интерфейсом внутреннего класса.
Как его использовать?
Другое название адаптера — «Обертка». Он «оборачивает» новый интерфейс вокруг класса для его использования. Классический пример: вам надо создать класс предметной модели, имея классы объектов в базе данных. Вместо того, чтобы обращаться к табличным классам напрямую и вызывать их методы по одному, вы можете инкапсулировать вызовы этих методов в одном методе в адаптере. Это не только позволит повторно использовать набор операций, но и избавит вас от постоянного переписывания большого количества кода, если вам потребуется выполнить тот же набор действий в другом месте.
Сравните два примера.
Без адаптера:
Если нам придется использовать такой код повторно, мы будем вынуждены переписывать все это заново.
С использованием адаптера:
Мы можем создать класс-обертку Account :
Теперь мы можем использовать класс Account каждый раз и, кроме того, мы можем добавить в него дополнительные функции.
Шаблон «Метод-фабрика»
Фабрика — порождающий шаблон, который представляет собой класс с методом для создания различных объектов.
Основная цель этого шаблона — инкапсулировать процедуру создания различных классов в одной функции, которая в зависимости от переданного ей контекста возвращает необходимый объект.
Как его использовать?
Сначала создадим три класса:
Теперь мы можем написать нашу фабрику:
На выходе должен получиться HTML со всеми типами кнопок. Таким образом мы получили возможность указать, кнопку какого типа мы хотим получить, и использовать код повторно.
Шаблон «Декоратор»
Декоратор — это структурный шаблон, который позволяет добавить новое поведение объекту в процессе выполнения программы в зависимости от ситуации.
Цель — в расширении поведения конкретного объекта без необходимости изменять поведение базового класса. Это позволит использовать несколько декораторов одновременно. Этот шаблон — альтернатива наследованию. В отличие от наследования, декоратор добавляет поведение в процессе выполнения программы.
Для реализации декоратора нам понадобится:
Как его использовать?
Предположим, что у нас есть объект, который должен иметь определенное поведение в определенной ситуации. Например, у нас есть HTML-ссылка для выхода из аккаунта, которая должна по-разному показываться в зависимости от того, на какой странице мы находимся. Это тот самый случай, когда нам помогут декораторы.
Сначала определимся, какие «декорации» нам нужны:
Теперь мы можем написать сами декораторы:
Теперь мы можем использовать их так:
Обратите внимание, как можно использовать несколько декораторов на одном объекте. Все они используют функцию __call для вызова оригинального метода. Если мы войдем в аккаунт и перейдем на заглавную страницу, результат будет такой:
Шаблон «Одиночка»
Одиночка — порождающий шаблон, который позволяет убедиться, что в процессе выполнения программы создается только один экземпляр класса с глобальным доступом.
Его можно использовать как точку «координации» для других объектов, поскольку поля «Одиночки» будут одинаковы для всех, кто его вызывает.
Как его использовать?
Теперь мы можем получить доступ к сессии из различных участков кода, даже из других классов. Метод getInstance всегда будет возвращать одну и ту же сессию.
Заключение
В этой статье мы рассмотрели только наиболее часто встречающиеся шаблоны из множества. Если вы хотите узнать больше о шаблонах проектирования, вы найдете достаточно информации на Википедии. Для более полной информации обратите внимание на знаменитую книгу «Приемы объектно-ориентированного проектирования» «Банды четырех».
И последнее: при использовании того или иного шаблона убедитесь, что вы решаете задачу правильным способом. Как уже упоминалось, при неправильном использовании шаблоны проектирования могут доставить больше проблем, чем решить. Но при правильном — их пользу нельзя переоценить.
Что такое шаблоны проектирования?
Вы когда-либо задавались вопросом, что такое шаблоны проектирования? В этой статье будет разъяснено, почему шаблоны проектирования имеют существенное значение, и будет приведено несколько примеров на PHP, поясняющих, когда и где их следует использовать.
Шаблоны проектирования — это допускающие многократное использование оптимизированные решения проблем программирования, с которыми мы сталкиваемся каждый день. Шаблон проектирования — это не класс или библиотека, которые мы можем просто вставить в нашу систему. Он — много больше. Это — некоторый шаблон, который должен быть реализован в надлежащей ситуации. Он не зависит от языка. Хороший шаблон проектирования должен быть таким, чтобы его можно было использовать с большинством языков (если не со всеми) в зависимости от характеристик языка. Чрезвычайно важно то, что любой шаблон проектирования необходимо использовать очень осторожно — если он применён в ненадлежащем месте, то его действие может быть разрушительным и породить много проблем для вас. Однако применённый в нужном месте в нужное время он может стать вашим спасителем.
Есть три основных типа шаблонов проектирования:
• структурный
• порождающий
• поведенческий
Структурные шаблоны, в общем случае, имеют дело с отношениями между объектами, облегчая их совместную работу.
Порождающие шаблоны обеспечивают механизмы инстанцирования, облегчая создание объектов способом, который наиболее соответствует ситуации.
Поведенческие шаблоны используются в коммуникации между объектами, делая её более лёгкой и гибкой.
Почему их следует использовать?
Шаблоны проектирования в принципе являются хорошо продуманными решениями проблем программирования. Многие программисты уже сталкивались ранее с этими проблемами и использовали для преодоления эти «решения». Встречая какую-то проблему, зачем заново искать решение, когда можно применить уже проверенное?
Пример
Давайте представим, что вам поручено создать способ объединить два класса, которые выполняют два разных действия в зависимости от ситуации. Эти два класса интенсивно используются существующей системой в разных местах, что затрудняет их удаление и изменение существующего кода. Дополнительно к этому изменение существующего кода требует проверки всего изменённого кода, т.к. правка такого рода в системе, построенной на разных компонентах, почти всегда вносит новые ошибки. Вместо перечисленного можно использовать вариант шаблона «Стратегия» и шаблона «Адаптер», которые могут легко обращаться с названными типами сценариев.
Довольно просто, не так ли? Теперь посмотрим внимательнее на шаблон «Стратегия».
Шаблон «Стратегия»
Изображение размещено с разрешения владельцев сайта cioinnervoice.wordpress.com
Шаблон «Стратегия» является поведенческим шаблоном проектирования, который позволяет вам решать, какой план действий должна принять программа, основываясь на определённом контексте при выполнении. Вы закладываете два различных алгоритма внутри двух классов и решаете в ходе выполнения, с какой стратегией следует работать.
В нашем примере выше стратегия устанавливается в зависимости от того, какой была переменная $context в то время, когда класс подвергался обработке. Если вы даёте ей контекст для класса_один, то будет использован класс_один и наоборот.
Замечательно, но где я могу использовать это?
Предположим, что вы в данный момент разрабатываете класс, который может или обновить или создать новую пользовательскую запись. Хотя ему требуются те же самые входы (имя, адрес, номер мобильного телефона и т.п.), но в зависимости от ситуации он должен использовать различные функции при обновлении и создании. Здесь для выполнения можно, вероятно, сразу же использовать условный переход «if-else», но как быть, если этот класс понадобится и в другом месте? Тогда нужно будет переписать полностью весь этот оператор условного перехода. Не было бы проще просто указать ваш контекст?
Теперь «обычный» шаблон «Стратегия» предполагает помещение ваших алгоритмов внутри другого класса, но в данном случае другой класс был бы нерациональным решением. Помните, что вы не обязаны точно следовать шаблону. Варианты работают, пока концепция остаётся прежней, и это решает проблему.
Шаблон «Адаптер»
Изображение размещено с разрешения владельцев сайта www.uxcell.com
Шаблон «Адаптер» является структурным шаблоном проектирования, который позволяет перепрофилировать класс с другим интерфейсом, делая его доступным для системы, которая использует различные методы вызова.
Это также позволяет изменять некоторые из входов, получаемых от класса клиента, превращая его в нечто совместимое с функциями класса Adaptee.
Как можно использовать это?
Другим понятием для ссылки на класс адаптера является «обёртка», которая по существу позволяет «обернуть» действия в класс и повторно использовать эти действия в надлежащих ситуациях. Классическим примером может быть создание доменного класса для классов таблиц. Вместо вызова различных классов таблиц и последовательного вызова их функций можно вложить все эти методы в один, используя класс адаптера. Это не только позволяет вам повторно использовать любые требуемые действия, но также избавляет от необходимости переписывать код, если вам нужно использовать то же действие в другом месте.
Сравните эти две реализации:
Подход без адаптера
Если бы нам нужно было сделать это снова в другом месте или даже использовать этот код в другом проекте, то мы должны были бы набрать всё заново.
Лучше
Указанное противоположно действиям вроде приведённых ниже:
В данной ситуации мы имеем обёрточный класс, который был бы нашим доменным классом Account:
Таким образом, можно использовать домен Account снова везде, где требуется, — дополнительно вы оказываетесь в состоянии обёртывать другие классы также под вашим доменным классом.
Шаблон «Фабричный метод»
Изображение размещено с разрешения владельцев сайта www.lankanewspappers.com
Шаблон «Фабричный метод» является порождающим шаблоном проектирования, который делает именно то, что означает это слово: этот класс действует как фабрика экземпляров объектов.
Основной целью этого шаблона является вложение порождающей процедуры, которая может свести различные классы в одну функцию. Если фабричному методу обеспечить надлежащий контекст, то он будет в состоянии вернуть правильный объект.
Когда можно использовать это?
Наилучшей ситуацией для использования шаблона «Фабричный метод» является наличие нескольких различных вариантов одного объекта. Допустим, имеется класс «кнопка»; у этого класса есть различные варианты — например, ImageButton (кнопка изображения), InputButton (кнопка ввода) и FlashButton (флэш-кнопка). В зависимости от места может потребоваться создать различные кнопки — именно здесь можно использовать «фабрику» для создания кнопок для вас!
Начнём с создания наших трёх классов:
Теперь можно создать наш фабричный класс:
Полученный код можно использовать, например, так:
Выходом должен быть HTML всех ваших типов кнопок. Таким образом, вы могли бы указать, какую кнопку создать в зависимости от ситуации, а также повторно использовать условие.
Шаблон «Декоратор»
Изображение размещено с разрешения владельцев сайта www.decoratorsdarlington.co.uk
Шаблон «Декоратор» является структурным шаблоном проектирования, который позволяет нам добавлять новое или дополнительное поведение к объекту в ходе выполнения в зависимости от ситуации.
Целью является сделать так, чтобы расширенные функции могли быть применены к одному конкретному экземпляру и в то же время иметь возможность создать оригинальный экземпляр, который не имеет этих новых функций. Это также позволяет комбинировать несколько декораторов для одного экземпляра, благодаря чему отсутствует привязка к одному декоратору для каждого экземпляра. Этот шаблон является альтернативой созданию подкласса, что относится к созданию класса, который наследует функциональность от родительского класса. В противоположность к созданию подкласса, которое добавляет поведение во время компиляции, «декорирование» позволяет добавить новое поведение в ходе выполнения, если ситуация требует этого.
Чтобы реализовать шаблон «Декоратор», можно выполнить следующие шаги:
1. Выделите оригинальный класс «Компонент» как подкласс класса «Декоратор».
2. В классе «Декоратор» добавьте указатель «Компонент» как поле.
3. Переместите «Компонент» в конструктор «Декоратора», чтобы инициализировать указатель «Компонент».
4. В классе «Декоратор» перенаправьте все методы «Компонент» на указатель «Компонент».
5. В классе «Декоратор» отмените любой метод (любые методы) «Компонент», поведение которого (которых) должно быть модифицировано.
Данные этапы размещены с разрешения владельцев сайта en.wikipedia.org/wiki/Decorator_pattern
Когда можно использовать это?
Наиболее удобно использовать шаблон «Декоратор» для объекта, требующего нового поведения, только когда на это имеется запрос по ситуации. Допустим, имеется HTML-элемент компоновки, ссылка на выход из системы, и вы желаете, чтобы она делала немного различающиеся действия, основываясь на текущей странице. Для этого можно использовать шаблон «Декоратор».
Сначала зададим различные требуемые «декорации»:
• Если мы находимся на главной странице и зарегистрированы, то эта ссылка должна быть «обёрнута» в теги h2.
• Если мы находимся на другой странице и зарегистрированы, то эта ссылка должна быть «обёрнута» в теги подчёркивания.
• Если мы зарегистрированы, то эта ссылка должна быть «обёрнута» в теги полужирного шрифта.
После задания наших «декораций» можно их запрограммировать:
Затем мы должны быть в состоянии использовать это, например, следующим образом:
Здесь можно видеть, как мы оказываемся в состоянии скомбинировать несколько декораторов, если это требуется. Поскольку все декораторы используют магическую функцию __call, то мы можем всё ещё вызвать методы оригинальной функции. Если принять, что мы в настоящий момент находимся внутри главной страницы и зарегистрированы, то HTML-выход должен быть следующим:
Шаблон «Одиночка»
Изображение размещено с разрешения владельцев сайта intoxicologist.wordpress.com
Шаблон проектирования «Одиночка» является порождающим шаблоном проектирования, который обеспечивает наличие одного единственного экземпляра какого-то конкретного класса во время выполнения и глобальную точку доступа к этому единственному экземпляру.
Это облегчает задание точки «координации» для других объектов, также использующих данный единственный экземпляр, поскольку его переменные будут неизменными для любых вызовов.
Когда можно использовать это?
Сделав так, мы можем получать доступ к нашему экземпляру сеанса из различных частей нашего кода, даже в разных классах. Эти данные будут сохраняться в течение всех вызовов getInstance.
Заключение
Имеется ещё много шаблонов проектирования, которые полезно знать; в этой статье я остановился только на некоторых из наиболее известных, которые я использую при программировании. Если есть интерес прочитать о других шаблонах проектирования, то страница Википедии Design Patterns (Шаблоны проектирования) содержит много информации об этом. Если этого недостаточно, то вы всегда можете прочитать книгу «Design Patterns: Elements of Reusable Object-Oriented Software» («Шаблоны проектирования: элементы многократно используемого объектно-ориентированного программного обеспечения»), которая считается одной из лучших по рассматриваемой теме.
И последнее: используя эти шаблоны проектирования, всегда проверяйте, что вы пытаетесь решить правильно поставленную задачу. Как я упоминал ранее, эти шаблоны проектирования необходимо использовать очень осторожно: они — при использовании в ненадлежащем контексте — могут ухудшить ситуацию, но при правильном использовании они просто жизненно необходимы.
Если вы нашли данную статью полезной, то почему бы не ознакомиться с предложением PHP-скриптов на Envato Market. Там представлены тысячи полезных скриптов, которые могут ускорить вашу разработку и улучшить конечный результат. Имеются системы бронирования, контактные формы AJAX, системы информационных бюллетеней и многое другое.