Приведи пример использования Dependency Inversion Principle из SOLID

Dependency Inversion Principle (DIP) из SOLID

Dependency Inversion Principle — принцип, который гласит:

• Высокоуровневые модули не должны зависеть от низкоуровневых модулей; оба должны зависеть от абстракций (интерфейсов)
• Абстракции не должны зависеть от деталей; детали должны зависеть от абстракций

Этот принцип позволяет создавать гибкий и тестируемый код, где легко подменять реализации.

Проблема без DIP

Найчастую встречается такой код, где высокоуровневый класс прямо зависит от низкоуровневых реализаций:

// Низкоуровневый класс — конкретная реализация БД
public class MySQLDatabase {
    public void save(User user) {
        System.out.println("Saving to MySQL: " + user.getName());
    }
}

// Высокоуровневый класс — зависит прямо от MySQLDatabase
public class UserService {
    private MySQLDatabase database; // ПЛОХО: прямая зависимость
    
    public UserService() {
        this.database = new MySQLDatabase();
    }
    
    public void registerUser(User user) {
        // Проверки, валидация...
        database.save(user);
    }
}

Проблемы:

• Невозможно заменить БД на PostgreSQL без изменения UserService
• Сложно тестировать: нужна реальная БД или сложный мок
• Высокая связанность (coupling) между классами

Решение с DIP

Используем интерфейс как абстракцию, на которой основываются обе стороны:

// 1. Абстракция (интерфейс)
public interface Database {
    void save(User user);
    User findById(Long id);
}

// 2. Низкоуровневые реализации
public class MySQLDatabase implements Database {
    @Override
    public void save(User user) {
        System.out.println("Saving to MySQL: " + user.getName());
    }
    
    @Override
    public User findById(Long id) {
        // MySQL логика
        return new User(id, "John");
    }
}

public class PostgreSQLDatabase implements Database {
    @Override
    public void save(User user) {
        System.out.println("Saving to PostgreSQL: " + user.getName());
    }
    
    @Override
    public User findById(Long id) {
        // PostgreSQL логика
        return new User(id, "John");
    }
}

// 3. Высокоуровневый класс — зависит от абстракции
public class UserService {
    private Database database; // ХОРОШО: зависимость от интерфейса
    
    // Инъекция зависимости через конструктор
    public UserService(Database database) {
        this.database = database;
    }
    
    public void registerUser(User user) {
        // Валидация
        if (user.getName() == null || user.getName().isEmpty()) {
            throw new IllegalArgumentException("Name is required");
        }
        
        // Используем абстракцию, не конкретную реализацию
        database.save(user);
    }
    
    public User getUserInfo(Long id) {
        return database.findById(id);
    }
}

Преимущества этого подхода

1. Легкая подмена реализаций

// Используем MySQL
Database mysqlDb = new MySQLDatabase();
UserService service1 = new UserService(mysqlDb);

// Переходим на PostgreSQL — достаточно одной строки!
Database postgresDb = new PostgreSQLDatabase();
UserService service2 = new UserService(postgresDb);

2. Простое тестирование

// Mock реализация для тестов
public class MockDatabase implements Database {
    @Override
    public void save(User user) {
        System.out.println("Mock: saving user");
    }
    
    @Override
    public User findById(Long id) {
        return new User(1L, "Test User");
    }
}

// Тест без реальной БД
@Test
public void testRegisterUser() {
    Database mockDb = new MockDatabase();
    UserService service = new UserService(mockDb);
    
    User user = new User(null, "Alice");
    service.registerUser(user); // Не требует реальной БД
}

3. Низкая связанность

USerService ничего не знает о конкретных реализациях БД. Это позволяет разработчикам работать независимо.

4. Масштабируемость

Легко добавить новые реализации — MongoDB, Cassandra и т.д., не трогая UserService:

public class MongoDBDatabase implements Database {
    @Override
    public void save(User user) {
        // MongoDB логика
    }
    
    @Override
    public User findById(Long id) {
        // MongoDB логика
        return null;
    }
}

Dependency Injection контейнер (Spring)

В реальных приложениях обычно используется DI контейнер, как Spring:

@Configuration
public class AppConfig {
    @Bean
    public Database database() {
        return new PostgreSQLDatabase(); // Выбор реализации в одном месте
    }
    
    @Bean
    public UserService userService(Database database) {
        return new UserService(database); // Автоматическая инъекция
    }
}

// Использование
@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        ApplicationContext context = SpringApplication.run(Application.class, args);
        UserService service = context.getBean(UserService.class);
        
        User user = new User(null, "Bob");
        service.registerUser(user);
    }
}

Ключевые выводы

Dependency Inversion Principle:

• Делает код более гибким и тестируемым
• Снижает связанность между компонентами
• Позволяет легко подменять реализации
• Является основой для использования Design Patterns (Adapter, Strategy, Factory)
• В Spring приложениях реализуется через Dependency Injection