zorca · February 10, 2024 02:45 · Nov 1, 2017 · Nov 1, 2017 · Nov 1, 2017 · Nov 1, 2017
diff --git a/test_app.md b/test_app.md
@@ -471,4 +471,7 @@ class DI
 * Посредник между уровнями области определения (хранилище) и распределения данных. Использует интерфейс, похожий на коллекции, для доступа к объектам области определения. Репозиторий инкапсулирует набор объектов, сохраняемых в хранилище данных, и операции выполняемые над ними, обеспечивая более объектно-ориентированное представление реальных данных. Репозиторий также преследует цель достижения полного разделения и односторонней зависимости между уровнями области определения и распределения данных.
 * Вероятно, наиболее важным отличием репозиториев является то, что они представляют собой коллекции объектов. Они не описывают хранение в базах данных или кэширование или решение любой другой технической проблемы. Репозитории представляют коллекции.
 * Основное преимущество репозиториев — это абстрактный механизм хранения для коллекций сущностей.
-* Пример: https://github.com/deuterium7/repository-test
+* Пример: https://github.com/deuterium7/repository-test
+#### Сущность-Атрибут-Значение (Entity Attribute Value)
+* Модель Сущность-Атрибут-Значение (EAV) - это модель данных, предназначенная для описания сущностей, в которых количество атрибутов (свойств, параметров), характеризующих их, потенциально огромно, но то количество, которое реально будет использоваться в конкретной сущности относительно мало.
+* Пример: https://github.com/deuterium7/entity-attribute-value-test
diff --git a/test_app.md b/test_app.md
@@ -466,4 +466,9 @@ class DI
 ####  Локатор Служб (Service Locator)
 * Локатор служб — это шаблон проектирования, используемый в разработке программного обеспечения для инкапсуляции процессов, связанных с получением какого-либо сервиса с сильным уровнем абстракции. Этот шаблон использует центральный реестр, известный как «локатор сервисов», который по запросу возвращает информацию (как правило это объекты), необходимую для выполнения определенной задачи. Обратите внимание, что в некотором случае, локатор служб фактически является анти-шаблоном.
 * Аналогия: Пускай задача стоит доставить пакет сока, созданный строителем, фабрикой или ещё чем, куда захотел покупатель. Мы говорим локатору «дай нам службу доставки», и просим службу доставить сок по нужному адресу. Сегодня одна служба, а завтра может быть другая. Нам без разницы какая это конкретно служба, нам важно знать, что эта служба доставит то, что мы ей скажем и туда, куда скажем. В свою очередь службы реализуют интерфейс «Доставить <предмет> на <адрес>».
-* Пример: https://github.com/deuterium7/service-locator-test
+* Пример: https://github.com/deuterium7/service-locator-test
+#### Хранилище (Repository)
+* Посредник между уровнями области определения (хранилище) и распределения данных. Использует интерфейс, похожий на коллекции, для доступа к объектам области определения. Репозиторий инкапсулирует набор объектов, сохраняемых в хранилище данных, и операции выполняемые над ними, обеспечивая более объектно-ориентированное представление реальных данных. Репозиторий также преследует цель достижения полного разделения и односторонней зависимости между уровнями области определения и распределения данных.
+* Вероятно, наиболее важным отличием репозиториев является то, что они представляют собой коллекции объектов. Они не описывают хранение в базах данных или кэширование или решение любой другой технической проблемы. Репозитории представляют коллекции.
+* Основное преимущество репозиториев — это абстрактный механизм хранения для коллекций сущностей.
+* Пример: https://github.com/deuterium7/repository-test
diff --git a/test_app.md b/test_app.md
@@ -462,4 +462,8 @@ class DI
 * Делегирование (англ. Delegation) — основной шаблон проектирования, в котором объект внешне выражает некоторое поведение, но в реальности передаёт ответственность за выполнение этого поведения связанному объекту. Шаблон делегирования является фундаментальной абстракцией, на основе которой реализованы другие шаблоны - композиция (также называемая агрегацией), примеси (mixins) и аспекты (aspects).
 * Цель: Возможность изменить поведение конкретного экземпляра объекта вместо создания нового класса путемнаследования.
 * Минусы: Этот шаблон обычно затрудняет оптимизацию по скорости в пользу улучшенной чистоты абстракции.
