Что такое сильная связность?

Что такое сильная связность?

Сильная связность (tight coupling) в программировании — это ситуация, когда компоненты или модули сильно зависят друг от друга, что делает их трудными для изменения, тестирования и переиспользования. Противоположность этого явления — слабая связность (loose coupling).

Определение

Два компонента имеют сильную связность, когда:

1. Один компонент напрямую использует реализацию другого
2. Изменение одного требует изменения другого
3. Невозможно протестировать компонент отдельно
4. Компоненты переплетены и не переиспользуются

Пример сильной связности

// ПЛОХО: сильная связность
public class UserService {
    private DatabaseConnection dbConnection;
    
    public UserService() {
        // UserService создаёт свой экземпляр DatabaseConnection
        this.dbConnection = new DatabaseConnection("localhost", 5432);
    }
    
    public User getUserById(Long id) {
        // Напрямую использует конкретную реализацию DatabaseConnection
        return dbConnection.executeQuery("SELECT * FROM users WHERE id = " + id);
    }
}

// Проблемы:
// 1. Невозможно протестировать без реальной БД
// 2. Если изменить DatabaseConnection, нужно менять UserService
// 3. Невозможно использовать другую реализацию БД
public class UserServiceTest {
    @Test
    public void testGetUser() {
        // НЕВОЗМОЖНО создать сервис без реальной БД!
        UserService service = new UserService();
    }
}

Пример слабой связности

// ХОРОШО: слабая связность через интерфейс
public interface UserRepository {
    User findById(Long id);
}

public class UserService {
    private UserRepository userRepository;
    
    // Зависимость внедряется извне (Dependency Injection)
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
    
    public User getUserById(Long id) {
        // Использует интерфейс, а не конкретную реализацию
        return userRepository.findById(id);
    }
}

// Преимущества:
// 1. Легко тестировать с Mock объектами
// 2. Можно подставить любую реализацию UserRepository
// 3. Изменения в реализации не влияют на UserService
public class UserServiceTest {
    @Test
    public void testGetUser() {
        // Создаём Mock репозитория
        UserRepository mockRepository = Mockito.mock(UserRepository.class);
        User expectedUser = new User(1L, "John");
        Mockito.when(mockRepository.findById(1L)).thenReturn(expectedUser);
        
        // Создаём сервис с Mock
        UserService service = new UserService(mockRepository);
        
        // Тестируем без реальной БД
        User result = service.getUserById(1L);
        assertEquals(expectedUser, result);
    }
}

Проблемы сильной связности

1. Сложность тестирования

// Сильная связность — тесты зависят от других модулей
public class OrderService {
    private PaymentProcessor paymentProcessor = new PaymentProcessor();
    private EmailSender emailSender = new EmailSender();
    private InventoryService inventoryService = new InventoryService();
    
    public void createOrder(Order order) {
        // Для теста нужна реальная платёжная система!
        paymentProcessor.charge(order.getPrice());
        
        // Для теста нужен реальный email сервер!
        emailSender.send(order.getCustomerEmail());
        
        // Для теста нужна реальная БД инвентаря!
        inventoryService.updateStock(order.getItems());
    }
}

2. Сложность изменения кода

// Сильная связность — изменение влияет на множество мест
public class OldDatabaseConnection {
    public ResultSet query(String sql) { ... }
}

// Эта класс используется везде
public class UserService { private OldDatabaseConnection db; }
public class OrderService { private OldDatabaseConnection db; }
public class ProductService { private OldDatabaseConnection db; }

// Если заменить на новую БД, нужно менять везде!
public class NewDatabaseConnection {
    public List<Map<String, Object>> execute(String sql) { ... }
}

3. Невозможно переиспользовать

// Сильная связность — сложно переиспользовать в другом проекте
public class SpecificDatabaseUserDAO {
    private Connection connection;
    private Logger logger = LoggerFactory.getLogger(this.getClass());
    private ConfigManager configManager = new ConfigManager();
    
    // DAO переплетён с конкретной логгировкой и конфигурацией
    public User findById(Long id) { ... }
}

// Если хотим использовать этот DAO в другом проекте, всё зависает!

Способы уменьшить связность

1. Dependency Injection

// Вместо создания зависимостей внутри класса,
// внедрить их извне

public class OrderService {
    private PaymentProcessor paymentProcessor;
    private EmailSender emailSender;
    
    // Spring автоматически внедрит зависимости
    @Autowired
    public OrderService(PaymentProcessor paymentProcessor, EmailSender emailSender) {
        this.paymentProcessor = paymentProcessor;
        this.emailSender = emailSender;
    }
}

// Конфигурация
@Configuration
public class AppConfig {
    @Bean
    public PaymentProcessor paymentProcessor() {
        return new StripePaymentProcessor();
    }
    
    @Bean
    public EmailSender emailSender() {
        return new GmailEmailSender();
    }
}

2. Использование интерфейсов

// Зависим от интерфейса, а не от реализации
public interface Repository<T> {
    T findById(Long id);
    void save(T entity);
}

public class UserService {
    private Repository<User> userRepository;
    
    // Можем подставить любую реализацию
    public UserService(Repository<User> userRepository) {
        this.userRepository = userRepository;
    }
}

// Разные реализации
public class DatabaseUserRepository implements Repository<User> { ... }
public class CachedUserRepository implements Repository<User> { ... }
public class MockUserRepository implements Repository<User> { ... }

3. Event-Driven архитектура

// Вместо прямого вызова, используем события

public class OrderService {
    private ApplicationEventPublisher eventPublisher;
    
    public void createOrder(Order order) {
        // OrderService не знает о других сервисах
        eventPublisher.publishEvent(new OrderCreatedEvent(order));
    }
}

// Другие сервисы слушают события
@Component
public class PaymentEventListener {
    @EventListener
    public void onOrderCreated(OrderCreatedEvent event) {
        paymentProcessor.charge(event.getOrder().getPrice());
    }
}

@Component
public class EmailEventListener {
    @EventListener
    public void onOrderCreated(OrderCreatedEvent event) {
        emailSender.send(event.getOrder().getCustomerEmail());
    }
}

4. Facade паттерн

// Прячем сложность за простым интерфейсом
public class OrderFacade {
    private PaymentService paymentService;
    private InventoryService inventoryService;
    private EmailService emailService;
    
    // Клиент видит только простой интерфейс
    public void processOrder(Order order) {
        paymentService.charge(order.getPrice());
        inventoryService.updateStock(order.getItems());
        emailService.notifyCustomer(order);
    }
}

// Клиентский код
public class OrderController {
    @Autowired
    private OrderFacade orderFacade;
    
    @PostMapping("/orders")
    public void createOrder(@RequestBody Order order) {
        orderFacade.processOrder(order); // Простой вызов
    }
}

Сравнение: сильная vs слабая связность

SOLID принципы для снижения связности

• Single Responsibility — один класс, одна ответственность
• Open/Closed — открыт для расширения, закрыт для модификации
• Liskov Substitution — подтипы заменяемы
• Interface Segregation — специфичные интерфейсы
• Dependency Inversion — зависим от абстракций

Минимизация связности — это один из главных целей хорошей архитектуры ПО. Слабая связность делает код более гибким, тестируемым и поддерживаемым.