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

Исходный код Адаптера вы можете посмотреть на гитхабе.

Кратко опишу что в нём происходит. Есть два совершенно разных класса. Но при этом, мы хотим привести их к некоему одному типу/поведению в рамках своего проекта. В данном случае это интерфейс AdapterInterface. Дальше делаются классы, реализующие этот интерфейс: AdapterA и AdapterB.

Метод commonMethod()является обязательным, и в нём мы уже подключаем существующие методы классов ClassA и ClassB. Такой подход позволяет использовать в приложении совершенно разные классы с нужным интерфейсом.

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

Пример кода вы можете посмотреть на гитхабе. Рассмотрим его работу.

Читать дальше...

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

Смысл Строителя в том, чтобы иметь возможность получить конечный результат в различном виде. Например есть некий «Продукт», который может быть получен разными «Строителями» (один делает одно, другой другое). И есть класс, который управляет строителями — «Директор».

Исходный рабочий код, вы всё также найдёте на гитхабе. Рекомендую вначале с ним бегло ознакомиться и держать под рукой по мере объяснений ниже. :-)

Читать дальше...

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

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

Читать дальше...

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

Следует отметить, что этот паттерн имеет множество реализаций. Я покажу свой вариант, основанный на использовании Multiton. Смысл в том, что Registry может хранить разные данные и для того, чтобы гарантировать единый доступ, следует использовать Singleton. Но, с практической точки зрения, данные в Registry могут иметь разные типы/группировку. Например конфигурация приложения может содержать параметры доступа к MySQL, Sqlite, ключ шифрования, параметры роутинга и т.п. Именно с помощью Мультитона мы можем указать «группу» настроек, чтобы они не смешивались между собой: general, database, route и т.п.

Читать дальше...

Multiton (Пул одиночек) — представляет собой развитие шаблона Singleton, где вместо единственного экземпляра можно создать и использовать множество. С практической точки зрения мультитон может использоваться для создания однотипных классов, которые не должны между собой пересекаться. Самый простой пример — работа с несколькими конфигурациями, где каждый класс мультитона хранит какой-то свой набор данных.

Читать дальше...

Singleton (Одиночка) наверное самый известный в PHP паттерн. Я уже как-то писал о нём, но сейчас речь пойдёт уже с точки зрения ООП и практического использования.

Синглтон очень часто называют антипаттерном, который выражается в «неуместном использовании». На самом деле это действительно так: из-за своей простоты Singleton очень часто применяют там, где в общем-то он и не нужен.

Основное назначение Singleton в том, чтобы гарантировать только один экземпляр класса. ООП в PHP 5 был не так развит и ещё не было автозагрузки файлов, синглтон был оправдан для создания глобального объекта всего приложения, как например в CodeIgniter — $CI. Этот объект обслуживает все подключения файлов, библиотеки и т.п. Всё это создаёт очень жесткую структуру.

Читать дальше...