Какую применяешь методологию написания классов?

Моя методология написания классов в JavaScript/TypeScript

Как frontend-разработчик с более чем 10-летним опытом, я выработал комплексную методологию работы с классами, которая эволюционировала вместе с экосистемой JavaScript. Вот основные принципы, которых я придерживаюсь:

Композиция вместо наследования

Я предпочитаю композицию классическому наследованию, особенно в UI-компонентах. Это соответствует принципам React и современных фреймворков:

// ПЛОХО: глубокое наследование
class Button extends BaseComponent {
  // ...
}

class IconButton extends Button {
  // ...
}

// ХОРОШО: композиция через HOC или хуки
const withIcon = (Component) => {
  return function IconEnhanced(props) {
    return (
      <Component {...props}>
        <Icon name={props.iconName} />
        {props.children}
      </Component>
    );
  };
};

// Или использование хуков для переиспользования логики
const useButtonLogic = () => {
  const [isLoading, setIsLoading] = useState(false);
  
  const handleClick = async () => {
    setIsLoading(true);
    // Логика обработки
    setIsLoading(false);
  };
  
  return { isLoading, handleClick };
};

Принцип единственной ответственности (SRP)

Каждый класс должен решать только одну задачу. В контексте фронтенда это особенно важно:

// ПЛОХО: класс делает слишком много
class UserManager {
  fetchUser() { /* API запрос */ }
  validateUser() { /* валидация */ }
  renderUserCard() { /* отрисовка UI */ }
  saveToLocalStorage() { /* работа с хранилищем */ }
}

// ХОРОШО: разделение ответственности
class UserService {
  async fetchUser(id: string) { /* только API логика */ }
}

class UserValidator {
  validate(user: User) { /* только валидация */ }
}

class UserStorage {
  save(user: User) { /* только работа с хранилищем */ }
}

Иммутабельность и чистота

Для state-менеджмента и бизнес-логики я предпочитаю иммутабельные подходы:

class ShoppingCart {
  private items: CartItem[];
  
  constructor(items: CartItem[] = []) {
    this.items = [...items]; // Копируем массив, не мутируем оригинал
  }
  
  addItem(newItem: CartItem): ShoppingCart {
    // Возвращаем НОВЫЙ экземпляр вместо мутации
    return new ShoppingCart([...this.items, newItem]);
  }
  
  removeItem(itemId: string): ShoppingCart {
    return new ShoppingCart(
      this.items.filter(item => item.id !== itemId)
    );
  }
}

Dependency Injection для тестируемости

Я активно использую dependency injection для создания легко тестируемых классов:

interface IApiClient {
  get(url: string): Promise<any>;
  post(url: string, data: any): Promise<any>;
}

class ProductService {
  constructor(private apiClient: IApiClient) {}
  
  async getProducts(): Promise<Product[]> {
    // Теперь легко мокать apiClient в тестах
    return this.apiClient.get('/api/products');
  }
}

// В production коде
const realService = new ProductService(realApiClient);

// В тестах
const mockApiClient = { get: jest.fn() };
const testService = new ProductService(mockApiClient);

Паттерны для UI-компонентов

Для React-компонентов я применяю следующие паттерны:

• Контейнерные и презентационные компоненты (с появлением хуков стал менее строгим, но концептуально сохраняется)
• Custom hooks для переиспользования логики
• Compound components для сложных интерактивных элементов

// Compound Components паттерн
class Tabs extends React.Component {
  static Tab = ({ children, isActive }) => (
    <div className={`tab ${isActive ? 'active' : ''}`}>
      {children}
    </div>
  );
  
  static Panel = ({ children, isActive }) => (
    isActive && <div className="tab-panel">{children}</div>
  );
  
  render() {
    return React.Children.map(this.props.children, child => {
      return React.cloneElement(child, {
        isActive: this.props.activeTab === child.props.name
      });
    });
  }
}

// Использование
<Tabs activeTab="profile">
  <Tabs.Tab name="profile">Профиль</Tabs.Tab>
  <Tabs.Panel name="profile">Содержимое профиля</Tabs.Panel>
</Tabs>

TypeScript и строгая типизация

Я всегда использую TypeScript для работы с классами, что дает:

• Автодополнение и безопасность рефакторинга
• Контракты через интерфейсы
• Защиту от runtime-ошибок

// Четкие интерфейсы для контрактов
interface IRepository<T> {
  findById(id: string): Promise<T | null>;
  save(entity: T): Promise<void>;
  delete(id: string): Promise<boolean>;
}

// Абстрактный базовый класс с общей логикой
abstract class BaseRepository<T> implements IRepository<T> {
  constructor(protected collectionName: string) {}
  
  abstract findById(id: string): Promise<T | null>;
  
  async save(entity: T): Promise<void> {
    // Общая логика сохранения
    await this.validate(entity);
    // Специфичная логика в наследниках
  }
  
  protected abstract validate(entity: T): Promise<void>;
}

Практические рекомендации

В своей работе я следую таким правилам:

1. Избегайте мега-классов - если класс превышает 300 строк, вероятно, его нужно разделить
2. Приватные поля - используйте #privateField (новый синтаксис) или TypeScript модификаторы
3. Статические методы только для утилит - не смешивайте инстанс-логику и статическую
4. Фабричные методы вместо сложных конструкторов - если создание объекта нетривиально
5. Декомпозиция сложных методов - каждый метод должен делать одно действие

// Фабричный метод для сложного создания
class ChartConfiguration {
  private constructor(private options: ChartOptions) {}
  
  static createForDashboard(): ChartConfiguration {
    return new ChartConfiguration({
      type: 'line',
      interactive: true,
      refreshRate: 5000
    });
  }
  
  static createForReport(): ChartConfiguration {
    return new ChartConfiguration({
      type: 'bar',
      interactive: false,
      refreshRate: 0
    });
  }
}

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