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

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

Утилитарные классы используются в любом css-фреймворке. С их помощью решаются какие-то типовые задачи верстки, например задаются отступы или размер шрифта. Каждый фреймворк использует свои утилитарные классы, которые именуются не всегда очевидным образом.

Например в Bootstrap 4 есть такие классы:

.py-5, .pt-2, .p-5, .m-5, .my-1, .m-1, .m-n1, .text-reset

Понять их назначение невозможно без обращения к документации.

.p-5 {padding: 3rem !important;}
.m-n1 {margin: -0.25rem !important;}
.m-1 { margin: 0.25rem !important; }
.text-reset {color: inherit !important;}

Во некоторых случаях css-классы меняют свое поведение. Например в UiKit 3 есть классы .uk-padding, который задает padding: 30px;, но при @media (min-width: 1200px)становится уже 40px.

Проблемы бывают и более глобального уровня. Например в Bootstrap 4 было принято решение, что для всех компонентов и многих элементов используется нулевой верхний отступ (margin-top:0), а отступы между элементами следует делать с помощью нижнего отступа. Это глобальное поведение, которое сложно изменить. Но что делать, если нужно состыковать два блока непосредственно друг к другу или задать какой-то другой вариант, не предусмотренный во фреймворке?

Библиотека Berry как раз и призвана решать эти проблемы.

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

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

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

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

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

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