-* Пример: https://github.com/deuterium7/delegation-test
+* Пример: https://github.com/deuterium7/delegation-test
+####  Локатор Служб (Service Locator)
+* Локатор служб — это шаблон проектирования, используемый в разработке программного обеспечения для инкапсуляции процессов, связанных с получением какого-либо сервиса с сильным уровнем абстракции. Этот шаблон использует центральный реестр, известный как «локатор сервисов», который по запросу возвращает информацию (как правило это объекты), необходимую для выполнения определенной задачи. Обратите внимание, что в некотором случае, локатор служб фактически является анти-шаблоном.
+* Аналогия: Пускай задача стоит доставить пакет сока, созданный строителем, фабрикой или ещё чем, куда захотел покупатель. Мы говорим локатору «дай нам службу доставки», и просим службу доставить сок по нужному адресу. Сегодня одна служба, а завтра может быть другая. Нам без разницы какая это конкретно служба, нам важно знать, что эта служба доставит то, что мы ей скажем и туда, куда скажем. В свою очередь службы реализуют интерфейс «Доставить <предмет> на <адрес>».
+* Пример: https://github.com/deuterium7/service-locator-test
diff --git a/test_app.md b/test_app.md
@@ -456,4 +456,10 @@ class DI
 * Шаблон «Посетитель» — это способ отделения алгоритма от структуры объекта, в которой он оперирует. Результат отделения — возможность добавлять новые операции в существующие структуры объектов без их модифицирования. Это один из способов соблюдения принципа открытости/закрытости (open/closed principle).
 * Аналогия: Туристы собрались в Дубай. Сначала им нужен способ попасть туда (виза). После прибытия они будут посещать любую часть города, не спрашивая разрешения, ходить где вздумается. Просто скажите им о каком-нибудь месте — и туристы могут там побывать. Шаблон «Посетитель» помогает добавлять места для посещения.
 * Шаблон «Посетитель» выполняет операции над объектами других классов. Главной целью является сохранение разделения направленности задач отдельных классов. При этом классы обязаны определить специальный контракт, чтобы позволить использовать их Посетителям (метод accept).
-* Примеры: https://github.com/deuterium7/visitor-test
+* Пример: https://github.com/deuterium7/visitor-test
+### 01.11.2017:
+#### Делегрование (Delegation)
+* Делегирование (англ. Delegation) — основной шаблон проектирования, в котором объект внешне выражает некоторое поведение, но в реальности передаёт ответственность за выполнение этого поведения связанному объекту. Шаблон делегирования является фундаментальной абстракцией, на основе которой реализованы другие шаблоны - композиция (также называемая агрегацией), примеси (mixins) и аспекты (aspects).
+* Цель: Возможность изменить поведение конкретного экземпляра объекта вместо создания нового класса путемнаследования.
+* Минусы: Этот шаблон обычно затрудняет оптимизацию по скорости в пользу улучшенной чистоты абстракции.
+* Пример: https://github.com/deuterium7/delegation-test
diff --git a/test_app.md b/test_app.md
@@ -451,4 +451,9 @@ class DI
 4. Настил перекрытий.
 Порядок этапов никогда не меняется. Вы не настелите крышу до возведения стен — и т. д. Но каждый этап модифицируется: стены, например, можно возвести из дерева, кирпича или газобетона.
 * Это каркас алгоритма, который хорошо подходит для библиотек (в фреймворках, например). Пользователь просто реализует уточняющие методы, а суперкласс делает всю основную работу.
-* Пример: https://github.com/deuterium7/template-method-test
+* Пример: https://github.com/deuterium7/template-method-test
+#### Посетитель (Visitor)
+* Шаблон «Посетитель» — это способ отделения алгоритма от структуры объекта, в которой он оперирует. Результат отделения — возможность добавлять новые операции в существующие структуры объектов без их модифицирования. Это один из способов соблюдения принципа открытости/закрытости (open/closed principle).
+* Аналогия: Туристы собрались в Дубай. Сначала им нужен способ попасть туда (виза). После прибытия они будут посещать любую часть города, не спрашивая разрешения, ходить где вздумается. Просто скажите им о каком-нибудь месте — и туристы могут там побывать. Шаблон «Посетитель» помогает добавлять места для посещения.
+* Шаблон «Посетитель» выполняет операции над объектами других классов. Главной целью является сохранение разделения направленности задач отдельных классов. При этом классы обязаны определить специальный контракт, чтобы позволить использовать их Посетителям (метод accept).
+* Примеры: https://github.com/deuterium7/visitor-test
diff --git a/test_app.md b/test_app.md
@@ -441,4 +441,14 @@ class DI
 * Стратегия (англ. Strategy) — поведенческий шаблон проектирования, предназначенный для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости. Это позволяет выбирать алгоритм путём определения соответствующего класса. Шаблон Strategy позволяет менять выбранный алгоритм независимо от объектов-клиентов, которые его используют.
 * Аналогия: Возьмём пример с пузырьковой сортировкой. Мы её реализовали, но с ростом объёмов данных сортировка стала выполняться очень медленно. Тогда мы сделали быструю сортировку (Quick sort). Алгоритм работает быстрее на больших объёмах, но на маленьких он очень медленный. Тогда мы реализовали стратегию, при которой для маленьких объёмов данных используется пузырьковая сортировка, а для больших — быстрая.
 * Этот паттерн является хорошей альтернативой наследованию (вместо расширения абстрактного класса).
-* Пример: https://github.com/deuterium7/strategy-test
+* Пример: https://github.com/deuterium7/strategy-test
+#### Шаблонный Метод (Template Method)
+* Шаблонный метод (англ. Template method) — поведенческий шаблон проектирования, определяющий основу алгоритма и позволяющий наследникам переопределять некоторые шаги алгоритма, не изменяя его структуру в целом.
+* Аналогия: Допустим, вы собрались строить дома. Этапы будут такими:
+1. Подготовка фундамента.
+2. Возведение стен.
+3. Настил крыши.
+4. Настил перекрытий.
+Порядок этапов никогда не меняется. Вы не настелите крышу до возведения стен — и т. д. Но каждый этап модифицируется: стены, например, можно возвести из дерева, кирпича или газобетона.
+* Это каркас алгоритма, который хорошо подходит для библиотек (в фреймворках, например). Пользователь просто реализует уточняющие методы, а суперкласс делает всю основную работу.
+* Пример: https://github.com/deuterium7/template-method-test
diff --git a/test_app.md b/test_app.md
@@ -436,4 +436,9 @@ class DI
 1. Реализации каждого состояния в виде производного класса интерфейса шаблона «Состояние»,
 2. Реализации переходов состояний (state transitions) посредством вызова методов, определённых вышестоящим классом (superclass).
 * Шаблон «Состояние» — это в некотором плане шаблон «Стратегия», при котором возможно переключение текущей стратегии с помощью вызова методов, определённых в интерфейсе шаблона.
