В чем разница между Cohesion и Coupling

Вопрос

В чем разница между Cohesion и Coupling

Профессия

Frontend Developer

Что хочет услышать интервьюер

Интервьюер хочет убедиться, что кандидат понимает ключевые принципы проектирования ПО и может объяснить их на примерах. Важно показать, как эти концепции влияют на качество кода и его поддержку.

Ключевые тезисы

• Cohesion (связность) — это степень, в которой элементы модуля (например, функции или классы) связаны между собой и работают для выполнения одной задачи. Высокая связность означает, что модуль выполняет одну четкую задачу.
• Coupling (сцепление) — это степень зависимости между модулями. Низкое сцепление означает, что модули слабо зависят друг от друга, что упрощает их изменение и поддержку.
• Идеальная архитектура стремится к высокой связности (Cohesion) и низкому сцеплению (Coupling), так как это делает код более читаемым, поддерживаемым и масштабируемым.
• Пример высокой связности: класс UserRepository, который отвечает только за работу с данными пользователя. Пример низкого сцепления: модуль AuthService, который зависит от абстракции (интерфейса) UserRepository, а не от его конкретной реализации.

Подробный ответ

Cohesion (связность) и Coupling (сцепление) — это два ключевых принципа проектирования программного обеспечения, которые помогают создавать чистый, поддерживаемый и масштабируемый код. Cohesion определяет, насколько элементы внутри одного модуля (например, класса или функции) связаны между собой и работают для выполнения одной четкой задачи. Высокая связность (High Cohesion) означает, что модуль фокусируется на одной ответственности, что упрощает его понимание и тестирование. Например, класс UserRepository должен отвечать только за операции с данными пользователя, а не за логирование или валидацию. Низкая связность (Low Cohesion), напротив, приводит к «божественным классам», которые делают слишком много, усложняя поддержку и модификацию кода.

Coupling (сцепление) описывает степень зависимости между модулями. Низкое сцепление (Low Coupling) означает, что модули минимально зависят друг от друга, что облегчает их замену или изменение без влияния на другие части системы. Например, модуль AuthService должен зависеть от интерфейса UserRepository, а не от его конкретной реализации. Это позволяет легко менять реализацию UserRepository (например, с базы данных на API) без изменений в AuthService. Высокое сцепление (High Coupling) делает систему хрупкой: изменения в одном модуле могут «разорвать» другие, увеличивая риски при рефакторинге.

Идеальная архитектура стремится к высокой связности и низкому сцеплению. Это особенно важно в микросервисной архитектуре, где каждый сервис должен быть максимально независимым и focused на своей задаче. Например, сервис «Пользователи» не должен напрямую вызывать методы сервиса «Заказы» — вместо этого они общаются через API или message queue, уменьшая сцепление.

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

Пример 1

Пример высокой связности: класс OrderService, который содержит только методы для работы с заказами (создание, обновление, отмена). Низкая связность: класс Utils, который объединяет методы для работы с датами, строками, HTTP-запросами и валидацией — такой класс сложно поддерживать.

Пример 2

Пример низкого сцепления: модуль PaymentProcessor зависит от интерфейса PaymentGateway, а не от конкретного класса StripeGateway. Это позволяет легко заменить Stripe на PayPal, изменив только реализацию PaymentGateway.

Пример 3

Пример высокого сцепления: класс ReportGenerator напрямую использует DatabaseConnection и знает детали SQL-запросов. При смене базы данных придется переписывать ReportGenerator.

Частые ошибки

• Путаница между терминами: кандидаты иногда говорят, что «высокое сцепление — это хорошо», но на самом деле хорошо низкое сцепление.
• Игнорирование принципа единственной ответственности (SRP), что приводит к низкой связности. Например, класс UserManager, который и логирует, и отправляет email, и валидирует данные.
• Использование конкретных классов вместо абстракций, что увеличивает сцепление. Например, new StripeGateway() внутри PaymentService вместо инъекции зависимости через интерфейс.

Связанные темы

• Принцип единственной ответственности (SRP)
• Инверсия зависимостей (Dependency Injection)
• Паттерны проектирования: Фасад, Адаптер, Наблюдатель
• Микросервисная архитектура

Follow-up вопросы

Можете привести пример низкой связности (Low Cohesion) и объяснить, почему это плохо?

Уровень: basic

Пример низкой связности — класс, который отвечает и за обработку данных, и за их отображение, и за логику бизнеса. Это плохо, потому что такой класс становится сложным для понимания, тестирования и поддержки.

Как вы можете достичь низкого сцепления в своем коде?

Уровень: intermediate

Низкого сцепления можно достичь, используя принципы SOLID, такие как Dependency Injection и разделение интерфейсов. Это позволяет модулям зависеть от абстракций, а не от конкретных реализаций.

Какие проблемы могут возникнуть при высоком сцеплении (High Coupling)?

Уровень: intermediate

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

Как связаны Cohesion и Coupling с архитектурой микросервисов?

Уровень: advanced

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

Можете объяснить, как Cohesion и Coupling влияют на читаемость кода?

Уровень: basic

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