Как Dependency Injection позволяет подменять реализации зависимостей?

Давай разберём эту штуку, Dependency Injection, но без заумных соплей. Представь, ты пишешь код, а внутри него, как в говне, зашиты конкретные штуки — база данных, логгер, внешний сервис. И вот ты пишешь тест, а он, блядь, не работает, потому что пытается стучаться в реальную базу, которой нет. Или хочешь поменять логгер, а приходится перелопачивать весь код. Пиздец, да?

А теперь смотри, как это делают умные люди, чтобы не быть мудаками. Суть в том, чтобы не создавать зависимости внутри класса, а получать их снаружи. Как будто тебе не самому готовить обед, а чтобы его приносили. И главное — ты договариваешься не про конкретный борщ, а про «что-то съедобное». Тогда тебе могут принести и борщ, и щи, и даже, нахуй, доширак, если очень надо.

Зачем это, блядь, нужно?

• Тестировать — овердохуища проще. Вместо реальной базы данных ты подсовываешь муляж, который не падает и не требует настроек.
• Менять поведение, не переписывая всё под чистую. Захотел другой логгер — просто передал другую реализацию, а не искал по всему коду, где ты его вызывал.
• Не зависеть от конкретной хуйни. Класс знает только интерфейс (договор), а не то, кто именно его выполняет. Слабая связанность, ёпта! Это когда один модуль не знает, как устроен другой, и всем от этого хорошо.

Смотри на примере, тут всё понятно будет:

from abc import ABC, abstractmethod
from typing import List

# 1. Вот наш договор, абстракция. Говорим: "Всё, что умеет логировать — годится".
class Logger(ABC):
    @abstractmethod
    def log(self, message: str) -> None:
        pass

# 2. Реальная рабочая лошадка. Кидает сообщения прямо в консоль.
class ConsoleLogger(Logger):
    def log(self, message: str) -> None:
        print(f"[CONSOLE] {message}")

# 3. А это — подстава для тестов. Сохраняет всё в список, чтобы потом проверить.
class MockLogger(Logger):
    def __init__(self):
        self.logged_messages: List[str] = []

    def log(self, message: str) -> None:
        self.logged_messages.append(message)
        print(f"[MOCK] {message} (captured)") # Для наглядности, в жизни можно и без принта

# 4. А вот наш главный герой — сервис. Он хочет логировать, но не парится, КАК именно.
class Service:
    # Смотри сюда, ебать! Логгер ему ПЕРЕДАЮТ извне. Он его не создаёт сам.
    def __init__(self, logger: Logger):
        self.logger = logger

    def do_work(self, task_id: int):
        self.logger.log(f"Начало работы над задачей {task_id}...")
        # ... какая-то бизнес-логика ...
        self.logger.log(f"Задача {task_id} завершена.")

# --- А теперь смотрим, как этим пользоваться, не будем идиотами ---

print("--- Работаем по-настоящему ---")
# В боевом режине даём ему нормальный логгер
prod_service = Service(ConsoleLogger())
prod_service.do_work(1)
# Вывод в консоль, всё как люди:
# [CONSOLE] Начало работы над задачей 1...
# [CONSOLE] Задача 1 завершена.

print("n--- А теперь тестируем, как хитрая жопа ---")
# А для тестов подсовываем муляж!
test_logger = MockLogger()
test_service = Service(test_logger) # Тот же сервис, но с другой начинкой!
test_service.do_work(2)

# И теперь мы можем проверить, что он там налогировал, без всяких реальных систем!
assert "Начало работы над задачей 2..." in test_logger.logged_messages
assert "Задача 2 завершена." in test_logger.logged_messages
print(f"Всё, что записал наш муляж: {test_logger.logged_messages}")

Вот и вся магия, ёпта! Сервису похуй, какой логгер — консольный или тестовый. Он знает только, что у него есть что-то, умеющее делать .log(). А кто это — его не ебёт. Это и есть Dependency Injection: не самому лезть за зависимостью, а чтобы её внедрили. Как результат — код становится гибким, как гимнастка, и тестируемым, как инструкция к стиралке.