-* Пример: https://github.com/deuterium7/state-test
+* Пример: https://github.com/deuterium7/state-test
+#### Стратегия (Strategy)
+* Стратегия (англ. Strategy) — поведенческий шаблон проектирования, предназначенный для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости. Это позволяет выбирать алгоритм путём определения соответствующего класса. Шаблон Strategy позволяет менять выбранный алгоритм независимо от объектов-клиентов, которые его используют.
+* Аналогия: Возьмём пример с пузырьковой сортировкой. Мы её реализовали, но с ростом объёмов данных сортировка стала выполняться очень медленно. Тогда мы сделали быструю сортировку (Quick sort). Алгоритм работает быстрее на больших объёмах, но на маленьких он очень медленный. Тогда мы реализовали стратегию, при которой для маленьких объёмов данных используется пузырьковая сортировка, а для больших — быстрая.
+* Этот паттерн является хорошей альтернативой наследованию (вместо расширения абстрактного класса).
+* Пример: https://github.com/deuterium7/strategy-test
diff --git a/test_app.md b/test_app.md
@@ -428,4 +428,12 @@ class DI
 #### Спецификация (Specification)
 * Шаблон проектирования, посредством которого представление правил бизнес логики может быть преобразовано в виде цепочки объектов, связанных операциями булевой логики.
 * Строит ясное описание бизнес-правил, на соответствие которым могут быть проверены объекты. Композитный класс спецификация имеет один метод, называемый isSatisfiedBy, который возвращает истину или ложь в зависимости от того, удовлетворяет ли данный объект спецификации.
-* Пример: https://github.com/deuterium7/specification-test
+* Пример: https://github.com/deuterium7/specification-test
+#### Состояние (State)
+* Используется в тех случаях, когда во время выполнения программы объект должен менять своё поведение в зависимости от своего состояния.
+* Аналогия: Допустим, в графическом редакторе вы выбрали инструмент «Кисть». Она меняет своё поведение в зависимости от настройки цвета: т.е. рисует линию выбранного цвета.
+* Шаблон «Состояние» реализует машину состояний объектно ориентированным способом. Это достигается с помощью:
+1. Реализации каждого состояния в виде производного класса интерфейса шаблона «Состояние»,
+2. Реализации переходов состояний (state transitions) посредством вызова методов, определённых вышестоящим классом (superclass).
+* Шаблон «Состояние» — это в некотором плане шаблон «Стратегия», при котором возможно переключение текущей стратегии с помощью вызова методов, определённых в интерфейсе шаблона.
+* Пример: https://github.com/deuterium7/state-test
diff --git a/test_app.md b/test_app.md
@@ -424,4 +424,8 @@ class DI
 * В шаблоне «Наблюдатель» есть объект («субъект»), ведущий список своих «подчинённых» («наблюдателей») и автоматически уведомляющий их о любом изменении своего состояния, обычно с помощью вызова одного из их методов.
 * Паттерн используется, чтобы сократить количество связанных напрямую объектов и вместо этого использует слабую связь (loose coupling).
 * Аналогия: Люди, ищущие работу, подписываются на публикации на сайтах вакансий и получают уведомления, когда появляются вакансии, подходящие по параметрам.
-* Пример: https://github.com/deuterium7/observer-test
+* Пример: https://github.com/deuterium7/observer-test
+#### Спецификация (Specification)
+* Шаблон проектирования, посредством которого представление правил бизнес логики может быть преобразовано в виде цепочки объектов, связанных операциями булевой логики.
+* Строит ясное описание бизнес-правил, на соответствие которым могут быть проверены объекты. Композитный класс спецификация имеет один метод, называемый isSatisfiedBy, который возвращает истину или ложь в зависимости от того, удовлетворяет ли данный объект спецификации.
+* Пример: https://github.com/deuterium7/specification-test
diff --git a/test_app.md b/test_app.md
@@ -418,4 +418,10 @@ class DI
 ```php
   $obj->callSomething();
 ```
