Поведенческие паттерны: Паттерны поведения пользователей / Хабр

Человек не может контролировать себя 24 часа в сутки: часть реакций и действий имеют свои спусковые механизмы и срабатывают автоматически. Одинаковому поведению, речевым оборотам, эмоциональным реакциям и жестам ученые давно дали названия. Это паттерны. В статье пойдет речь об общих характеристиках психологических паттернов, видах и способах коррекции в детском возрасте. Знания о механизме действия паттерного поведения поможет лучше понять себя и окружающих.

Что такое паттерн?

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

Этимологически понятие происходит от английского слова pattern – шаблон, образец. Кроме психологии паттерны встречаются в физике, математике, программировании, дизайне, музыке, строительстве, философии

Пройти тест на тип личности

Еще одна интересная особенность паттерна – активизация полного шаблона поведения при активизации любой его части. Например, почувствовав аромат кофе из кофейни, мы покупаем к напитку печенье. Или погружаемся в радостные воспоминания при упоминании слова «елка». Таким образом, часть паттерна – это курок, который запускает его целиком. Специалисты называют это кодом. Но психологические модели – это не бездумные последовательности действий, а наполненные смыслом поведенческие реакции. Например, бесконечное мытье рук – это невроз. Зато мытье рук после прогулки – это паттерн.

Виды паттерного поведения.

Паттерное поведение – удобный механизм, который достался нам от предков. Оно объясняется принципом рациональности – если реакция выручила несколько раз, она выручит и в дальнейшем. Ведь намного проще пользоваться готовую модель, чем каждый раз придумывать новую.

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

• Социальные и индивидуальные. Социальные шаблоны – это рукопожатие, взмах рукой или поклон при встрече, привычка придерживать за собой двери или пропускать другого человека. Можно назвать это культурой. Индивидуальные шаблоны – это личные привычки человека: манера еды или вождения, последовательность действий во время утренних сборов на работу.
• Врожденные и приобретенные. Врожденные шаблоны – это наша генетика на уровне инстинктов: крик как реакция на боль, отдых после активности, улыбка при виде родного человека. Приобретенные шаблоны появляются в результате воспитания, под влиянием родителей и окружения.
• Позитивные и негативные. Позитивные шаблоны помогают нам гармонично общаться, развиваться, следить за своим здоровьем, преодолевать препятствия. Это все полезные привычки от чистки зубов до улыбки при встрече. Негативные мешают жить, накапливают болезненный опыт, но решаются после визита к психотерапевту.

Различают паттерны:

• Коммуникативные или социальные: мимика, жесты, голос и интонации, которые человек использует при знакомстве, встрече или общении.
• Мышления: мысли, заключения, обобщения, логические выводы в результате действий окружающих людей или после событий.
• Двигательные: защитные реакции в случае опасности, позы, мимика и жесты во время общения, передвижение в пространстве.
• Эмоциональные: диапазон реакций на раздражение, обиду, юмор, комплименты, чужую агрессию.
• Языковые или лингвистические: определенные словосочетания, речевые формы, диалоги, реплики или повторы, которые мы используем в повседневной речи.
• Культурные: культурные образцы, ценности, идеи, характерные для отдельного сообщества или племени.

Зачем корректировать детские паттерны?

При рождении младенец получает базовые модели поведения. По мере взросления на врожденные шаблоны наслаиваются привычки, стереотипы, воспитание. Все вместе они формируют характер человека. Детская психика очень гибкая. Если родители внимательно следят за поведением ребенка, они смогут уловить и убрать потенциально вредные психологические модели. Для начала с ребенком можно провести «зефирный тест».

Пройти тест на характер человека

Впервые «зефирный эксперимент» или маршмеллоу-тест провел профессор социальной психологии Уолтер Мишел. Детей 4-6 лет ставили перед столом, на котором стояла тарелка с одной зефиркой. Ведущий объяснял малышу: если он просидит наедине с лакомством 15 минут и не съест, то потом получит две зефирки. Дети оставались в комнате. Кто-то дожидался до конца эксперимента, но большинство сдавались на первой минуте. Ученые проследили судьбу детей в дальнейшем. Оказалось, что терпеливые дети в дальнейшем достигали в жизни больше остальных.

Если родители захотят воспитать ребенка так, чтобы он выбирал «лакомство потом», начинать стоит с первых лет жизни: с обычной чистки зубов, уборки игрушек, подарков или других поощрений. Настойчивость и терпение родителей помогут создать ребенку паттерн самоконтроля и не соблазняться сегодняшним зефиром. Правда, совсем недавно, чистоту этого эксперимента поставили под сомнение, так как оказалось, что есть большая зависимость между тем, в насколько богатой семье рос ребенок и его способностью противостоять соблазнам. И неудивительно, что дети из богатых семей в дальнейшем имели больше шансов добиться успеха, так как могли получить лучшее образование и иметь более влиятельные связи.

Как использовать паттерны для изучения других людей?

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

