SOLID принципы в TypeScript: Применение на практике

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

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

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

S — Single Responsibility Principle (Принцип единственной ответственности)

Принцип: Каждый класс или модуль должен иметь только одну причину для изменения.

Пример нарушения:

class UserService {
  getUser(id: number) {
    // Логика получения пользователя
  }

  saveUser(user: any) {
    // Логика сохранения пользователя
  }

  sendEmail(email: string, message: string) {
    // Отправка email (лишняя ответственность)
  }
}

Как исправить:

class UserRepository {
  getUser(id: number) {
    // Получение пользователя из базы
  }

  saveUser(user: any) {
    // Сохранение пользователя в базу
  }
}

class EmailService {
  sendEmail(email: string, message: string) {
    // Отправка email
  }
}

Разделение логики делает код более поддерживаемым и удобным для тестирования.

O — Open/Closed Principle (Принцип открытости/закрытости)

Принцип: Код должен быть открыт для расширения, но закрыт для модификации.

Пример нарушения:

class PaymentProcessor {
  process(paymentType: string) {
    if (paymentType === "card") {
      console.log("Processing card payment");
    } else if (paymentType === "paypal") {
      console.log("Processing PayPal payment");
    }
  }
}

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

Как исправить:

interface PaymentMethod {
  process(): void;
}

class CardPayment implements PaymentMethod {
  process() {
    console.log("Processing card payment");
  }
}

class PayPalPayment implements PaymentMethod {
  process() {
    console.log("Processing PayPal payment");
  }
}

class PaymentProcessor {
  constructor(private method: PaymentMethod) {}
  process() {
    this.method.process();
  }
}

Теперь можно добавлять новые способы оплаты без изменения существующего кода.

L — Liskov Substitution Principle (Принцип подстановки Барбары Лисков)

Принцип: Объекты должны быть заменяемы их подтипами без изменения корректности программы.

Пример нарушения:

class Bird {
  fly() {
    console.log("Flying");
  }
}

class Penguin extends Bird {
  fly() {
    throw new Error("Penguins can't fly!");
  }
}

Как исправить:

interface Bird {
  move(): void;
}

class FlyingBird implements Bird {
  move() {
    console.log("Flying");
  }
}

class NonFlyingBird implements Bird {
  move() {
    console.log("Walking");
  }
}

Теперь подклассы корректно реализуют свое поведение.

I — Interface Segregation Principle (Принцип разделения интерфейсов)

Принцип: Клиенты не должны зависеть от интерфейсов, которые они не используют.

Пример нарушения:

interface Worker {
  work(): void;
  eat(): void;
}

class Developer implements Worker {
  work() {
    console.log("Writing code");
  }
  eat() {
    console.log("Eating lunch");
  }
}

class Robot implements Worker {
  work() {
    console.log("Assembling parts");
  }
  eat() {
    throw new Error("Robots don't eat");
  }
}

Как исправить:

interface Workable {
  work(): void;
}

interface Eatable {
  eat(): void;
}

class Developer implements Workable, Eatable {
  work() {
    console.log("Writing code");
  }
  eat() {
    console.log("Eating lunch");
  }
}

class Robot implements Workable {
  work() {
    console.log("Assembling parts");
  }
}

Теперь классы реализуют только те интерфейсы, которые им нужны.

D — Dependency Inversion Principle (Принцип инверсии зависимостей)

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

Пример нарушения:

class MySQLDatabase {
  connect() {
    console.log("Connected to MySQL");
  }
}

class UserService {
  private db = new MySQLDatabase();

  getUser() {
    this.db.connect();
  }
}

Как исправить:

interface Database {
  connect(): void;
}

class MySQLDatabase implements Database {
  connect() {
    console.log("Connected to MySQL");
  }
}

class UserService {
  constructor(private db: Database) {}

  getUser() {
    this.db.connect();
  }
}

Теперь можно легко заменить базу данных без изменения UserService.

Заключение

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

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

Если вы работаете над крупным проектом или планируете его масштабировать, использование SOLID значительно упростит поддержку кода и снизит вероятность ошибок.