-* Пример: https://github.com/deuterium7/null-object-test
+* Пример: https://github.com/deuterium7/null-object-test
+#### Наблюдатель (Observer)
+* Также известен как «подчинённые» (Dependents). Создает механизм у класса, который позволяет получать экземпляру объекта этого класса оповещения от других объектов об изменении их состояния, тем самым наблюдая за ними.
+* В шаблоне «Наблюдатель» есть объект («субъект»), ведущий список своих «подчинённых» («наблюдателей») и автоматически уведомляющий их о любом изменении своего состояния, обычно с помощью вызова одного из их методов.
+* Паттерн используется, чтобы сократить количество связанных напрямую объектов и вместо этого использует слабую связь (loose coupling).
+* Аналогия: Люди, ищущие работу, подписываются на публикации на сайтах вакансий и получают уведомления, когда появляются вакансии, подходящие по параметрам.
+* Пример: https://github.com/deuterium7/observer-test
diff --git a/test_app.md b/test_app.md
@@ -405,4 +405,17 @@ class DI
 * Поведенческий шаблон проектирования, позволяющий, не нарушая инкапсуляцию, зафиксировать и сохранить внутреннее состояние объекта так, чтобы позднее восстановить его в это состояние.
 * Классический вариант: Шаблон Хранитель используется двумя объектами: «Создателем» (originator) и «Опекуном» (caretaker). «Создатель» — это объект, у которого есть внутреннее состояние. Объект «Опекун» может производить некоторые действия с «Создателем», но при этом необходимо иметь возможность откатить изменения. Для этого «Опекун» запрашивает у «Создателя» объект «Хранителя». Затем выполняет запланированное действие (или последовательность действий). Для выполнения отката «Создателя» к состоянию, которое предшествовало изменениям, «Опекун» возвращает объект «Хранителя» его «Создателю». «Хранитель» является непрозрачным (то есть таким, который не может или не должен изменяться «Опекуном»).
 * Аналогия: В качестве примера можно привести калькулятор («создатель»), у которого любая последняя выполненная операция сохраняется в памяти («хранитель»), чтобы вы могли снова вызвать её с помощью каких-то кнопок («опекун»).
-* Пример: https://github.com/deuterium7/memento-test
+* Пример: https://github.com/deuterium7/memento-test
+#### Объект Null (Null Object)
+* Null Object — это объект с определенным нейтральным («null») поведением. Шаблон проектирования Null Object описывает использование таких объектов и их поведение (или отсутствие такового).
+* Методы, которые возвращают объект или Null, вместо этого должны вернуть объект NullObject. Это упрощённый формальный код, устраняющий необходимость проверки: 
+```php
+  if (!is_null($obj)) { 
+    $obj->callSomething();
+  }
+```
+заменяя её на обычный вызов:
+```php
+  $obj->callSomething();
+```
+* Пример: https://github.com/deuterium7/null-object-test
diff --git a/test_app.md b/test_app.md
@@ -394,6 +394,7 @@ class DI
 * Аналогия: Радиоприёмник. Вы начинаете с какой-то радиостанции, а затем перемещаетесь по станциям вперёд/назад. То есть устройство предоставляет интерфейс для итерирования по каналам.
 * Зачастую этот паттерн используется вместо массива объектов, чтобы не только предоставить доступ к элементам, но и наделить некоторой логикой. Это может быть ограничение доступа, сортировка или любая другая операция над множеством объектов.
 * Пример: https://github.com/deuterium7/iterator-test
+### 31.10.2017:
 #### Посредник (Mediator)
 * Обеспечивающий взаимодействие множества объектов, формируя при этом слабую связанность и избавляя объекты от необходимости явно ссылаться друг на друга.
 * Шаблон помогает уменьшить связанность (coupling) классов, общающихся друг с другом, ведь теперь они не должны знать о реализациях своих собеседников.

diff --git a/test_app.md b/test_app.md
@@ -399,4 +399,9 @@ class DI
 * Шаблон помогает уменьшить связанность (coupling) классов, общающихся друг с другом, ведь теперь они не должны знать о реализациях своих собеседников.
 * "Посредник" определяет интерфейс для обмена информацией с объектами "Коллеги", "Конкретный посредник" координирует действия объектов "Коллеги". Каждый класс "Коллеги" знает о своем объекте "Посредник", все "Коллеги" обмениваются информацией только с посредником, при его отсутствии им пришлось бы обмениваться информацией напрямую. "Коллеги" посылают запросы посреднику и получают запросы от него. "Посредник" реализует кооперативное поведение, пересылая каждый запрос одному или нескольким "Коллегам".
 * Аналогия: Когда вы говорите с кем-то по мобильнику, то между вами и собеседником находится мобильный оператор. То есть сигнал передаётся через него, а не напрямую. В данном примере оператор — посредник.
-* Пример: https://github.com/deuterium7/mediator-test
+* Пример: https://github.com/deuterium7/mediator-test
+#### Хранитель (Memento)
+* Поведенческий шаблон проектирования, позволяющий, не нарушая инкапсуляцию, зафиксировать и сохранить внутреннее состояние объекта так, чтобы позднее восстановить его в это состояние.
+* Классический вариант: Шаблон Хранитель используется двумя объектами: «Создателем» (originator) и «Опекуном» (caretaker). «Создатель» — это объект, у которого есть внутреннее состояние. Объект «Опекун» может производить некоторые действия с «Создателем», но при этом необходимо иметь возможность откатить изменения. Для этого «Опекун» запрашивает у «Создателя» объект «Хранителя». Затем выполняет запланированное действие (или последовательность действий). Для выполнения отката «Создателя» к состоянию, которое предшествовало изменениям, «Опекун» возвращает объект «Хранителя» его «Создателю». «Хранитель» является непрозрачным (то есть таким, который не может или не должен изменяться «Опекуном»).
+* Аналогия: В качестве примера можно привести калькулятор («создатель»), у которого любая последняя выполненная операция сохраняется в памяти («хранитель»), чтобы вы могли снова вызвать её с помощью каких-то кнопок («опекун»).
+* Пример: https://github.com/deuterium7/memento-test
diff --git a/test_app.md b/test_app.md
@@ -393,4 +393,10 @@ class DI
 * Используется для перемещения по контейнеру и обеспечения доступа к элементам контейнера.
 * Аналогия: Радиоприёмник. Вы начинаете с какой-то радиостанции, а затем перемещаетесь по станциям вперёд/назад. То есть устройство предоставляет интерфейс для итерирования по каналам.
 * Зачастую этот паттерн используется вместо массива объектов, чтобы не только предоставить доступ к элементам, но и наделить некоторой логикой. Это может быть ограничение доступа, сортировка или любая другая операция над множеством объектов.