Другой способ использования чужих шаблонов – провокация или манипуляция поведением другого человека. Многие способы известны нам с детства: взять жертву «на слабО», польстить или восхититься, спровоцировать конфликт или скандал, вызвать чувство вины или стыда. Зная поведенческие модели знакомого человека, можно получить от него нужную информацию или вынудить совершить желаемое действие. Знание собственных паттернов поможет распознать провокатора и выработать против них устойчивый иммунитет.

За шаблонами поведения покупателей внимательно следят маркетологи. Ведь знание поведенческих паттернов – это как разведка перед боем, дает 85% результата. Знание того, «как люди покупают», помогает маркетологам воздействовать на покупателей в дальнейшем. Это выкладка дорогого товара на уровне глаз, прикассовые стенды с игрушками, быстрое оформление заказа, доставка габаритных грузов.

Отслеживание паттернов.

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

• Привычка листать соцсети перед сном приводит к недосыпу, а привычка есть на ходу, пропускать завтрак и обед – к скачкам уровня сахара в крови, тремору, головокружению.
• Привычка обобщать все события «Мне не повезло сегодня, значит я неудачник» провоцирует плохое настроение, депрессию.
• Привычка грубить оппоненту приводит к проблемам на работе и в личной жизни.

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

Выводы:

• Психологические паттерны – застывшие схемы действий, имеющиеся в нашем жизненном опыте.
• Формирование психологических шаблонов запускается в детстве и в раннем возрасте их можно корректировать.
• Наши шаблоны поведения оберегают и ограничивают одновременно.
• Убрать негативные паттерны сложно, проще заменить их позитивными.

Пройти тест на эмоциональный интеллект EQ

Состояние

Суть паттерна

Состояние — это поведенческий паттерн проектирования, который позволяет объектам менять поведение в зависимости от своего состояния. Извне создаётся впечатление, что изменился класс объекта.

Проблема

Паттерн Состояние невозможно рассматривать в отрыве от концепции машины состояний, также известной как стейт-машина или конечный автомат.

Конечный автомат.

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

Такой подход можно применить и к отдельным объектам. Например, объект Документ может принимать три состояния: Черновик, Модерация или Опубликован. В каждом из этих состоянии метод опубликовать будет работать по-разному:

• Из черновика он отправит документ на модерацию.
• Из модерации — в публикацию, но при условии, что это сделал администратор.
• В опубликованном состоянии метод не будет делать ничего.

Возможные состояния документа и переходы между ними.

Машину состояний чаще всего реализуют с помощью множества условных операторов, if либо switch, которые проверяют текущее состояние объекта и выполняют соответствующее поведение. Наверняка вы уже реализовали хотя бы одну машину состояний в своей жизни, даже не зная об этом. Как насчёт вот такого кода, выглядит знакомо?

class Document is
    field state: string
    // ...
    method publish() is
        switch (state)
            "draft":
                state = "moderation"
                break
            "moderation":
                if (currentUser.role == 'admin')
                    state = "published"
                break
            "published":
                // Do nothing.
                break
    // ...

Основная проблема такой машины состояний проявится в том случае, если в Документ добавить ещё десяток состояний. Каждый метод будет состоять из увесистого условного оператора, перебирающего доступные состояния. Такой код крайне сложно поддерживать. Малейшее изменение логики переходов заставит вас перепроверять работу всех методов, которые содержат условные операторы машины с

Стратегия

Суть паттерна

Стратегия — это поведенческий паттерн проектирования, который определяет семейство схожих алгоритмов и помещает каждый из них в собственный класс, после чего алгоритмы можно взаимозаменять прямо во время исполнения программы.

Проблема

Вы решили написать приложение-навигатор для путешественников. Оно должно показывать красивую и удобную карту, позволяющую с лёгкостью ориентироваться в незнакомом городе.

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

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

Через некоторое время выяснилось, что некоторые люди предпочитают ездить по городу на общественном транспорте. Поэтому вы добавили и такую опцию прокладывания пути.

Но и это ещё не всё. В ближайшей перспективе вы хотели бы добавить прокладывание маршрутов по велодорожкам. А в отдалённом будущем — интересные маршруты посещения достопримечательностей.

Код навигатора становится слишком раздутым.

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

Любое изменение алгоритмов поиска, будь то исправление багов или добавление нового алгоритма, затрагивало основной класс. Это повышало риск сделать ошибку, случайно задев остальной работающий код.

Кроме того, осложнялась командная работа с другими программистами, которых вы наняли после успешного релиза навигатора. Ваши изменения нередко затрагивали один и тот же код, создавая конфликты, которые требовали дополнительного времени на их разрешение.

Решение

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

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

Паттерны ООП в метафорах / Хабр

Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.

Что же такое вообще паттерн в ООП?

