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

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

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

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

Поведенческий шаблон Наблюдатель реализует механизм, с момощью которого один класс может уведомлять другие о своём изменении. Практическая реализация кода может быть разной, но в PHP уже существуют готовые стандартные интерфейсы SplSubject, SplObjectStorage и SplObserver, на которых и принято реализовывать паттерн Observer.

Стоит отметить, что сам по себе этот шаблон родом из «больших» языков. Я уже рассказывал о его реализации для Java, где класс Модели отправляет уведомления о своём изменении всем своим «слушателям».

Я уже рассказывал, что в свободное время занимаюсь своим микрофреймворком и хочу поделиться некоторыми мыслями по этому поводу. Речь пойдёт о представлениях (view) в концепции MVC, точнее о том, что они на самом деле представляют.

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

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

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

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

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