-* Пример: https://github.com/deuterium7/iterator-test
+* Пример: https://github.com/deuterium7/iterator-test
+#### Посредник (Mediator)
+* Обеспечивающий взаимодействие множества объектов, формируя при этом слабую связанность и избавляя объекты от необходимости явно ссылаться друг на друга.
+* Шаблон помогает уменьшить связанность (coupling) классов, общающихся друг с другом, ведь теперь они не должны знать о реализациях своих собеседников.
+* "Посредник" определяет интерфейс для обмена информацией с объектами "Коллеги", "Конкретный посредник" координирует действия объектов "Коллеги". Каждый класс "Коллеги" знает о своем объекте "Посредник", все "Коллеги" обмениваются информацией только с посредником, при его отсутствии им пришлось бы обмениваться информацией напрямую. "Коллеги" посылают запросы посреднику и получают запросы от него. "Посредник" реализует кооперативное поведение, пересылая каждый запрос одному или нескольким "Коллегам".
+* Аналогия: Когда вы говорите с кем-то по мобильнику, то между вами и собеседником находится мобильный оператор. То есть сигнал передаётся через него, а не напрямую. В данном примере оператор — посредник.
+* Пример: https://github.com/deuterium7/mediator-test
diff --git a/test_app.md b/test_app.md
@@ -392,4 +392,5 @@ class DI
 #### Итератор (Iterator)
 * Используется для перемещения по контейнеру и обеспечения доступа к элементам контейнера.
 * Аналогия: Радиоприёмник. Вы начинаете с какой-то радиостанции, а затем перемещаетесь по станциям вперёд/назад. То есть устройство предоставляет интерфейс для итерирования по каналам.
+* Зачастую этот паттерн используется вместо массива объектов, чтобы не только предоставить доступ к элементам, но и наделить некоторой логикой. Это может быть ограничение доступа, сортировка или любая другая операция над множеством объектов.
 * Пример: https://github.com/deuterium7/iterator-test
diff --git a/test_app.md b/test_app.md
@@ -388,4 +388,8 @@ class DI
 * Объект используется для инкапсуляции всей информации, необходимой для выполнения действия либо для его инициирования позднее. Информация включает в себя имя метода; объект, владеющий методом; значения параметров метода.
 * Допустим, у нас есть объекты Invoker (Командир) и Receiver (Исполнитель). Этот паттерн использует реализацию интерфейса «Команда», чтобы вызвать некий метод Исполнителя используя для этого известный Командиру метод «execute()». Командир просто знает, что нужно вызвать метод “execute()”, для обработки команды клиента, не разбираясь в деталях реализации Исполнителя. Исполнитель отделен от Командира.
 * Вторым аспектом этого паттерна является метод undo(), который отменяет действие, выполняемое методом execute(). Команды также могут быть объединены в более общие команды с минимальным копированием-вставкой и полагаясь на композицию поверх наследования.
-* Пример: https://github.com/deuterium7/command-test
+* Пример: https://github.com/deuterium7/command-test
+#### Итератор (Iterator)
+* Используется для перемещения по контейнеру и обеспечения доступа к элементам контейнера.
+* Аналогия: Радиоприёмник. Вы начинаете с какой-то радиостанции, а затем перемещаетесь по станциям вперёд/назад. То есть устройство предоставляет интерфейс для итерирования по каналам.
+* Пример: https://github.com/deuterium7/iterator-test
diff --git a/test_app.md b/test_app.md
@@ -383,4 +383,9 @@ class DI
 #### Цепочка ответственности (Chain Of Responsibilities)
 * Содержит исходный управляющий объект и ряд обрабатывающих объектов. Каждый обрабатывающий объект содержит логику, определяющую типы командных объектов, которые он может обрабатывать, а остальные передаются по цепочке следующему обрабатывающему объекту.
 * Аналогия: Допустим, для вашего банковского счёта доступны три способа оплаты (A, B и C). Каждый подразумевает разные доступные суммы денег: A — 100 долларов, B — 300, C — 1000. Приоритетность способов при оплате: А, затем В, затем С. Вы пытаетесь купить что-то за 210 долларов. На основании «цепочки ответственности» система попытается оплатить способом А. Если денег хватает — то оплата проходит, а цепочка прерывается. Если денег не хватает — то система переходит к способу В, и т. д.