Паттерн (от англ. Pattern) — образец, шаблон.
Представьте, что вы хотите сделать новый автомобиль, но вы никогда этим не занимались. Сколько колес и почему вы спроектируете для него? Сейчас вы уже скорее всего скажете что 4, однако почему не 3, 5, 10, 20? Потому-что практикой использования уже было выяснено, что обычные автомобили лучше всего делать на 4-х колесах — это шаблон проектирования сформированный временем. Именно такому же подходу и служат паттерны в ООП и вы не столкнетесь с ними в разработке до тех пор, пока вам не потребуется «сделать автомобиль». Однако иногда случается так, что вы создаете «трицикл», и только потом, набив несколько шишек с его устойчивость и неудачным вписыванием в колею на дороге, узнаете что существует паттерн «автомобиль», который значительно упростил бы вам жизнь, знай вы про него ранее.

Примечание:
Паттерны не привязаны к какому-либо конкретному языку программирования. Это просто подход к проектированию чего-либо. Если смотреть глубже, то многие паттерны ООП были созданы на основе реальных жизненный ситуаций в проектировании вполне себе осязаемых объектов нашего мира. Именно на таких метафорах и описаниях и будет построено дальнейшее изложение.

Порождающие паттерны

Паттерны которые создают новые объекты, или позволяют получить доступ к уже существующим. То есть те шаблоны, по которым можно создать новый автомобиль и как это лучше сделать.

Singleton (одиночка)

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

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

Registry (реестр, журнал записей)

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

Паттерны «одиночка» и «реестр» постоянно встречаются нам в повседневной жизни. Например бухгалтерия в фирме является «одиночкой», потому как она всегда одна и помнит что с ней происходило с момента ее начала работы. Фирма не создает каждый раз новую бухгалтерию когда ей требуется выдать зарплату. В свою очередь бухгалтерия является и «реестром», потому как в ней есть записи о каждом работнике фирмы.

Примечание:
«Реестр» нередко является «одиночкой», однако это не всегда должно быть именно так. Например мы можем заводить в бухгалтерии несколько журналов, в одном работники от «А» до «М», в другом от «Н» до «Я». Каждый такой журнал будет «реестром», но не «одиночкой», потому как журналов уже 2. Хотя нередко «реестр» служит именно для хранения «одиночек».
Сам паттерн «реестр» не являтся «порождающим паттерном» в полном смысле этого термина, однако его удобно рассматривать именно во взаимосвязи с ними.

Multiton (пул «одиночек»)

Как понятно из названия паттерна, это по своей сути «реестр» содержащий несколько «одиночек», каждый из которых имеет своё «имя» по которому к нему можно получить доступ.

Object pool (пул объектов)

По аналогии с «пулом одиночек» данный паттерн также позволяет хранить уже готовые объекты, однако они не обязаны быть «одиночками».

Factory (фабрика)

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

Builder (строитель)

Данный паттерн очень тесно переплетается с паттерном «фабрики». Основное различие заключается в том, что «строитель» внутри себя, как правило, содержит все сложные операции по созданию объекта (пакета сока). Вы говорите «хочу сока», а строитель запускает уже целую цепочку различных операций (создание пакета, печать на нем изображений, заправка в него сока, учет того сколько пакетов было создано и т.п.). Если вам потребуется другой сок, например ананасовый, вы точно также говорите только то, что вам нужно, а «строитель» уже позаботится обо всем остальном (какие-то процессы повторит, какие-то сделает заново и т.п.). В свою очередь процессы в «строителе» можно легко менять (например изменить рисунок на упаковке), однако потребителю сока этого знать не требуется, он также будет легко получать требуемый ему пакет сока по тому же запросу.

Примечание:
Чтобы лучше понять разницу между фабрикой и строителем, можно использовать следующую метафору.
«Фабрика» — это автомат по продаже напитков, в нем уже есть всё готовое (или «осталось разогреть»), а вы только говорите что вам нужно (нажимаете кнопку). «Строитель» — это завод, который производит эти напитки и содержит в себе все сложные операции и может собирать сложные объекты из более простых (упаковка, этикетка, вода, ароматизаторы и т.п.) в зависимости от запроса.

Prototype (прототип)

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

Factory method (фабричный метод)

Данный паттерн довольно сложно объяснить в метафорах, но всё же попробую.
Ключевой сложностью объяснения данного паттерна является то, что это «метод», поэтому метафора метода будет использовано как действие, то есть например слово «Хочу!». Соответственно, паттерн описывает то, как должно выполнятся это «Хочу!».
Допустим ваша фабрика производит пакеты с разными соками. Теоретически мы можем на каждый вид сока делать свою производственную линию, но это не эффективно. Удобнее сделать одну линию по производству пакетов-основ, а разделение ввести только на этапе заливки сока, который мы можем определять просто по названию сока. Однако откуда взять название?
Для этого мы создаем основной отдел по производству пакетов-основ и предупреждаем все под-отделы, что они должны производить нужный пакет с соком про простому «Хочу!» (т.е. каждый под-отдел должен реализовать паттерн «фабричный метод»). Поэтому каждый под-отдел заведует только своим типом сока и реагирует на слово «Хочу!».
Таким образом если нам потребуется пакет апельсинового сока, то мы просто скажем отделу по производству апельсинового сока «Хочу!», а он в свою очередь скажет основному отделу по созданию пакетов сока, «Сделай ка свой обычный пакет и вот сок, который туда нужно залить».

