Отвечают за построение удобных в поддержке иерархий классов. ### Декоратор Также известен как: Wrapper, Обертка, Decorator Позволяет расширять функциональность типа без непосредственного изменения кода самого типа. Другими словами, позволяет оборачивать в полезные «обертки» Построен на принципе замены наследования на агрегацию или композицию. Декоратор и тип, который оборачивают, имеют общий интерфейс. Обертывание Декораторов контролируется клиентом [ссылка](https://refactoring.guru/ru/design-patterns/decorator) ### Адаптер Также известен как: Wrapper, Обёртка, Adapter Позволяет типам с несовместимыми интерфейсами работать вместе, предоставляя альтернативный интерфейс. Например, мы хотим использовать библиотеку, но она принимает данные только в виде XML, а нам удобнее работать с JSON. Для решения данной проблемы создается адаптер. Он переделывает интерфейс так, чтобы он стал для нас подходящим. Аналогия из жизни. В разных странах стандарты розеток отличаются. Для совместимости путешественники используют переходник (адаптер) Разница между **адаптером** и **декоратором** - **Адаптер** предоставляет альтернативный интерфейс существующего типа - **Декоратор** улучшает другой тип без изменения его интерфейса. [ссылка](https://refactoring.guru/ru/design-patterns/adapter) ### Мост Также известен как: Bridge Разделяет один или несколько типов на две отдельные иерархии - абстракцию и реализацию. Это позволяет изменять их независимо друг от друга. Две иерархии будут связаны между собой композицией или агрегацией. [ссылка](https://refactoring.guru/ru/design-patterns/bridge) ### Компоновщик Также известен как: Дерево, Composite Позволяет сгруппировать множество типов в древовидную структуру, а затем работать с ней так, как будто это единичный тип. У всех типов единый интерфейс. То есть у самого большого в иерархии типа и самого маленького - один и тот же интерфейс. Например, если нам нужно что-то получить от единого типа, то он просто циклом прокрутит каждый тип и получит от них всех результат засуммирует и вернет. [ссылка](https://refactoring.guru/ru/design-patterns/composite) ### Фасад Также известен как: Facade. Предоставляет простой интерфейс к сложной системе классов, библиотеке или фреймворку. Например, вместо того, чтобы напрямую из клиентского кода обращаться к сложной системе классов, можно сделать «обертку», которая позволит выполнить нужную задачу в один метод. А сам метод будет уже работать со сложной системой классов. Различия между **фасадом** и **адаптером** - **Фасад** задает новый интерфейс и оборачивает целую подсистему - **Адаптер** повторно использует старый интерфейс и оборачивает только один тип (класс). [ссылка](https://refactoring.guru/ru/design-patterns/facade) ### Легковес Также известен как: Приспособленец, Кэш, Flyweight Позволяет экономить оперативную память. Выносит общее состояние (хранимую информацию) между экземплярами в отдельный код, вместо хранения одинаковых данных в каждом экземпляре Если у нас есть массив экземпляров, у которых есть поле с повторяющейся информацией, то нужно вынести его во вне и хранить единичном экземпляре. Это очень сильно экономит оперативную память. [ссылка](https://refactoring.guru/ru/design-patterns/flyweight) ### Заместитель Также известен как: Proxy Позволяет подставлять вместо реальных типов специальные типы-заменители. Они перехватывают вызовы к оригинальному типу, позволяя сделать что-то до или после передачи вызова оригиналу. **Свойства заместителя** - Имеет с оригинальным типом общий интерфейс. - Сам управляет жизнью оригинальным типом. **Применимость** - Загрузка оригинального типа только тогда, когда будет непосредственно вызов какого-либо свойства/метода - Логирование запросов - Кеширование - Локальный запуск типа-заменителя, когда оригинальный находится на удаленном сервере [ссылка](https://refactoring.guru/ru/design-patterns/proxy)