-* Пример: https://github.com/deuterium7/chain-of-responsibilities-test
+* Пример: https://github.com/deuterium7/chain-of-responsibilities-test
+#### Команда (Command)
+* Объект используется для инкапсуляции всей информации, необходимой для выполнения действия либо для его инициирования позднее. Информация включает в себя имя метода; объект, владеющий методом; значения параметров метода.
+* Допустим, у нас есть объекты Invoker (Командир) и Receiver (Исполнитель). Этот паттерн использует реализацию интерфейса «Команда», чтобы вызвать некий метод Исполнителя используя для этого известный Командиру метод «execute()». Командир просто знает, что нужно вызвать метод “execute()”, для обработки команды клиента, не разбираясь в деталях реализации Исполнителя. Исполнитель отделен от Командира.
+* Вторым аспектом этого паттерна является метод undo(), который отменяет действие, выполняемое методом execute(). Команды также могут быть объединены в более общие команды с минимальным копированием-вставкой и полагаясь на композицию поверх наследования.
+* Пример: https://github.com/deuterium7/command-test
diff --git a/test_app.md b/test_app.md
@@ -379,4 +379,8 @@ class DI
 * Необходим для создания глобального хранилища.
 * Подобно Одиночке, паттерн Registry вводит объект в глобальную область видимости, позволяя использовать его на любом уровне приложения.
 * Применять с осторожностью, т.к. вносит в приложение глобальное состояние, так что изменение в одном месте может повлиять на все остальные случаи использования.
-* Пример: https://github.com/deuterium7/registry-test
+* Пример: https://github.com/deuterium7/registry-test
+#### Цепочка ответственности (Chain Of Responsibilities)
+* Содержит исходный управляющий объект и ряд обрабатывающих объектов. Каждый обрабатывающий объект содержит логику, определяющую типы командных объектов, которые он может обрабатывать, а остальные передаются по цепочке следующему обрабатывающему объекту.
+* Аналогия: Допустим, для вашего банковского счёта доступны три способа оплаты (A, B и C). Каждый подразумевает разные доступные суммы денег: A — 100 долларов, B — 300, C — 1000. Приоритетность способов при оплате: А, затем В, затем С. Вы пытаетесь купить что-то за 210 долларов. На основании «цепочки ответственности» система попытается оплатить способом А. Если денег хватает — то оплата проходит, а цепочка прерывается. Если денег не хватает — то система переходит к способу В, и т. д.
+* Пример: https://github.com/deuterium7/chain-of-responsibilities-test
diff --git a/test_app.md b/test_app.md
@@ -343,7 +343,7 @@ class DI
 * «Компоновщик» описывает общий порядок обработки группы объектов, словно это одиночный экземпляр объекта.
 * Шаблон позволяет клиентам одинаково обращаться к отдельным объектам и к группам объектов.
 * Пример: https://github.com/deuterium7/composite-test
-#### Преобразователь данных (Data Mapper)
+#### Преобразователь данных (Data Mapper)*
 * Выступает в роли посредника для двунаправленной передачи данных между постоянным хранилищем данных и представления данных в памяти.
 * Схема: http://design-pattern.ru/i/data-mapper.gif
 * Пример: https://github.com/deuterium7/data-mapper-test
@@ -365,7 +365,7 @@ class DI
 * Способ реализации объектно-ориентированного API, нацеленный на повышение читабельности исходного кода программы.
 * Текучий интерфейс хорош тем, что упрощается множественный вызов методов одного объекта. Обычно это реализуется использованием цепочки методов, передающих контекст вызова следующему звену.
 * Пример: https://github.com/deuterium7/query-builder-test
-#### Приспособленей (Flyweight)
+#### Приспособленец (Flyweight)
 * «Приспособленец» — это объект, минимизирующий использование памяти за счёт общего с другими, такими же объектами использования как можно большего объёма данных.
 * Паттерн приспособленец позволяет повторно использовать мелкие объекты в различном контексте.
 * Для уменьшения использования памяти Приспособленец разделяет как можно больше памяти между аналогичными объектами. Это необходимо, когда используется большое количество объектов, состояние которых не сильно отличается.
@@ -375,7 +375,7 @@ class DI
 * «Заместитель» может просто переадресовывать запросы настоящему объекту, а может предоставлять дополнительную логику: кеширование данных при интенсивном выполнении операций или потреблении ресурсов настоящим объектом; проверка предварительных условий (preconditions) до вызова выполнения операций настоящим объектом.
 * Наиболее частым применением паттерна прокси является ленивая загрузка (lazy load). "Тяжелые" объекты не всегда разумно загружать в момент инициализации. Более правильным решением будет загрузить его по первому требованию.
 * Пример: https://github.com/deuterium7/proxy-test
-#### Реестр (Registry)
+#### Реестр (Registry)*
 * Необходим для создания глобального хранилища.
 * Подобно Одиночке, паттерн Registry вводит объект в глобальную область видимости, позволяя использовать его на любом уровне приложения.
 * Применять с осторожностью, т.к. вносит в приложение глобальное состояние, так что изменение в одном месте может повлиять на все остальные случаи использования.