Примечание:
Как вы могли уже заметить, «фабричный метод» является как бы основой для «фабрики», «строителя» и «прототипа». В разработке часто именно так и получается, сперва реализуют фабричный метод, а по мере усложнения кода выбирают во что именно его преобразовать, в какой из перечисленных паттернов. При использовании «фабричного метода» каждый объект как бы сам является «фабрикой».

Lazy initialization (отложенная инициализация)

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

Dependency injection (внедрение зависимости)

Внедрение зависимости позволяет переложить часть ответственности за какой-то функционал на другие объекты. Например если нам требуется нанять новый персонал, то мы можем не создавать свой отдел кадров, а внедрить зависимость от компании по подбору персонала, которая свою очередь по первому нашему требованию «нам нужен человек», будет либо сама работать как отдел кадров, либо же найдет другую компанию (при помощи «локатора служб»), которая предоставит данные услуги.
«Внедрение зависимости» позволяет перекладывать и взаимозаменять отдельные части компании без потери общей функциональности.

Service Locator (локатор служб)

автор: VolCh
«Локатор служб» является методом реализации «внедрения зависимости». Он возвращает разные типы объектов (компаний) в зависимости от кода инициализации. Пускай задача стоит доставить наш пакет сока, созданный строителем, фабрикой или ещё чем, куда захотел покупатель. Мы спрашиваем у локатора «дай нам службу доставки», и он нам соединяет на со службой доставки по номеру телефона, который директор ему дал (потому что получает откат они нам дают скидку как постоянным клиентам), а мы уже просим службу доставить сок по нужному адресу. Сегодня одна служба, а завтра может быть другая. Нам без разницы какая это конкретно служба, решение принимает директор и сообщает об этом локатору служб, нам важно знать лишь что они могут доставлять то, что мы им скажем туда, куда скажем, то есть службы реализуют интерфейс «Доставить на ».

Структурирующие паттерны

Данные паттерны помогают внести порядок и научить разные объекты более правильно взаимодействовать друг с другом.

Adapter или wrapper (адаптер, обертка)

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

Bridge (мост)

Представим ситуацию, когда вам требуется работать на разных автомобилях, однако садясь в новый автомобиль вам уже желательно знать как им управлять. Таким образом вы сталкиваетесь с паттерном «мост». С одной стороны вы имеете множество различных автомобилей (разные модели и марки), но среди все них есть общая абстракция (интерфейс) ввиде руля, педалей, коробки передач и так далее. Таким образом мы задаем как-бы правила изготовления автомобилей по которым мы можем создавать любые их виды, но за счет сохранения общих правил взаимодействия с ними, мы можем одинаково управлять каждым из них. «Мостом» в данном случае является пара двух «объектов»: конкретного автомобиля и правил взаимодействия с этим (и любым другим) автомобилем.

Composite (компоновщик)

Довольно интересный паттерн суть которого заключается в минимизации различий в управлении как группами объектов так и индивидуальными объектами. Для примера можно рассмотреть управление солдатами в строю. Существует строевой устав, который определяет как управлять строем и согласно этого устава абсолютно не важно кому отдается приказ (например «шагом марш») одному солдату или целому взводу. Соответственно в устав (если его в чистом виде считать паттерном «компоновщик») нельзя включить команду, которую может исполнить только один солдат, но не может исполнить группа, или наоборот.

Decorator (декоратор, оформитель)

Как понятно из названия, данный паттерн чаще всего используется для расширения исходного объекта до требуемого вида. Например мы условно можем считать «декоратором» человека с кистью и красной краской. Таким образом, какой бы объект (или определенный тип объектов) мы не передали в руки «декоратору», на выходе мы будем получать красные объекты.

Facade (фасад)

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

Front controller (единая точка входа)

Если проводить аналогии с реальными миром, то «единая точка входа» это то, через что вы сейчас читаете данную статью (например броузер). Она служит «единой точкой входа» для всего интернет пространства. То есть вы используете один интерфейс (броузер) для получения доступа к разным объектам большой системы (сайтам в интернете). Данный паттерн в целом сильно похож на «фасад».

Flyweight (приспособленец)

Самым лучшим примером (который я смог найти в реальной жизни) для метафорического сравнения паттерна «приспособленец» является театральная постановка. Представьте что нам требуется поставить пьесу. Однако по сценарию в этой пьесе задействованы несколько десятков людей, которые по своей сути выполняют одинаковые действия, например участвуют в массовках различных сцен в разные промежутки времени, но между ними всё же есть какие-то различия (например костюмы). Нам бы стоило огромных денег нанимать для каждой роли отдельного актера, поэтому мы используем паттерн «приспособленец». Мы создадим все нужные нам костюмы, но для каждой массовки будем переодевать небольшую группу актеров в требуемые для этой сцены костюмы. В результате мы имеем возможность ценой малых ресурсов создавать видимость управления большим количеством казалось бы разных объектов.

