JavaOpt: Паттерны

Основные

SOLID
S - Single Responsibility Principle - интерфейсы, классы и методы должны выполнять только 1 задачу и делать это хорошо!
O - Open-Close Principle - методы, классы и интерфейсы должны быть открыты для расширения, но не для изменения. В особенности это касается публичных библиотек с множеством внешних зависимостей
L - Liskov Substitution Principle - принцип в основе которого лежит заменимость родительского класса любым его наследником. Иными словами, там где возможно, следует использовать максимально базовую абстракцию
I - Interface Segregfation Principle - принцип согласно которому интерфейсы следует разбивать на множество мелких, с более узконаправленными функциями. Реализация будет зависеть уже от класса.
D - Dependency Invertion Principle - классы не должны зависеть от конкретных реализаций, только от абстракций. Так, вставка (передача) в класс зависимостей должна представлять собой только абстракции
DRY - Don’t Repeat Yourself - следует избегать дублирования кода
KISS - Keep It Simple, Stupid - написание кода должно быть максимально просты, чтобы понимание было интуитивным
TDD - Test-Driven Development - принцип разработки, при котором наложение тестов идет несколько опережающими темпами относительно реализации задачи.
ACID - паттерн баз данных
A - Atomicity - гарантирует, что никакая транзакция не будет зафиксирована в системе частично - либо все, либо ничего;
C - Consistency - каждая успешная транзакция по определению фиксирует только допустимые результаты;
I - Isolation - Во время выполнения транзакции, параллельные транзакции не должны оказывать влияния на её результат;
D - Durability - если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.

12 Factor app

Codebase. В VCS должно лежать все что так или иначе связано с приложением (чтобы оно заработало). К нему должны иметь доступ все заинтересованные лица + CI/CD
Depencencies. Хранение артефактов в VCS запрещено. В контроле версий должно лежать только уникальная и необходимая для проекта база
Configurations. Параметры приложения следует выносить из кода в переменные окружения или конфигурационные файлы
Backing Services. Внешние для приложения сервисы должны быть отделены от него и максимально абстрагированы. Поддержку предпочтительнее переносить на другую команду (речь про БД, почтовые сервисы, стриминговые сервисы и прочие)
Build, Release, Run. Принцип, согласно которому приложение каждый раз собирается, поставляется и запускается “с нуля”.
Process. Процессы в рамках приложения должны быть атомарны с наименьшим количеством взаимозависимостей. Например, с 1 внешним ресурсом работает 1 сервис и он же выполняет все необходимые действия, предоставляя сервис
Port Binding. Каждому сервису выделяется отдельный сетевой порт, который дополнительно идентифицирует сервис
Concurrency. Сервис в рамках приложения должен быть легко масштабируемым как в сторону увеличения, так и в сторону уменьшения
Disposability. Приложение/сервис сам должен следить за корректностью старта. Если он получил статус успешно запущенного - это значит лишь одно - он гарантированно работает на 100%
Dev/Prod Parity. Окружение/контура работы (dev и prod) должны быть идентичными. Допускаются минорные различия и различия в масштабировании
Logs. Логи должны быть максимально разбиты и сгруппированы по целевым группам их читателей (например, только логи с ошибками, только HTTP запрос/ответ, только работа с БД и т.д.)
Admin Process. Ключевые участки работы всего приложения носят максимальный приоритет (даже если зависят от внешних ресурсов и сервисов). Их всегда следует рассматривать как ключевой элемент системы!

Основные

Delegation - передает выполнение на сторону;
Functional Design - функциональный интерфейс. Сигнализирует, что класс объявляет только 1 публичный метод;
Interface - абстракция, без конкретной реализации, но объявляющая контракт для работы с наследуемыми объектами;
Marker Interface - маркировочный интерфейс, не выполняет никаких действий, но служит для маркировки наследников;
Immutable Interface - с помощью интерфейса маркируется класс, гарантируя его immutable природу;
Event Channel - паттерн, указывающий на взаимодействие между компонентами посредством подписки одного на события другого.

Проектирование

Adapter - взаимодействие между двумя и более несовместимыми компонентами осуществляются через сторонний компонент (Adapter);
Bridge - обеспечивает работу между потенциально изменяемыми компонентами посредством абстракции, позволяя им взаимодействовать без рисков;
Composite - объединяет несколько компонентов в 1 (не реализуя все заново, а делегируя (Delegation) исполнение), через который и выполняется все взаимодействие;
Decorator - оборачивает базовый компонент в обертки (надстройки), добавляя или расширяя функционал;
Facade - внешняя точка входа для взаимодействия с компонентами;
Proxy - предоставляет компонент, который контролирует доступ, перехватывая вызовы базового компонента (может добавлять, заменять или предотвращать вызов работы базового компонента).

Порождающие

Abstract Factory - фабрика по производству объектов. Предоставляет доступ к различным реализациям на внутренней логики;
Factory Method - метод, который является частью Abstract Factory и фактически создает объект;
Builder - конструктор, который позволяет конфигурировать создаваемый объект;
Prototype - позволяет копировать создавать копии компонента с одинаковыми начальными конфигурациями (как продукт на заводе);
Singleton - гарантирует наличие одного (и только одного!) активного экземпляра объекта.

Поведенческие

Chain of Responsibility - указывает на наличие действий, выполняемых по цепочкам;
Command - оборачивает запрос на выполнение какого-то действия над объектом в надстройку с конфигурацией для выполнения этого действия;
Interpreter - паттерн настраиваемого интерпретатора тех или иных данных (будь то параметры, или текст), который определяет как анализировать и действовать с данными;
Iterator - паттерн для итерирования наборов данных;
Mediator - посредник, связывающий несколько компонентов между собой (2 и более) и пропускающий все команды и данные через себя;
Memento - снимок, который хранит историю объектов (фактически, snapshot объектов/данных);
Observer - является участником общего паттерна Event Channel - наблюдатель, который подписывается на события другого компонента и следит за ними;
State - паттерн, указывающий на наличие у объекта нескольких состояний (статусов);
Strategy - указывает на объединение нескольких алгоритмов в одном объекте;
Template Method - является частью Strategy, делегирует (Delegation) реализацию методов на зависимые компоненты (например, на подклассы). Зависимые компоненты не меняют базовые методы в Strategy;
Visitor - надстройка, которая дополняет компоненты, не меняя их стандартного (ожидаемого) поведения. Является дочерним паттерном к Proxy.

АНТИПАТТЕРНЫ

Abstraction Inversion - излишнее сокрытие доступов и ограничение безопасности;
Ambiguous Viewpoint - антипаттерн, который указывает на неопределенность назначения компонента (например, он может совмещать несколько несвязанных между собой функционала, или его описание просто не соответствовать его действиям, пусть они и будут выполняться корректно);
Big Ball Of Mud - никто ничего не понял;
God Object - объединение огромного количества действий в одном компоненте;
Interface Bloat - чрезмерное усложнение абстракции (она требует выполнения слишком большого количества действий);
Introduced Complexity - излишнее усложнение примитивной задачи;
Magic Pushbutton - как правило, встречается в UI компонентах, когда одной большой красной кнопкой выполняется все и сразу;
Re-Coupling - внедрение ненужной зависимости;
Stovepipe System - сборка плохо связанных компонентов (связи не только не очевидные, но и чрезмерно хрупкие);
Race Hazard - антипаттерн конкурентного программирования;
Mutilation - чрезмерное «ориентирование» компонентов на одну, очень узкую задачу;
Save or Die - сохранение изменений только при «смерти» компонента.