diff --git a/test_app.md b/test_app.md
@@ -374,4 +374,9 @@ class DI
 * Это оболочка или объект-агент, вызываемый клиентом для получения доступа к другому, «настоящему» объекту. 
 * «Заместитель» может просто переадресовывать запросы настоящему объекту, а может предоставлять дополнительную логику: кеширование данных при интенсивном выполнении операций или потреблении ресурсов настоящим объектом; проверка предварительных условий (preconditions) до вызова выполнения операций настоящим объектом.
 * Наиболее частым применением паттерна прокси является ленивая загрузка (lazy load). "Тяжелые" объекты не всегда разумно загружать в момент инициализации. Более правильным решением будет загрузить его по первому требованию.
-* Пример: https://github.com/deuterium7/proxy-test
+* Пример: https://github.com/deuterium7/proxy-test
+#### Реестр (Registry)
+* Необходим для создания глобального хранилища.
+* Подобно Одиночке, паттерн Registry вводит объект в глобальную область видимости, позволяя использовать его на любом уровне приложения.
+* Применять с осторожностью, т.к. вносит в приложение глобальное состояние, так что изменение в одном месте может повлиять на все остальные случаи использования.
+* Пример: https://github.com/deuterium7/registry-test
diff --git a/test_app.md b/test_app.md
@@ -369,4 +369,9 @@ class DI
 * «Приспособленец» — это объект, минимизирующий использование памяти за счёт общего с другими, такими же объектами использования как можно большего объёма данных.
 * Паттерн приспособленец позволяет повторно использовать мелкие объекты в различном контексте.
 * Для уменьшения использования памяти Приспособленец разделяет как можно больше памяти между аналогичными объектами. Это необходимо, когда используется большое количество объектов, состояние которых не сильно отличается.
-* Пример: https://github.com/deuterium7/flyweight-test
+* Пример: https://github.com/deuterium7/flyweight-test
+#### Заместитель (Proxy)
+* Это оболочка или объект-агент, вызываемый клиентом для получения доступа к другому, «настоящему» объекту. 
+* «Заместитель» может просто переадресовывать запросы настоящему объекту, а может предоставлять дополнительную логику: кеширование данных при интенсивном выполнении операций или потреблении ресурсов настоящим объектом; проверка предварительных условий (preconditions) до вызова выполнения операций настоящим объектом.
+* Наиболее частым применением паттерна прокси является ленивая загрузка (lazy load). "Тяжелые" объекты не всегда разумно загружать в момент инициализации. Более правильным решением будет загрузить его по первому требованию.
+* Пример: https://github.com/deuterium7/proxy-test
diff --git a/test_app.md b/test_app.md
@@ -366,3 +366,7 @@ class DI
 * Текучий интерфейс хорош тем, что упрощается множественный вызов методов одного объекта. Обычно это реализуется использованием цепочки методов, передающих контекст вызова следующему звену.
 * Пример: https://github.com/deuterium7/query-builder-test
 #### Приспособленей (Flyweight)
+* «Приспособленец» — это объект, минимизирующий использование памяти за счёт общего с другими, такими же объектами использования как можно большего объёма данных.
+* Паттерн приспособленец позволяет повторно использовать мелкие объекты в различном контексте.
+* Для уменьшения использования памяти Приспособленец разделяет как можно больше памяти между аналогичными объектами. Это необходимо, когда используется большое количество объектов, состояние которых не сильно отличается.
+* Пример: https://github.com/deuterium7/flyweight-test
diff --git a/test_app.md b/test_app.md
@@ -360,4 +360,9 @@ class DI
 * Объект, предоставляющий упрощённый интерфейс для более крупного тела кода, например библиотеки классов.
 * Разбиение на подсистемы сложной системы позволяет упростить процесс проектирования, а также помогает максимально снизить зависимости одной подсистемы от другой. Однако это приводит к тому, что использовать такие подсистемы вместе становиться довольно сложно. Один из способов решения этой проблемы является ввод паттерна фасад.
 * Главная цель шаблона состоит в уменьшении связности кода и соблюдении Закона Деметры.
-* Пример: https://github.com/deuterium7/facade-test
+* Пример: https://github.com/deuterium7/facade-test
+#### Текучий Интерфейс (Fluent Interface)
+* Способ реализации объектно-ориентированного API, нацеленный на повышение читабельности исходного кода программы.
+* Текучий интерфейс хорош тем, что упрощается множественный вызов методов одного объекта. Обычно это реализуется использованием цепочки методов, передающих контекст вызова следующему звену.
+* Пример: https://github.com/deuterium7/query-builder-test
+#### Приспособленей (Flyweight)
diff --git a/test_app.md b/test_app.md
@@ -355,4 +355,9 @@ class DI
 * Процесс предоставления внешней зависимости программному компоненту.
 * В полном соответствии с принципом единственной ответственности объект отдаёт заботу о построении требуемых ему зависимостей внешнему, специально предназначенному для этого общему механизму.
 * Необходим для реализации слабосвязанной архитектуры. Чтобы получить более тестируемый, сопровождаемый и расширяемый код.