Proxy или surrogate (прокси, заместитель, суррогат)

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

Паттерны поведения

Эта группа паттернов позволяет структурировать подходы к обработке поведения и взаимодействия объектов. Проще говоря, как должны проходить процессы в которых существует несколько вариантов протекания событий.

Chain of responsibility (цепочка обязанностей)

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

Command или action (команда, действие)

Паттерн «команда» очень похож в реальной жизни на кнопки выключателей света в наших квартирах и домах. Каждый выключатель по своей сути делает одно простое действие — разъединяет или соединяет два провода, однако что стоит за этими проводами выключателю не известно. Что подключат, то и произойдет. Точно также действует и паттерн «команда». Он лишь определяет общие правила для объектов (устройств), в виде соединения двух проводов для выполнения команды, а что именно будет выполнено уже определяет само устройство (объект).
Таким образом мы можем включать одним типом выключателей как свет в комнате, так и пылесос.

Interpreter (интерпретатор)

Сравнить данный паттерн можно с тем, как вы закладываете часто используемые действия в сокращенный набор слов, чтобы сам «интерпретатор» потом превратил этот набор в более комплексные осмысленные действия. По сути каждый человек постоянно является «интерпретатором». Хотите провести жизненный эксперимент? Если из дома выходит кто-то из вашей семьи (муж, жена, ребенок), скажите ему простой набор слов «Литр молока, половинку белого, 200 грамм творога». По сути вы ничего особенного не сказали, лишь перечислили набор продуктов, однако велик шанс того, что «интерпретатор» транслирует это в команду «зайди по дороге в продуктовый магазин и купи следующее … и принеси это домой». Паттерн «интерпретатор» призван сократить часто исполняемые действия в более короткое их описание.

Iterator (итератор, указатель)

Все помнят школьное «на первый второй рассчитайся!»? Вот именно в этот момент шеренга вашего класса и являлась реализацией паттерна «итератор», хотя в программировании это конечно более функциональное понятие, но суть примерно та же. «Итератор» предоставляет правила доступа к списку каких-либо объектов независимо от того, что это за объекты. То есть не важно какой именно класс построен и из каких учеников, должны быть общие правила подсчета и обращения как каждому ученику по списку, вроде «13-ый, выйти из строя». Нередко паттерн «итератор» используется для доступа к «реестру». Ссылки, которые вы видите на многих сайтах для переходов по страницам, вроде «следующая», «предыдущая», «в начало» и т.п. по своей сути также являются доступом «итератору» который отвечает за страницы сайта.

Mediator (посредник)

Вспомним пример из паттерна «одиночка». Так вот телефонная станция в том примере по сути также являлась паттерном «посредник», то есть обеспечивала взаимодействие группы объектов без необходимости обеспечения связи каждого объекта друг с другом.
Однако дополнительной ответственность этого «паттерна» является также управление этой группой через «посредника». То есть если мы возьмем пример с армейским строем, то медиатором будет командир отделения, то есть нам нет необходимости взаимодействовать с каждым солдатом в отдельности, достаточно отдавать приказания лишь командиру отделения, а он уже сам решит какие действия должны быть выполнены внутри его отделения.

Memento (хранитель)

Никогда не просили друга с сотовым телефоном на время запомнить (записать себе) тот номер, что диктуют вам по телефону, потому что вы не можете его запомнить сами (телефон занят)? В этот момент ваш друг реализовывал паттерн «хранитель». Он служит для тех случаев, когда какому-либо объекту требуется сохранить своё состояние (состояние знания номера) в другом объекте (вашем друге), и при необходимости его потом восстановить (спросить у друга номера и тем самым восстановить состояние когда вы его знали). Также уместен аналог с тем, как в играх работает сохранение. Файл «сейва» как раз и будет тем самым паттерном «хранитель».

Observer или Listener (наблюдатель, слушатель)

Очень распространенный паттерн в реальной жизни. Например если вы подписались на какую-либо email (или смс) рассылку, то ваш email (или номер сотового телефона) начинает реализовывать паттерн «наблюдатель». Как только вы подписываетесь на событие (например новая статья или сообщение), всем кто подписан на это событие (наблюдателям) будет выслано уведомление, а они уже в свою очередь могут выбрать как на это сообщение реагировать.

Blackboard (доска объявлений)

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

Servant (слуга)

Как следует из названия, данный паттерн служит для предоставления группе объектов какого-либо общего функционала. Например телефонная станция является для жителей города паттерном «слуга» если речь заходит о том, как узнать точное время (набрать номер 100).

State (состояние)

