Кратко опишу $...$ популярных паттернов (суть, решение, когда применять), затем приведу реализацию одного из них в языке, где паттерн заменим встроенными средствами, и объясню преимущества замены.
1) Factory
- Суть: выделить создание объектов в отдельный компонент, чтобы клиент не зависел от конкретных классов.
- Решение: фабрика (метод, класс или абстрактная фабрика) возвращает интерфейс/абстракцию, создавая нужный конкретный объект.
- Когда: когда код должен работать с семейством взаимозаменяемых продуктов или создание объекта зависит от конфигурации/параметров.
2) Singleton
- Суть: гарантировать существование ровно одного экземпляра некоторого класса и предоставить глобальную точку доступа.
- Решение: контролируемое создание экземпляра (через статические переменные, метаклассы, ленивую инициализацию).
- Когда: ресурсы/сервисы, которые действительно должны быть одни (например менеджер конфигурации), но применять осторожно из-за тестируемости и скрытых зависимостей.
3) Observer
- Суть: оповещать множество подписчиков об изменениях состояния субъекта без сильной связности.
- Решение: субъект хранит список слушателей и уведомляет их (через callback/интерфейс) при изменениях.
- Когда: UI-обновления, event-системы, асинхронные уведомления.
4) Strategy
- Суть: инкапсулировать алгоритмы в отдельные классы/объекты и делать их взаимозаменяемыми.
- Решение: клиент держит ссылку на интерфейс стратегии и может менять реализацию во время выполнения.
- Когда: когда есть множество схожих алгоритмов, выбираемых динамически, или нужно упростить тестирование/расширение алгоритмов.
5) Decorator
- Суть: добавлять поведение объекту динамически, не изменяя исходный класс.
- Решение: оборачивающие объекты реализуют тот же интерфейс и делегируют вызовы, добавляя функциональность до/после делегирования.
- Когда: когда нужно гибко комбинировать обязанности, избегая большого числа подклассов.
Пример: Singleton в Python и его идиоматичная замена
Классическая реализация Singleton (пример с метаклассом):
```python
class SingletonMeta(type):
_instance = None
def __call__(cls, *args, **kwargs):
if cls._instance is None:
cls._instance = super().__call__(*args, **kwargs)
return cls._instance
class Config(metaclass=SingletonMeta):
def __init__(self):
self.value = 0
```
Идиоматичная замена в Python — использовать модуль как singleton (встроенное поведение языка: модуль инициализируется один раз при первом импорте):
file config.py
```python
# config.py (модуль)
value = 0
def get_value():
return value
def set_value(v):
global value
value = v
```
Использование:
```python
import config
config.set_value(42)
# в любом месте приложения import config; config.get_value() вернёт 42
```
Преимущества замены паттерна Singleton модулем:
- Проще и короче: нет метаклассов/логики хранения экземпляра.
- Явность: зависимости видны через импорт, легче читать код.
- Гарантия единственности реализована механизмом импорта Python (модуль инициализируется один раз).
- Легче тестировать: можно мокать или заменять атрибуты модуля в тестах / импортировать тестовую версию модуля.
- Меньше проблем с сериализацией/пиклингом и рефлексией по сравнению с хитростями на уровне классов.
Короткие замечания и оговорки:
- Модульный подход действует в языках/рантаймах, где модульная система гарантирует одиночную инициализацию (например, Python, Node.js).
- Если инициализация должна быть ленивой, потокобезопасной или зависеть от параметров, может потребоваться явная фабрика/контейнер зависимостей вместо простого модуля.
- Во многих современных решениях предпочтительнее вообще избегать глобальных синглтонов и пользоваться DI/передачей зависимостей для лучшей тестируемости.
Если нужно, могу показать альтернативную реализацию (например, Strategy через функции в JavaScript) или пример тестирования модуля-singleton.