В чем разница между Inversion of Control, Dependency Injection и Dependency Inversion Principle?

А, слушай, вот это тема, где народ обычно в говне тонет, потому что названия похожи, а смысл разный, как хуй и палец. Сейчас разложу по полочкам, чтобы ты не был как тот Герасим, который только "Му-му" может мычать.

1. Inversion of Control (IoC) — Инверсия управления Это, блядь, как если бы ты всю жизнь сам себе бутерброды мазал, а тут пришёл в охуенный ресторан. Ты не бегаешь на кухню, не режешь колбасу — ты просто садишься за стол и говоришь: «Принесите жрать». А повар (фреймворк) уже сам решает, в какой последовательности там ножи мыть, огонь разжигать и какую тарелку подобрать. Общая идея — управление жизненным циклом твоих объектов (когда создать, когда связать, когда убить) забирает на себя внешняя сила (контейнер Spring, например). Твой код становится не боссом, а подчинённым, который ждёт указаний сверху. Ёперный театр, но удобно.

2. Dependency Injection (DI) — Внедрение зависимостей А это уже конкретный способ, как этот ресторан тебя обслуживает. Это когда тебе не нужно самому лезть в холодильник за пивом и в шкаф за чипсами. Официант (контейнер) сам приносит тебе всё нужное и ставит на стол. В коде это значит: если твоему сервису нужен репозиторий, то ты его не создаёшь через new, а просишь: «А дайте-ка сюда репозиторий, я его в конструктор воткну».

Способы, как Spring тебе это может впендюрить:

@Component
public class OrderService {
    // 1. Через конструктор (самый правильный, как будто тебе вручают гранату — сразу видно, что держишь)
    private final NotificationService notifier;
    public OrderService(NotificationService notifier) {
        this.notifier = notifier; // Вот, получи, ебашь!
    }

    // 2. Через поле (по-тихому, как подсыпать яд в суп. Менее явно, тестировать хуёво)
    @Autowired
    private PaymentService paymentService;

    // 3. Через сеттер (старый дедовский способ, как будто через форточку передают)
    private UserService userService;
    @Autowired
    public void setUserService(UserService userService) {
        this.userService = userService;
    }
}

Зачем это всё? Ну, чтобы код был тестируемым — легко подсунуть муляж вместо настоящей базы данных. И гибким — сегодня база MySQL, а завтра захотел MongoDB, и нихуя не переписываешь всю логику, только новую реализацию подсовываешь.

3. Dependency Inversion Principle (DIP) — Принцип инверсии зависимостей А это, сука, уже не про реализацию, а про высший пилотаж проектирования, один из этих ваших SOLID-принципов. Правило такое, блядь:

1. Модули верхнего уровня (логика бизнеса) не должны зависеть от модулей нижнего уровня (работа с базой, файлами). Оба должны зависеть от какой-то абстракции (интерфейса).
2. Абстракции не должны зависеть от деталей. Наоборот, детали (конкретные реализации) должны зависеть от абстракций.

Смотри, как бывает:

// ПЛОХО: Класс бизнес-логики привязан намертво к конкретной базе. Это пиздец как негибко.
class OrderProcessor {
    private MySqlDatabase database = new MySqlDatabase(); // Жёсткая привязка, как сварка
    void process(Order order) {
        database.save(order);
    }
}

// ХОРОШО: Следуем DIP. Все зависят от интерфейса.
interface Repository { // Абстракция, она же святая корова
    void save(Order order);
}

class OrderProcessor { // Верхний уровень (логика)
    private final Repository repo; // Зависит от интерфейса, а не от MySQL!
    public OrderProcessor(Repository repo) { this.repo = repo; } // DI в действии!
    void process(Order order) { repo.save(order); }
}

class MySqlDatabase implements Repository { ... } // Деталь №1
class MongoDatabase implements Repository { ... } // Деталь №2

Итог, чтобы не ебал мозг:

• IoC — это философия, идея «сиди и не рыпайся, за тебя всё сделают».
• DI — это конкретный инструмент, реализующий эту идею. Как отвёртка, которой завинчивают.
• DIP — это закон, мотивирующий тебя использовать DI и интерфейсы, чтобы не получить спагетти-код, который завтра развалится от любого чиха. Без него DI — просто красивая игрушка, а с ним — мощная архитектура.

Вот и вся магия. Вроде бы три разных слова, а вместе они создают эту вашу Spring-магию, где ты объявил интерфейс, поставил пару аннотаций, а контейнер уже бегает как угорелый и всё связывает. Главное — не перепутай, а то будешь как тот, кто принципы с паттернами в одну кучу мешает.