В реальной жизни каждый человек может прибывать в разных состояниях. Точно также порой требуется чтобы объекты в программе вели себя по разному в зависимости от каких-либо их внутренних состояний. По аналогии с реальной жизнью можно например привести следующий пример:
Если вы устали то на фразу «Сходи в магазин» вы будете выдавать «Не пойду», если вам нужно сходить в магазин (за пивом?), то на «Сходи в магазин» вы будете выдавать «Уже бегу!». Человек (объект) один и тот же, а поведение разное. Именно для этих целей и используют паттерн «состояние».

Strategy (стратегия)

Используется для выбора различных путей получения результата. Вспомним пример с получением прав. Человек, который будет реализовывать паттерн «стратегия» будет действовать следующим образом: вы говорите ему «Хочу права, денег мало» в ответ вы получите права через длительное время и с большой тратой ресурсов. Если вы скажите ему «Хочу права, денег много», то вы получите права очень быстро. Что именно делал этот человек вы понятия не имеете, но вы задаете начальные условия, а как себя вести уже решает он сам (сам выбирает стратегию).
Соответственно внутри «стратегии» хранятся различные способы поведения, и чтобы выбрать, ему нужны определенные параметры, в данном случае это объем денежных средств. Как устроена сама «стратегия» и какие алгоритмы внутри нее вам собственно знать и требуется.

Specification (спецификация, определение)

Паттерн спецификации позволяет описывать подходит ли данный объект нам на основе каких-либо критериев. Например мы имеем несколько контейнеров для погрузки на судно. Однако чтобы определить грузить контейнер или нет на определенное судно, нам нужно выбрать метод как это определять. Реализация такого метода и является паттерном «спецификация». В самом простом случае для каждого контейнера мы можем определить в паттерне «спецификация» совпадает ли страна назначения корабля со страной назначения контейнера. Соответственно мы один раз вводим правило «сравнить две страны назначения» и применяем его ко всем контейнерам для проверки.

Subsumption (категоризация)

Данный паттерн является прямым последователем паттерна «спецификация». Он позволяет распределять объекты по категориям на основе каких-либо условий. Соответственно по аналогии с примером кораблей и контейнеров, это категоризация по тому, какие контейнеры в какие страны направляются.

Visitor (посетитель)

Данный паттерн можно сравнить с прохождением обследования в больнице. Однако «посетителем» в терминах паттернов здесь будут сами врачи. Чтобы было понятнее: у нас есть больной которого требуется обследовать и полечить, но так как за разные обследования отвечают разные врачи, то мы просто присылаем к больному врачей в качестве «посетителей». Правило взаимодействия для больного очень простое «пригласите врача (посетителя) чтобы он сделал свою работу», а врач («посетитель») приходит, обследует и делает всё необходимое. Таким образом следуя простым правилам можно использовать врачей для разных больных по одним и тем же алгоритмам. Как уже было сказано, паттерном «посетитель» в данном случае является врач, который может одинаково обслуживать разные объекты (больных) если его позовут.

Single-serving visitor (одноразовый посетитель)

Является частным случаем использования паттерна «посетитель». Если в случае с обычным «посетителем» у нас есть врач которого мы можем отправить к разным больным (и при желании по несколько раз), то в данном паттерне можно привести аналогию, что мы нанимаем врача, отправляем его к одному больному и после обследования сразу увольняем.

Hierarchical visitor (иерархический посетитель)

Тот же самый паттерн «посетитель», однако в данном случае он отправляется к не одному больному, а в целую больницу и обходит там всех больных.

Заключение

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

Надеюсь вы нашли данный материал полезным для себя и благодарю за внимание.

UPD:
дополнительные материалы, которые также могут быть интересны по данной теме:
От пользователя Markel
www.cours.polymtl.ca/inf3700/divers/nonSoftwareExample/patexamples.html

От пользователя NikoM
Книга «Фримен, Фримен, Сьерра: Паттерны проектирования»

Наблюдатель

Также известен как: Издатель-Подписчик, Слушатель, Observer

Суть паттерна

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

Проблема

Представьте, что вы имеете два объекта: Покупатель и Магазин. В магазин вот-вот должны завезти новый товар, который интересен покупателю.

Покупатель может каждый день ходить в магазин, чтобы проверить наличие товара. Но при этом он будет злиться, без толку тратя своё драгоценное время.

Постоянное посещение магазина или спам?

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

Получается конфликт: либо покупатель тратит время на периодические проверки, либо магазин тратит ресурсы на бесполезные оповещения.

Решение

Давайте называть Издателями те объекты, которые содержат важное или интересное для других состояние. Остальные объекты, которые хотят отслеживать изменения этого состояния, назовём Подписчиками.

Паттерн Наблюдатель предлагает хранить внутри объекта издателя список ссылок на объекты подписчиков, причём издатель не должен вести список подписки самостоятельно. Он предоставит методы, с помощью которых подписчики могли бы добавлять или убирать себя из списка.

Подписка на события.

Теперь самое интересное. Когда в издателе будет происходить важное событие, он будет проходиться по списку подписчиков и оповещать их об этом, вызывая определённый метод объектов-подписчиков.

