Что такое принцип единой ответственности (Single Responsibility Principle) и пример его применения

Что проверяют

Понимаете ли вы SRP как «одна причина для изменения», а не как «класс делает одну вещь». Во фронтенде это проверяется быстро: компонент, который сам ходит в сеть, сам хранит состояние и сам рисует разметку, правят и дизайнер, и бэкендер, и продуктовый аналитик. Спрашивают, умеете ли вы разрезать такой компонент осмысленно.

Как отвечать

Формулировка Мартина: у модуля должна быть одна причина для изменения, то есть один заказчик изменений. Не «одна функция», а один источник требований.

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

function OrderList() {
  const [orders, setOrders] = useState([])
  useEffect(() => {
    fetch("/api/orders")
      .then((r) => r.json())
      .then((d) => setOrders(d.filter((o) => o.total > 0)))
  }, [])
  return <ul>{orders.map((o) => <li key={o.id}>{o.title}</li>)}</ul>
}

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

Где спотыкаются

Дробят до бессмысленного. Компонент на три строки, который только прокидывает пропсы дальше, добавляет файл и импорт, но ни одной причины изменения не убирает.

Считают, что SRP относится только к классам. В React единица ответственности это компонент, хук, модуль утилит и слой доступа к данным, а классов может не быть вообще.

Режут по техническим слоям вместо предметных областей. Папки components, hooks и utils выглядят аккуратно, но правка одной фичи по-прежнему идёт в три места, то есть причина изменения осталась общей.