Что означает буква S в SOLID?

Что означает буква S в SOLID?

Буква S в SOLID означает Single Responsibility Principle (Принцип единственной ответственности). Это первый и один из самых важных принципов чистого кода, который гласит: каждый модуль, класс или функция должен отвечать только за одно и только одно.

Определение

Модуль должен иметь одну причину для изменения. Если у модуля есть несколько причин меняться, значит он нарушает принцип SRP и нужно его разделить.

// ПЛОХО: Класс отвечает за слишком много
class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  // Ответственность 1: Управление данными пользователя
  getName() {
    return this.name;
  }

  // Ответственность 2: Отправка email
  sendEmail(message) {
    // ... код отправки email
    console.log(`Email отправлен пользователю ${this.email}`);
  }

  // Ответственность 3: Сохранение в БД
  saveToDatabase() {
    // ... код сохранения
    console.log(`Пользователь ${this.name} сохранён`);
  }

  // Ответственность 4: Логирование
  logActivity(action) {
    console.log(`${this.name} выполнил действие: ${action}`);
  }
}

const user = new User('John', 'john@example.com');
user.sendEmail('Welcome!');    // Отправка email
user.saveToDatabase();           // Сохранение в БД
user.logActivity('logged in');   // Логирование

Этот класс нарушает SRP из-за четырёх разных ответственностей!

Правильный подход: Разделение ответственности

// Класс отвечает ТОЛЬКО за данные пользователя
class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  getName() {
    return this.name;
  }

  getEmail() {
    return this.email;
  }
}

// Отдельный класс для отправки email
class EmailService {
  sendEmail(userEmail, message) {
    console.log(`Email отправлен на ${userEmail}: ${message}`);
  }
}

// Отдельный класс для сохранения данных
class UserRepository {
  save(user) {
    console.log(`Пользователь ${user.getName()} сохранён в БД`);
  }
}

// Отдельный класс для логирования
class Logger {
  log(message) {
    console.log(`[LOG] ${message}`);
  }
}

// Использование
const user = new User('John', 'john@example.com');
const emailService = new EmailService();
const repository = new UserRepository();
const logger = new Logger();

emailService.sendEmail(user.getEmail(), 'Welcome!');
repository.save(user);
logger.log('User logged in');

Теперь каждый класс отвечает за одно:

• User — только данные
• EmailService — только отправка email
• UserRepository — только работа с БД
• Logger — только логирование

В React компонентах

Принцип SRP применим и к React компонентам. Каждый компонент должен отвечать за одно.

ПЛОХО: Компонент делает слишком много

function UserProfile() {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [posts, setPosts] = useState([]);
  const [comments, setComments] = useState([]);

  // Ответственность 1: Загрузка пользователя
  useEffect(() => {
    fetch('/api/user')
      .then(r => r.json())
      .then(data => setUser(data))
      .finally(() => setLoading(false));
  }, []);

  // Ответственность 2: Загрузка постов
  useEffect(() => {
    fetch('/api/posts')
      .then(r => r.json())
      .then(data => setPosts(data));
  }, []);

  // Ответственность 3: Загрузка комментариев
  useEffect(() => {
    fetch('/api/comments')
      .then(r => r.json())
      .then(data => setComments(data));
  }, []);

  if (loading) return <div>Loading...</div>;

  return (
    <div>
      <h1>{user?.name}</h1>
      <div>
        {posts.map(post => (
          <div key={post.id}>
            <h2>{post.title}</h2>
            {/* Отображение комментариев к посту */}
          </div>
        ))}
      </div>
    </div>
  );
}

ХОРОШО: Разделение на отдельные компоненты

// Компонент отвечает ТОЛЬКО за отображение пользователя
function UserCard({ user, loading }) {
  if (loading) return <div>Loading...</div>;
  return <h1>{user?.name}</h1>;
}

// Компонент отвечает ТОЛЬКО за список постов
function PostList({ posts }) {
  return (
    <div>
      {posts.map(post => (
        <PostItem key={post.id} post={post} />
      ))}
    </div>
  );
}

// Компонент отвечает ТОЛЬКО за один пост
function PostItem({ post }) {
  return (
    <div>
      <h2>{post.title}</h2>
      <p>{post.content}</p>
    </div>
  );
}

// Контейнер отвечает ТОЛЬКО за логику загрузки
function UserProfile() {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [posts, setPosts] = useState([]);

  useEffect(() => {
    Promise.all([
      fetch('/api/user').then(r => r.json()),
      fetch('/api/posts').then(r => r.json()),
    ])
      .then(([userData, postsData]) => {
        setUser(userData);
        setPosts(postsData);
      })
      .finally(() => setLoading(false));
  }, []);

  return (
    <>
      <UserCard user={user} loading={loading} />
      <PostList posts={posts} />
    </>
  );
}

Преимущества SRP

1. Легче тестировать

// Чистый, заизолированный тест
describe('EmailService', () => {
  it('should send email correctly', () => {
    const service = new EmailService();
    const result = service.sendEmail('test@example.com', 'Hello');
    expect(result).toBe(true);
  });
});

2. Легче переиспользовать

const emailService = new EmailService();

// Использую в разных местах
emailService.sendEmail(user.email, 'Welcome!');
emailService.sendEmail(admin.email, 'New user registered');
emailService.sendEmail(support.email, 'Ticket created');

3. Легче менять и расширять

// Если нужно изменить способ отправки email,
// меняю ТОЛЬКО EmailService, остальной код не трогаю
class EmailService {
  sendEmail(email, message) {
    // Было: console.log
    // Теперь: использую SendGrid API
    sendgrid.send({
      to: email,
      subject: 'Notification',
      text: message,
    });
  }
}

4. Код более понятен

// Сразу понятно, что делает каждый класс:
const user = new User('John', 'john@example.com');
const emailService = new EmailService(); // Только отправка email
const repository = new UserRepository();   // Только работа с БД
const logger = new Logger();               // Только логирование

Когда нарушать SRP?

Обычно нарушать принцип SRP не стоит, но есть исключения:

// Может быть оправдано для очень простых utility функций
function formatAndLog(data) {
  const formatted = JSON.stringify(data);
  console.log(formatted);
}

// Лучше всё же разделить
function formatData(data) {
  return JSON.stringify(data);
}

function logData(data) {
  console.log(data);
}

Вывод

Single Responsibility Principle требует, чтобы каждый компонент, класс или функция отвечал за одно и только одно. Это делает код:

• Более тестируемым
• Более переиспользуемым
• Более гибким для изменений
• Более понятным и читаемым

Применение SRP — это ключ к написанию качественного, масштабируемого кода в JavaScript и особенно в React приложениях.