Издателю безразлично, какой класс будет иметь тот или иной подписчик, так как все они должны следовать общему интерфейсу и иметь единый метод оповещения.

Оповещения о событиях.

Увидев, как складно всё работает, вы можете выделить общий интерфейс, описывающий методы подписки и отписки, и для всех издателей. После этого подписчики смогут работать с разными типами издателей, а также получать оповещения о

Паттерны/шаблоны проектирования

Паттерны (или шаблоны) проектирования описывают типичные способы решения часто встречающихся проблем при проектировании программ.

Каталог паттернов

Список из 22-х классических паттернов, сгруппированых по предназначению.

Польза паттернов

Вы можете вполне успешно работать, не зная ни одного паттерна. Но зная паттерны, вы получаете ещё один инструмент в свой личный набор профессионала.

Классификация

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

История паттернов

Кто и когда придумал паттерны? Можно ли использовать язык паттернов вне разработки программного обеспечения?

Критика паттернов

Так ли паттерны хороши на самом деле? Всегда ли можно их использовать? Почему, иногда, паттерны бывают вредными?

Погружение в Паттерны

поведенческих моделей

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

• Цепочка ответственности
  Способ передачи запроса между цепочкой объектов
• Команда
  Инкапсулируйте запрос команды как объект
• Переводчик
  Способ включения языковых элементов в программу
Итератор
• 
  Последовательный доступ к элементам коллекции
• Посредник
  Определяет упрощенную связь между классами
• Memento
  Захват и восстановление внутреннего состояния объекта
• Нулевой объект
  Предназначен для использования в качестве значения по умолчанию для объекта
• Observer
  Способ уведомления об изменении количества классов
• Состояние
  Изменение поведения объекта при изменении его состояния
Стратегия
• 
  Инкапсулирует алгоритм внутри класса
• Шаблонный метод
  Отложить точные шаги алгоритма до подкласса
• Посетитель
  Определяет новую операцию для класса без изменений

Правила большого пальца

1. Поведенческие модели связаны с распределением обязанностей между объектами или инкапсулированием поведения в объекте и делегированием запросов к нему.
2. Цепочка ответственности, Командование, Посредник и Наблюдатель, описывают, как вы можете отделить отправителей и получателей, но с различными компромиссами. Цепочка ответственности передает запрос отправителя по цепочке потенциальных получателей. Команда обычно указывает соединение отправитель-получатель с подклассом. Посредник имеет отправителей и получателей ссылки друг на друга косвенно. Observer определяет очень отделенный интерфейс, который позволяет настроить несколько приемников во время выполнения.
3. Цепочка ответственности может использовать Command для представления запросов в виде объектов.
4. Цепочка ответственности часто применяется в сочетании с Composite. Там родитель компонента может действовать как его преемник.
5. Командование и Мементо действуют как магические жетоны, которые можно передать и использовать позже. В Command токен представляет запрос; в Memento это представляет внутреннее состояние объекта в определенное время. Полиморфизм важен для Command, но не для Memento, потому что его интерфейс настолько узок, что сувенир может быть передан только как значение.
6. Команда может использовать Memento для поддержания состояния, необходимого для отмены операции.
Макрокоманды
7. могут быть реализованы с помощью Composite.
8. Команда, которую необходимо скопировать перед помещением в список истории, действует как прототип.
9. Интерпретатор может использовать State для определения контекстов синтаксического анализа.
10. Абстрактное синтаксическое дерево интерпретатора является составным (поэтому итераторы и посетители также применимы).
11. Терминальные символы в абстрактном синтаксическом дереве интерпретатора могут использоваться совместно с Flyweight.
12. Итератор может пройти через Composite. Посетитель может применить операцию над Composite.
13. Полиморфные итераторы используют фабричные методы для создания экземпляров соответствующего подкласса итераторов.
14. Посредник и Наблюдатель — конкурирующие модели. Разница между ними заключается в том, что Observer распределяет связь, вводя объекты «наблюдатель» и «субъект», тогда как объект-посредник инкапсулирует связь между другими объектами. Мы обнаружили, что легче создавать повторно используемых наблюдателей и субъектов, чем повторно используемых посредников.
15. С другой стороны, Mediator может использовать Observer для динамической регистрации коллег и общения с ними.
16. Mediator похож на Facade тем, что он абстрагирует функциональность существующих классов. Посредник абстрагирует / централизует произвольную связь между объектами коллег, он обычно «добавляет ценность», и на него ссылаются объекты коллег (т. Е. Он определяет разнонаправленный протокол). В отличие от

.

моделей поведения (13 описанных моделей)

Поведенческие образцы дизайна (13 описанных образцов)

Поведенческие образцы

Поведенческие шаблоны дизайна

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

