Записки погромиста

«Низкая связанность» (low coupling) в контексте программирования означает, что компоненты (модули, классы, функции) в вашем коде слабо зависят друг от друга. Это является важным принципом проектирования программного обеспечения, так как низкая связанность способствует улучшению понимания, обслуживания, и масштабируемости кода. Вот несколько принципов, которые помогают достичь низкой связанности:

1. Разделение обязанностей (Single Responsibility Principle — SRP): Каждый компонент (класс, модуль, функция) должен иметь только одну ответственность. Это означает, что каждый компонент делает одну вещь, и он делает это хорошо. Это способствует уменьшению связанности, так как изменения в одной области не влияют на другие.
2. Интерфейсы и абстракции: Используйте интерфейсы и абстракции, чтобы скрыть детали реализации от других компонентов. Это позволяет изменять внутреннюю реализацию без воздействия на другие части системы.
3. Зависимость инверсии (Dependency Inversion): Применяйте принцип инверсии зависимости, чтобы компоненты зависели от абстракций, а не от конкретных реализаций. Это уменьшает связанность, так как компоненты не привязаны непосредственно друг к другу.
4. Использование событий и сообщений: Вместо прямых вызовов функций, используйте механизмы событий или сообщений для связи между компонентами. Это позволяет им работать независимо друг от друга.
5. Модульная структура: Разделите ваш код на модули или пакеты, которые имеют четкие грани и определенные интерфейсы для взаимодействия.
6. Тестирование: Хорошо спроектированный код с низкой связанностью легче тестировать, так как вы можете изолировать компоненты и проверять их независимо.
7. Документация и комментарии: Документируйте, как компоненты взаимодействуют друг с другом, чтобы другие разработчики могли легко понимать и использовать ваш код.

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

«High cohesion» в разработке программного обеспечения означает концепцию проектирования компонентов программы (таких как классы, модули или функции) таким образом, чтобы элементы внутри компонента были тесно связаны и работали вместе для выполнения конкретной, четко определенной задачи или ответственности.

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

1. Принцип единственной ответственности (SRP): Каждый компонент (например, класс или функция) должен иметь одну, четко определенную ответственность. Он должен делать одну вещь и делать это хорошо.
2. Группировка связанных функциональностей: Группируйте функции или методы, которые имеют тесно связанные задачи. Например, если у вас есть класс для обработки аутентификации пользователей, все методы, связанные с аутентификацией, должны находиться в этом классе.
3. Логическая организация кода: Упорядочивайте свой код логически и последовательно. Это помогает разработчикам понимать, как взаимодействуют разные части программы.
4. Минимизация зависимостей: Компоненты должны иметь слабую связанность с другими компонентами. Это означает, что они должны зависеть от как можно меньшего числа других компонентов, чтобы минимизировать риск изменения одного компонента, влияющего на многие другие.
5. Использование интерфейсов и абстракций: Определите четкие интерфейсы и абстракции, которые позволяют компонентам взаимодействовать друг с другом через четко определенные контракты, снижая прямые зависимости между ними.
6. Разделение задач: Разделите вашу программу на слои или модули, которые сосредоточены на разных задачах. Например, разделите логику пользовательского интерфейса (UI) от бизнес-логики и доступа к данным.
7. Инкапсуляция данных: Сохраняйте данные внутри компонента, который работает с ними. Избегайте прямого раскрытия внутренних данных другим компонентам и используйте методы доступа и мутаторы для контроля доступа к данным.
8. Четкие и самодостаточные функции: Функции внутри компонента должны быть самодостаточными и работать с четко определенным набором данных. Они не должны сильно зависеть от глобальных или внешних данных.
9. Наименование и документация: Используйте четкие и описательные наименования для компонентов, функций и переменных. Хорошо документированный код помогает другим разработчикам легче понимать назначение и использование компонента.
10. Модульное тестирование: Высокая связанность часто приводит к компонентам, которые легче тестировать в изоляции. Написание модульных тестов для отдельных компонентов помогает обеспечить их фокусировку и четкость.

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

Давайте рассмотрим примеры хорошего и плохого кода на TypeScript, чтобы проиллюстрировать концепции высокой связанности (high cohesion) и низкой связанности (low coupling):

Пример 1: High Cohesion and Low Coupling

Хороший код (High Cohesion):

class Calculator {
  add(a: number, b: number): number {
    return a + b;
  }
  
  subtract(a: number, b: number): number {
    return a - b;
  }
}

Объяснение: В этом примере класс Calculator имеет высокую связанность, так как все методы относятся к одной области ответственности, а именно математическим операциям. Этот класс легко понимать, тестировать и изменять.

Плохой код (Low Cohesion and High Coupling):

class Calculator {
  performOperation(a: number, b: number, operation: string): number {
    if (operation === 'add') {
      return a + b;
    } else if (operation === 'subtract') {
      return a - b;
    }
  }
}

Объяснение: В этом примере класс Calculator имеет низкую связанность, так как один метод обрабатывает разные операции на основе переданного аргумента operation. Это делает класс менее понятным и более связанным с клиентским кодом, который должен знать, какие операции существуют.

Пример 2: High Cohesion and Low Coupling

Хороший код (High Cohesion):

class Customer {
  private name: string;
  private email: string;

  constructor(name: string, email: string) {
    this.name = name;
    this.email = email;
  }

  getName(): string {
    return this.name;
  }
}

class EmailService {
  sendEmail(customer: Customer, message: string): void {
    // Logic to send email to the customer's email address
  }
}

Объяснение: Здесь класс Customer имеет высокую связанность, так как он отвечает только за данные и операции, связанные с клиентами. EmailService также имеет высокую связанность, так как он отвечает только за отправку электронных писем. Классы слабо связаны, так как EmailService зависит от абстракции Customer, а не от конкретной реализации.

Плохой код (Low Cohesion and High Coupling):

class CustomerAndEmailService {
  private name: string;
  private email: string;

  constructor(name: string, email: string) {
    this.name = name;
    this.email = email;
  }

  getName(): string {
    return this.name;
  }

  sendEmail(message: string): void {
    // Logic to send email to the customer's email address
  }
}

Объяснение: В этом примере класс CustomerAndEmailService имеет низкую связанность, так как он объединяет два разных функциональных блока (управление клиентами и отправку электронных писем) в одном классе. Это делает код менее понятным и связывает два разных аспекта в одном месте.

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