-* Пример: https://github.com/deuterium7/dependency-injection-test
+* Пример: https://github.com/deuterium7/dependency-injection-test
+#### Фасад (Facade)
+* Объект, предоставляющий упрощённый интерфейс для более крупного тела кода, например библиотеки классов.
+* Разбиение на подсистемы сложной системы позволяет упростить процесс проектирования, а также помогает максимально снизить зависимости одной подсистемы от другой. Однако это приводит к тому, что использовать такие подсистемы вместе становиться довольно сложно. Один из способов решения этой проблемы является ввод паттерна фасад.
+* Главная цель шаблона состоит в уменьшении связности кода и соблюдении Закона Деметры.
+* Пример: https://github.com/deuterium7/facade-test
diff --git a/test_app.md b/test_app.md
@@ -349,4 +349,10 @@ class DI
 * Пример: https://github.com/deuterium7/data-mapper-test
 #### Декоратор (Decorator)
 * Позволяет подключать к объекту дополнительное поведение (статически или динамически), не влияя на поведение других объектов того же класса.
-* Пример: https://github.com/deuterium7/decorator-test
+* Пример: https://github.com/deuterium7/decorator-test
+### 30.10.2017:
+#### Внедрение зависимостей (Dependency Injection)
+* Процесс предоставления внешней зависимости программному компоненту.
+* В полном соответствии с принципом единственной ответственности объект отдаёт заботу о построении требуемых ему зависимостей внешнему, специально предназначенному для этого общему механизму.
+* Необходим для реализации слабосвязанной архитектуры. Чтобы получить более тестируемый, сопровождаемый и расширяемый код.
+* Пример: https://github.com/deuterium7/dependency-injection-test
diff --git a/test_app.md b/test_app.md
@@ -346,4 +346,7 @@ class DI
 #### Преобразователь данных (Data Mapper)
 * Выступает в роли посредника для двунаправленной передачи данных между постоянным хранилищем данных и представления данных в памяти.
 * Схема: http://design-pattern.ru/i/data-mapper.gif
-* Пример: https://github.com/deuterium7/data-mapper-test
+* Пример: https://github.com/deuterium7/data-mapper-test
+#### Декоратор (Decorator)
+* Позволяет подключать к объекту дополнительное поведение (статически или динамически), не влияя на поведение других объектов того же класса.
+* Пример: https://github.com/deuterium7/decorator-test
diff --git a/test_app.md b/test_app.md
@@ -342,4 +342,8 @@ class DI
 #### Компоновщик (Composite)
 * «Компоновщик» описывает общий порядок обработки группы объектов, словно это одиночный экземпляр объекта.
 * Шаблон позволяет клиентам одинаково обращаться к отдельным объектам и к группам объектов.
-* Пример: https://github.com/deuterium7/composite-test
+* Пример: https://github.com/deuterium7/composite-test
+#### Преобразователь данных (Data Mapper)
+* Выступает в роли посредника для двунаправленной передачи данных между постоянным хранилищем данных и представления данных в памяти.
+* Схема: http://design-pattern.ru/i/data-mapper.gif
+* Пример: https://github.com/deuterium7/data-mapper-test
diff --git a/test_app.md b/test_app.md
@@ -338,4 +338,8 @@ class DI
 #### Мост (Bridge)
 * Означает отделение абстракции от реализации, чтобы их обе можно было изменять независимо друг от друга.
 * Реализация web-страниц с паттерном и без: https://hsto.org/files/693/d31/e70/693d31e709f249bfab95520c182af6d6.jpg
-* Пример: https://github.com/deuterium7/bridge-test
+* Пример: https://github.com/deuterium7/bridge-test
+#### Компоновщик (Composite)
+* «Компоновщик» описывает общий порядок обработки группы объектов, словно это одиночный экземпляр объекта.
+* Шаблон позволяет клиентам одинаково обращаться к отдельным объектам и к группам объектов.
+* Пример: https://github.com/deuterium7/composite-test
diff --git a/test_app.md b/test_app.md
@@ -334,4 +334,8 @@ class DI
 #### Адаптер (Adapter)
 * Позволяет использовать интерфейс существующего класса как другой интерфейс.
 * Часто применяется для обеспечения работы одних классов с другими без изменения их исходного кода.
-* Пример: https://github.com/deuterium7/adapter-test
+* Пример: https://github.com/deuterium7/adapter-test
+#### Мост (Bridge)
+* Означает отделение абстракции от реализации, чтобы их обе можно было изменять независимо друг от друга.
+* Реализация web-страниц с паттерном и без: https://hsto.org/files/693/d31/e70/693d31e709f249bfab95520c182af6d6.jpg
+* Пример: https://github.com/deuterium7/bridge-test
diff --git a/test_app.md b/test_app.md
@@ -330,4 +330,8 @@ class DI
 * Используется для создания ряда связанных или зависимых объектов.
 * Разница между этим шаблоном и Абстрактной Фабрикой заключается в том, что Статическая Фабрика использует только один статический метод, чтобы создать все допустимые типы объектов.
 * Этот метод, обычно, называется factory или build.
-* Пример: https://github.com/deuterium7/static-factory-test
+* Пример: https://github.com/deuterium7/static-factory-test
+#### Адаптер (Adapter)
+* Позволяет использовать интерфейс существующего класса как другой интерфейс.
+* Часто применяется для обеспечения работы одних классов с другими без изменения их исходного кода.
+* Пример: https://github.com/deuterium7/adapter-test
No results found