Как структуризировать классы в зависимости от конекста?

Структуризация классов в зависимости от контекста в Frontend-разработке

Структуризация классов — это фундаментальный аспект проектирования поддерживаемых и масштабируемых фронтенд-приложений. Подход варьируется в зависимости от контекста: фреймворк (React, Vue, Angular, Svelte), архитектурный паттерн (MVC, MVVM, Flux) и специфика задачи (UI-компоненты, сервисы, утилиты).

Ключевые принципы структуризации

1. Принцип единственной ответственности (SRP): Каждый класс должен решать одну задачу. Например:

    *   `UserApiService` — работа с API пользователей.
    *   `FormValidator` — валидация данных формы.
    *   `NotificationRenderer` — отрисовка уведомлений.

1. Инкапсуляция: Скрытие внутренней реализации и предоставление четкого публичного интерфейса.

2. Композиция над наследованием: Для фронтенда, особенно в React, предпочтительнее создавать сложные объекты путем комбинации простых, а не выстраивания глубоких иерархий наследования.

Структуризация по типам классов

1. Классы UI-компонентов (в компонентно-ориентированных фреймворках)

В современных фреймворках классы часто используются для stateful-компонентов или сервисов. Структура зависит от возможностей фреймворка.

Пример в React с классами (до появления Hooks):

// UserProfile.jsx
import React from 'react';
import UserService from '../services/UserService';

class UserProfile extends React.Component {
  constructor(props) {
    super(props);
    this.state = { user: null, isLoading: false };
    this.userService = new UserService(); // Композиция сервиса
  }

  async componentDidMount() {
    await this.loadUserData();
  }

  loadUserData = async () => {
    this.setState({ isLoading: true });
    try {
      const user = await this.userService.fetchUser(this.props.userId);
      this.setState({ user, isLoading: false });
    } catch (error) {
      this.setState({ error, isLoading: false });
    }
  };

  render() {
    const { user, isLoading } = this.state;
    if (isLoading) return <Spinner />;
    return (
      <div className="user-profile">
        <h2>{user.name}</h2>
        <Avatar src={user.avatarUrl} />
      </div>
    );
  }
}

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

2. Классы-сервисы / Модели

Эти классы инкапсулируют бизнес-логику, работу с API или управление данными.

Пример класса-сервиса:

// PaymentService.js
import ApiClient from './ApiClient';

export class PaymentService {
  constructor(apiClient = new ApiClient()) {
    this.apiClient = apiClient; // Dependency Injection
  }

  async processPayment(orderData) {
    this.validateOrder(orderData);
    const encryptedData = this.encryptSensitiveData(orderData);
    return await this.apiClient.post('/payments', encryptedData);
  }

  validateOrder(order) {
    if (!order.amount || order.amount <= 0) {
      throw new Error('Invalid order amount');
    }
    // ... другая валидация
  }

  encryptSensitiveData(data) {
    // ... логика шифрования
    return { ...data, encrypted: true };
  }

  // Статический метод для утилитарных операций
  static formatCurrency(amount, currency) {
    return new Intl.NumberFormat('ru-RU', {
      style: 'currency',
      currency
    }).format(amount);
  }
}

// Использование
const paymentService = new PaymentService();
await paymentService.processPayment(order);
const formatted = PaymentService.formatCurrency(1000, 'RUB');

3. Классы-утилиты (Хелперы)

Классы со статическими методами для переиспользуемых операций. Часто не имеют состояния.

// DateFormatter.js
export class DateFormatter {
  static toLocalString(date, locale = 'ru-RU') {
    return new Date(date).toLocaleDateString(locale, {
      year: 'numeric',
      month: 'long',
      day: 'numeric'
    });
  }

  static getRelativeTime(fromDate, toDate = new Date()) {
    const diffMs = toDate - new Date(fromDate);
    const diffDays = Math.floor(diffMs / (1000 * 60 * 60 * 24));
    return diffDays === 0 ? 'Сегодня' : `${diffDays} дней назад`;
  }
}

// Использование без инстанса
const readableDate = DateFormatter.toLocalString('2024-01-15');

4. Классы для управления состоянием (State Management)

Вне зависимости от использования Redux, MobX или контекста, классы могут моделировать доменные сущности.

// CartStore.js (пример для MobX)
import { makeAutoObservable } from 'mobx';

class CartStore {
  items = [];
  total = 0;

  constructor() {
    makeAutoObservable(this);
  }

  addItem(product) {
    const existing = this.items.find(item => item.id === product.id);
    if (existing) {
      existing.quantity += 1;
    } else {
      this.items.push({ ...product, quantity: 1 });
    }
    this.calculateTotal();
  }

  calculateTotal() {
    this.total = this.items.reduce(
      (sum, item) => sum + item.price * item.quantity,
      0
    );
  }

  get itemCount() {
    return this.items.reduce((count, item) => count + item.quantity, 0);
  }
}

Рекомендации по структуризации в проекте

• Группируйте по функциональности (Feature-based), а не по типу:

  src/
  ├── features/
  │   ├── cart/
  │   │   ├── Cart.jsx
  │   │   ├── CartService.js
  │   │   └── CartStore.js
  │   └── user/
  │       ├── UserProfile.jsx
  │       └── UserApiService.js
  ├── shared/
  │   ├── services/
  │   ├── utils/
  │   └── ui/
  └── core/
  

• Используйте Dependency Injection для тестируемости и гибкости.
• Избегайте "God Objects" — классов, которые знают и делают слишком много.
• Для UI-логики в современных React/Vue приложениях предпочитайте функциональные компоненты с хуками, а классы оставляйте для сложной бизнес-логики, сервисов и менеджеров состояния.
• В TypeScript активно используйте интерфейсы и типы для описания контрактов классов.

Контекст фреймворка

• Angular: Классы — основа (компоненты, сервисы, директивы, пайпы). Строгая структура, определяемая фреймворком.
• React: После Hooks классы отошли на второй план, но остаются для Error Boundaries, случаев, требующих производительности (через PureComponent или shouldComponentUpdate), и сложных провайдеров контекста.
• Vue 3: Composition API уменьшил необходимость в классах, но TypeScript-проекты могут использовать классы с декораторами (например, vue-class-component).
• Svelte: Классы используются минимально, в основном для сторонних библиотек или утилит.

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