Какие плюсы и минусы monkey patching?

Monkey Patching в Python: плюсы и минусы

Monkey patching — это изменение поведения кода во время выполнения программы без изменения исходного кода. Это мощный инструмент, но опасный.

1. Что такое monkey patching

# Оригинальный класс в библиотеке third-party
class RequestsLibrary:
    @staticmethod
    def get(url):
        print("Делаю HTTP запрос")
        return {"status": 200}

# Monkey patch: меняем поведение
original_get = RequestsLibrary.get

def mocked_get(url):
    print("Перехватил запрос (тестирование)")
    return {"status": 200, "data": "mocked"}

RequestsLibrary.get = mocked_get

# Теперь все вызовы используют новую версию
result = RequestsLibrary.get("http://api.example.com")
print(result)  # Использует mocked_get

2. Частые случаи использования

# Случай 1: Мокирование для тестов
from unittest.mock import patch
import requests

def test_api_call():
    # Меняем requests.get на mock
    with patch('requests.get') as mock_get:
        mock_get.return_value.status_code = 200
        mock_get.return_value.json.return_value = {"id": 1}
        
        result = fetch_user(1)
        assert result["id"] == 1

# Случай 2: Добавление нового метода
class OldLibrary:
    def old_method(self):
        return "old"

# Добавляем новый метод
OldLibrary.new_method = lambda self: "new"

obj = OldLibrary()
print(obj.new_method())  # "new"

# Случай 3: Изменение встроенного поведения
import datetime

original_now = datetime.datetime.now

def mocked_now():
    return datetime.datetime(2020, 1, 1, 12, 0, 0)

datetime.datetime.now = mocked_now

print(datetime.datetime.now())  # 2020-01-01 12:00:00

3. Плюсы monkey patching

plus = {
    "Тестирование": """
        Очень удобно мокировать зависимости без изменения основного кода.
        Не нужно передавать зависимости в конструктор.
    """,
    
    "Быстрый фикс": """
        Можно быстро исправить баг в third-party библиотеке без форка.
        Особенно полезно в production для экстренных ситуаций.
    """,
    
    "Динамичность": """
        Python позволяет менять код во время выполнения.
        Не нужно перекомпилировать (в отличие от Java).
    """,
    
    "Простота для прототипирования": """
        Можно быстро экспериментировать с кодом.
        Вставить логирование, трассировку без большого рефакторинга.
    """,
    
    "Работа с legacy кодом": """
        Когда переписать нельзя, но нужно изменить поведение.
        Monkey patch спасает старые системы.
    """
}

4. Минусы monkey patching

minuses = {
    "Непредсказуемость": """
        Код ведёт себя не так, как написано.
        Другой разработчик может не заметить, что поведение переопределено.
        Отладка становится кошмаром.
    """,
    
    "Сложность отладки": """
        Стектрейс показывает неправильное место кода.
        IDE не может найти реальное определение функции.
        Debugger может вести себя странно.
    """,
    
    "Глобальное состояние": """
        Изменение влияет на весь код программы.
        Если забыл восстановить original, проблемы будут везде.
        Порядок импортов может повлиять на результат.
    """,
    
    "Несовместимость с обновлениями библиотеки": """
        Когда library обновляется, monkey patch может сломаться.
        API мог измениться, и твой patch больше не работает.
    """,
    
    "Сложность тестирования": """
        Если забыл вернуть original после теста, next test сломается.
        Тесты становятся зависимыми друг от друга.
        Порядок запуска тестов влияет на результат (плохо!).
    """,
    
    "Производительность": """
        Дополнительная обёртка может замедлить код.
        Особенно если patch вызывается часто.
    """,
    
    "Статическая типизация": """
        MyPy и другие type checkers не видят monkey patched методы.
        Могут быть false positives типов.
    """
}

5. Практические примеры

Хороший пример: тестирование с патчем

# production code
import requests

def fetch_user_from_api(user_id: int):
    response = requests.get(f"https://api.example.com/users/{user_id}")
    return response.json()

# test code
from unittest.mock import patch, MagicMock