1. Цепочка ответственности: Командные объекты обрабатываются или передаются другим объектам объектами обработки, содержащими логику
2. Команда: Командные объекты инкапсулируют действие и его параметры
3. Переводчик: Внедрение специализированного компьютерного языка для быстрого решения определенного набора проблем
4. Итератор: Итераторы используются для последовательного доступа к элементам агрегированного объекта без раскрытия его базового представления
5. Посредник: Предоставляет унифицированный интерфейс для набора интерфейсов в подсистеме
6. Примечание: Предоставляет возможность восстановить объект до его предыдущего состояния (откат)
7. Наблюдатель: , также известный как публикация / подписка или прослушиватель событий.Объект регистрируется для наблюдения за событием, которое может быть вызвано другим объектом
.
8. Состояние: Чистый способ частичного изменения своего типа во время выполнения
9. Стратегия: Алгоритмы могут быть выбраны на лету
10. Шаблонный метод: Описывает программный скелет программы
11. Посетитель: Способ отделения алгоритма от объекта

подшаблонов

1. Внешность стека: Превратите рекурсивную функцию в итеративную, использующую стек.
2. Иерархический посетитель: Предоставить способ посещения каждого узла в иерархической структуре данных, такой как дерево.
3. Null Object: Предназначен для использования в качестве значения по умолчанию для объекта
4. Стек протокола : Связь обрабатывается несколькими уровнями, которые образуют иерархию инкапсуляции.
5. Запланированное задание: Запланированное задание должно быть выполнено в определенный интервал или время часов (используется в вычислениях в реальном времени)
6. Однократный посетитель: Оптимизация реализации посетителя, который назначается, используется только один раз, а затем удаляется
7. Спецификация: Рекомбинантная бизнес-логика логическим способом
8. Слабая ссылка: Отстранить наблюдателя от наблюдаемой.

Поведенческие образцы «Предыдущая Следующий» ,

Поведенческие, творческие и структурные модели [Определение] Поведенческие, творческие и структурные паттерны [Определение]

Шаблоны проектирования «Предыдущая

Поведенческие, творческие, структурные типы шаблонов проектирования

Основываясь на официальной книге шаблонов проектирования «Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения», существует 23 шаблона проектирования.Эти шаблоны могут быть сгруппированы в три категории:

1. Творческий,
2. структурных и
3. Поведенческие модели.
4. Кроме того, мы обсудим еще одну категорию шаблонов проектирования: шаблоны проектирования J2EE.

1. Шаблоны создания: Эти шаблоны проектирования предоставляют способы создания объектов, скрывая логику создания , вместо создания экземпляров объектов непосредственно с помощью нового оператора .Это дает программе большую гибкость в определении того, какие объекты необходимо создать для данного варианта использования .
2. Структурные шаблоны: Эти шаблоны проектирования имеют дело с композицией классов и объектов. Концепция наследования используется для составления интерфейсов и определения способов составления объектов для получения новых функциональных возможностей.
3. Поведенческие образцы: Эти шаблоны проектирования особенно связаны с коммуникацией между объектами.
4. Шаблоны J2EE: Эти шаблоны проектирования специально связаны с уровнем представления. Эти шаблоны были ранее идентифицированы Sun Java, а теперь Oracle.

Название шаблона:

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

Шаблоны проектирования

Каковы элементы шаблона дизайна?

Имя шаблона — это описание из одного или двух слов, которое программисты, знающие шаблоны, могут использовать для общения друг с другом. Примеры имен включают 1) заводской метод 2) синглтон 3) медиатор 4) прототип. Название шаблона должно напоминать проблему, которую он решает, и решение.
Проблема, которую решает шаблон, включает в себя общее намерение и более конкретную мотивацию или два. Например, цель шаблона синглтона состоит в том, чтобы предотвратить создание более одного экземпляра класса. Мотивирующим примером может быть запрещение нескольким объектам одновременно пытаться получить доступ к звуковому оборудованию системы, разрешая только один аудиообъект.

Решение проблемы определяет элементы, которые составляют шаблон, такие как конкретные классы, методы, интерфейсы, структуры данных и алгоритмы.Решение также включает в себя отношения, обязанности и сотрудников различных элементов. Действительно, эти взаимосвязи и структура, как правило, более важны для шаблона, чем отдельные части, которые могут измениться без существенного изменения шаблона.
Часто более чем один шаблон может решить проблему. Таким образом, определяющим фактором часто являются последствия модели. Некоторые шаблоны занимают больше места, а некоторые занимают больше времени. Кроме того, некоторые шаблоны более масштабируемы, чем другие.
Шаблоны проектирования «Предыдущая

,

Java — что такое структурные и поведенческие шаблоны проектирования Переполнение стека

1. Товары
2. Клиенты
3. Случаи использования

1. Переполнение стека Публичные вопросы и ответы
2. Команды Частные вопросы и ответы для вашей команды
3. предприятие Частные вопросы и ответы для вашего предприятия
4. работы Программирование и связанные с ним технические возможности карьерного роста
5. Талант Нанимать технический талант
6. реклама Связаться с разработчиками по всему миру

Загрузка…

2. Авторизоваться зарегистрироваться

3. текущее сообщество

.