Decorator pattern

Не подумайте, меня не покусал Егор Бугаенко (для тех кто в теме, кто нет — погуглите), мои взгляды не настолько радикальны, однако я действительно считаю, что этому паттерну уделяют мало внимания. Потому решил познакомить с ним тех, кто не знаком и освежить в памяти для тех, кто уже давно им пользуется.

Декоратор — (wiki) структурный шаблон проектирования, предназначенный для динамического подключения дополнительного поведения к объекту.

👉 Если простым языком, то суть данного паттерна заключается в "оборачивании" существующего объекта новым функционалом, при этом оригинальный интерфейс объекта остается неизменным. В данном примере WrapperObject и есть наш декоратор.

❓ В чем преимущества?

1. Его не получится просто так создать без существования базового класса.
2. Так как базовый класс и класс обертка имплементируют один интерфейс — то они взаимозаменяемы.
3. Мы расширяем поведение без изменения исходного кода.

Стоп, да это же прям Open-Closed Principle! И да, это отличная альтернатива наследованию. Также вы можете использовать несколько разных обёрток одновременно.

❗️ Да, клиентский код выглядит не круто, да и искать все места где вызывается базовый класс, чтобы прицепить обёртку бывает проблематично (особенно в долгоживущих проектах). Однако в фреймворках этот вопрос легко решается. Например в Symfony достаточно добавить всего несколько строк:

Представим, что у нас есть какой-то Mailer, который мы описали в services.yaml и теперь мы хотим логировать отправку всей почты. Для этого у контейнера есть директива decorates. Подобная запись подменит основной mailer на mailer_logger и наши письма начнут начнут логироваться. Для ссылки на исходный класс нужно использовать decorating_service_id + .inner (или просто '@.inner' начиная с Symfony 5.1).

👍 Но что если мы хотим не только логировать, но и отправлять наши письма через очередь? Нет проблем, мы можем добавить еще одну запись. Но как задать порядок в котором будут вызваны декораторы? Для этого существует директива decoration_priority (по умолчанию 0). Соответственно чем выше приоритет — тем раньше применится декоратор (всё логично). Например такой код сначала залогирует (1), а потом уже отправит в очередь (2) наше сообщение:

$this->services['mailer'] = new LoggerDecorator(new QueueDecorator(new Mailler()));

#php #oop #patterns #middle

Всеобъемлющее руководство по паттернам проектирования в JavaScript

В этой статье мы рассмотрим шаблоны JavaScript и узнаем, как они могут улучшить вашу практику разработки.

👉 https://dev.to/topefasasi/js-design-patterns-a-comprehensive-guide-h3m

#javascript #patterns

🕹 Злой полицейский — Подписаться

Паттерн Aggregate Outside

Руслан Гнатовский в своей статье "Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя" описал известную проблему протекания бизнес-логики из агрегата, в случае если эта логика зависит от данных которые находятся вне агрегата, и предложил несколько решений этой проблемы, каждое из которых не лишено недостатков. Многие из этих недостатков были описаны в статье, а также в комментариях, поэтому я не буду здесь дублировать эту информацию а попытаюсь предложить решение, которое этих недостатков лишено.

👉🏻 https://habr.com/ru/articles/799019/

#php #oop #patterns

🕹 Злой полицейский — Подписаться

Паттерн "Спецификация": реальный опыт применения

Четыре года назад на собеседовании я услышал от интервьюера о том, как замечательно паттерн Спецификация помогает справиться с проблемой разрастания репозитория. Я думаю, многие с этим сталкивались, когда количество методов типа getByThisAndThat(…) улетает за десяток, а то и за несколько десятков, и репозиторием становится пользоваться неудобно.

Вдохновившись таким позитивным отзывом, я изучил первоисточник и начал экспериментировать с использованием спецификации как со средством упрощения репозитория.

👉 https://habr.com/ru/articles/929848/

#patterns #development

👮‍♂️ Злой полицейский

💡Эргономичная архитектура

В своей книге The Problem with Software: Why Smart Engineers Write Bad Code Адам Барр пишет, что вопреки тому, что деятельность по разработке ПО часто называют "software engineering", а людей, которые разрабатывают ПО - "software engineer", на самом деле эта деятельность инженерной не является.

Потому что все - и научное сообщество, и коммерческие компании, и сами разработчики отказались от научного подхода к поиску наилучших способов разработки ПО. В результате, буквально все рекомендации, методологии и прочие руководства по разработке ПО основаны на личном опыте их авторов, а не на научно доказанных законах (вроде закона всемирного тяготения) или хотя бы статистически достоверных свидетельствах того, что применение той или иной рекомендации коррелирует с улучшением той или иной характеристики ПО.

Например, глядя на Чистую архитектуру, можно предположить, что у Роберта Мартина был негативный опыт, вызванный добавлением новых инфраструктурных компонентов в систему. И ответом на этот опыт стал принцип инверсии зависимостей в частности и Чистая архитектура в общем.

А мой негативный опыт был связан с отсутствием структуры в кодовой базе. Ответом на мой опыт стала Эргономичная архитектура.

👉 https://ergowiki.azhidkov.pro/docs/models/ergo-arch/

#patterns #arch

👮‍♂️ Злой полицейский

Архитектурный шаблон
Porto

Porto это современный архитектурный шаблон программного обеспечения, состоящий из методических рекомендаций, принципов и шаблонов, которые помогают разработчикам организовать свой код максимально удобным и многократно используемым способом.

Porto - отличный вариант для средних и крупных веб-проектов, поскольку со временем они, как правило, становятся более сложными.

👉️ https://github.com/dnsoftware/porto_ru

#arch #php #patterns #porto

👮‍♂️ Злой полицейский

Паттерн "Обработчик" (Handler) с использованием DTO и VO

- Изоляция бизнес-логики: Бизнес-логика изолирована в обработчиках, что позволяет сделать код более организованным и легко поддерживаемым.
- Тестируемость: Обработчики легко тестируются отдельно, так как они не зависят от инфраструктурного кода (например, контроллеров).
- Переиспользование: Обработчики могут быть легко переиспользованы в различных частях приложения.
- Ясность и читаемость кода: Использование DTO и VO позволяет четко определить структуру передаваемых данных, что улучшает читаемость и понимание кода.
- Соблюдение принципов SOLID: Обработчики помогают соблюдать принципы единственной ответственности (SRP) и разделения интерфейсов (ISP).
- Иммутабельность VO: Значения VO не изменяются после создания, что помогает избежать непреднамеренных изменений и улучшает предсказуемость кода.

👉 https://laravel.su/p/primer-ispolzovaniia-patterna-obrabotcik-handler-s-ispolzovaniem-dto-i-vo

#laravel #patterns #dto #handlers

👮‍♂️ Злой полицейский