def test_fetch_user():
    with patch('requests.get') as mock_get:
        # Настраиваем mock
        mock_response = MagicMock()
        mock_response.json.return_value = {"id": 1, "name": "Alice"}
        mock_get.return_value = mock_response
        
        # Тест
        result = fetch_user_from_api(1)
        assert result["name"] == "Alice"
        
        # Проверяем, что requests.get был вызван с правильными параметрами
        mock_get.assert_called_once_with("https://api.example.com/users/1")
    
    # После выхода из with, requests.get автоматически восстановлен

Плохой пример: грязный monkey patch

# ❌ Плохо
import datetime

# Где-то в коде (сложно найти)
datetime.datetime.now = lambda: datetime.datetime(2020, 1, 1)

# Другой код ломается
print(datetime.datetime.now())  # 2020-01-01 (всегда)
print("Current time:", datetime.datetime.now())  # Тоже 2020-01-01
# Тесты, которые полагаются на реальное время, падают

Хорошо: контролируемый patch с контекстом

# ✓ Хорошо
from unittest.mock import patch
import datetime

def test_something_with_fixed_time():
    with patch('datetime.datetime') as mock_datetime:
        mock_datetime.now.return_value = datetime.datetime(2020, 1, 1)
        
        # Тест с фиксированным временем
        result = process_time_sensitive_task()
        assert result == "processed at 2020-01-01"
    
    # После теста всё восстановлено
    print(datetime.datetime.now())  # Реальное время

6. Альтернативы monkey patching

alternatives = {
    "Dependency Injection": """
        Передавай зависимости через конструктор.
        Легче тестировать, легче понять код.
    """,
    
    "Стратегия (Strategy pattern)": """
        Разные реализации в разных контекстах.
        Явно и понятно.
    """,
    
    "Использование interfaces/protocols": """
        TypeScript/Go style: определи interface.
        Python 3.8+: typing.Protocol.
    """,
    
    "Фабрики (Factory pattern)": """
        Создание объектов через factory функции.
        Легко подменить на тестирование.
    """,
    
    "Composition over inheritance": """
        Вместо наследования используй composition.
        Больше гибкости, меньше неожиданностей.
    """
}

# Пример: вместо monkey patching используй DI
class APIClient:
    def __init__(self, http_client=None):
        self.http_client = http_client or requests
    
    def get_user(self, user_id):
        return self.http_client.get(f"/users/{user_id}").json()

# В тестах:
class MockHTTPClient:
    def get(self, url):
        class Response:
            def json(self):
                return {"id": 1, "name": "Alice"}
        return Response()

api = APIClient(http_client=MockHTTPClient())
result = api.get_user(1)
assert result["name"] == "Alice"

7. Когда monkey patching оправдан

приемлемые_случаи = {
    "Тестирование": "Почти всегда OK, если используешь unittest.mock",
    "Быстрый фикс в production": "Если это временное решение на час",
    "Отладка": "Для добавления логирования к чужому коду",
    "Prototyping": "Когда быстро экспериментируешь",
    "Legacy системы": "Когда переписать нельзя",
}

неприемлемые_случаи = {
    "Основная архитектура": "Если основан на monkey patching — плохой дизайн",
    "Постоянное решение": "Если это неделю уже в production",
    "Для скрытия проблем": "Если patch скрывает реальный баг",
    "В библиотеках": "Твоя библиотека не должна делать monkey patch",
}

8. Best practices

best_practices = [
    "Используй unittest.mock вместо ручного патчинга",
    "Всегда используй контекстные менеджеры (with) для патчей",
    "Не патчи глобальное состояние надолго",
    "Документируй, если используешь monkey patching",
    "Предпочитай Dependency Injection",
    "Если часто патчишь — переосмысли архитектуру",
    "В тестах: setUp восстанавливает, tearDown очищает",
    "Избегай цепочек monkey patches",
]

Итог

Monkey patching в Python:

• Хорош для: тестирования (через unittest.mock), быстрого фикса, прототипирования
• Плох для: основной архитектуры, постоянных решений, в production без контроля
• Правило: если часто патчишь код других — переосмысли архитектуру

Лучший подход: используй Dependency Injection + unittest.mock для тестов. Это явно, понятно, и не создаёт скрытые зависимости.