$1$ Singleton
- Цель: обеспечить наличие ровно одного экземпляра класса и глобальную точку доступа к нему.
- Структура: приватный конструктор, статический метод/поле для получения экземпляра, ленивый или жёсткий (eager) инициализатор.
- Когда использовать: нужен один общий ресурс/контекст (логгер, конфиг, соединение к БД, менеджер настроек).
- Минусы: затрудняет тестирование, может превратиться в глобальную переменную; осторожно с многопоточностью.
- Пример проекта: централизованный менеджер конфигурации в учебной системе тестирования — единый объект хранит настройки тестов и путь к БД.
$2$ Factory (Factory Method / Simple Factory)
- Цель: инкапсулировать создание объектов, отделить код, который использует объект, от деталей его создания.
- Структура: фабричный метод или класс, возвращающий интерфейс/абстракцию, конкретные подклассы создаются внутри фабрики.
- Когда использовать: выбор конкретной реализации в рантайме по параметрам, нужна простая замена классов без изменения клиента.
- Минусы: может привести к множеству фабрик при чрезмерном использовании.
- Пример проекта: генератор заданий в системе — фабрика создаёт разные типы вопросов (множественный выбор, ввод числа, сопоставление) по метаданным задания.
$3$ Observer (Наблюдатель)
- Цель: реализовать реакцию множества зависимых объектов на изменения состояния субъекта, слабое связывание издателя и подписчиков.
- Структура: субъект с регистрацией/удалением наблюдателей и методом уведомления; наблюдатели реализуют интерфейс обновления.
- Когда использовать: нужно оповестить разные компоненты об изменении (GUI обновляет вид, логирование, кеши).
- Минусы: возможны лишние уведомления, сложность отслеживания порядка/жизни наблюдателей.
- Пример проекта: в чате или системе уведомлений — при приходе нового сообщения уведомляются UI, счётчик непрочитанных и логирующий модуль.
$4$ Strategy
- Цель: инкапсулировать алгоритмы и делать их взаимозаменяемыми, отделить алгоритм от контекста.
- Структура: интерфейс стратегии и несколько конкретных реализаций; контекст хранит ссылку на стратегию и делегирует вызов.
- Когда использовать: разные варианты поведения/алгоритмов, выбор в рантайме или для тестирования.
- Минусы: увеличивает число классов; выбор стратегии должен быть очевиден.
- Пример проекта: модуль оценки теста — разные стратегии подсчёта баллов (с учётом частичных ответов, с штрафами за ошибки, простая сумма) можно переключать без изменения кода проверки.
$5$ Decorator
- Цель: динамически добавлять обязанности объекту без изменения его класса, альтернативa наследованию.
- Структура: компонентный интерфейс, конкретные компоненты и обёртки-декораторы, которые делегируют и добавляют поведение.
- Когда использовать: нужно гибко комбинировать дополнительные возможности, применять на уровне отдельных объектов.
- Минусы: может привести к глубокой вложенности обёрток и усложнить отладку.
- Пример проекта: система вывода отчётов — базовый генератор отчёта декорируется форматерами (PDF, CSV), кэшированием или шифрованием вывода по необходимости.
Если нужно — могу привести краткие UML-схемы или небольшой пример кода для любого паттерна.