Зарегистрируйтесь для доступа к 15+ бесплатным курсам по программированию с тренажером

Пишем код правильно JS: Объектно-ориентированный дизайн

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

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

Возьмем принцип SRP (принцип единственной ответственности, S из SOLID). Он говорит следующее:

Должна быть ровно одна причина для изменения класса. Роберт Мартин.

Есть и другие формулировки, но это самая лаконичная. Что не так с этим принципом? Он очень общий. Звучит примерно как: нормально делай – нормально будет. Он не дает никаких формальных критериев, по которым можно понять, что в классе есть проблема. В статьях, посвященных этому принципу, всегда всё кажется логичным. Но только потому, что автор уже предложил разделение ответственностей. В реальной жизни всё было бы по-другому. Когда спрашиваешь разных людей об одних и тех же ситуациях, они дают совершенно разные, иногда противоположные ответы. По факту, всё сводится к некоторому внутреннему чутью конкретного программиста.

Возьмем для примера библиотеку выполнения HTTP запросов. С чего нужно начать ее проектирование?

Правильно начинать с вариантов использования. Представить себе как будто библиотека уже написана и мы пробуем ей воспользоваться (TDD толкает именно к этому, поэтому оно так мощно работает). Перед тем, как я покажу код, попробуйте ответить на вопрос, так ли нужны классы и ООП для реализации этой библиотеки?

HTTP-сессия — это операция, у которой есть конец и начало. Нужны ли объекты для ее выражения? Нет, конечно. Для операций достаточно функций. Поэтому наша библиотека в самом простом случае может выглядеть так:

import { get, post } from 'http-client';

let response = get('https://ru.hexlet.io/blog');
console.log(response.body);

response = post('https://ru.hexlet.io/users', {
  name: 'mira', email: 'mira@example.com',
});
console.log(response.statusCode);

Теперь, когда готов интерфейс библиотеки, можно приступать к её реализации. Насколько важно, как она выполнена внутри? Откровенно говоря, не важно. Внутренности останутся внутренностями, и никто про них не узнает, а их размер никогда не станет слишком большим (это всего лишь http библиотека). Это значит, что мы в любой момент можем их переписать. И делать это лучше не до, а после, когда накопится опыт поддержки и опыт использования. Только в этом случае появится настоящее понимание того, как лучше структурировать библиотеку внутри.

Генеральная идея звучит так: грамотная абстракция – ключ к успеху. Обозначьте границы, рассмотрите варианты использования и реализуйте как-нибудь.

Пример выше не взят с потолка, вы можете убедиться сами, что самая популярная http-библиотека axios в JavaScript — это действительно набор функций:

import axios from 'axios';

await axios.get('https://ru.hexlet.io/users');

await axios.post('https://ru.hexlet.io/users', {
  firstName: 'Fred',
  lastName: 'Flintstone',
});

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

import axios from 'axios';

const client = new axios.Axios({ timeout: 1000 });
const response = await client.get('https://ru.hexlet.io/lessons.rss');
console.log(response.statusCode);

Какими принципами нужно руководствоваться, чтобы понять внутреннюю архитектуру и количество классов? Для старта достаточно здравого смысла. У нас есть сам клиент, который представлен объектом (но его состояние – это конфигурация, а не запросы и ответы), и есть результат http-запроса. Результат представлен объектом, который возвращается после выполнения запроса. Внутри него хранится вся информация по взаимодействию с сервером, например, отправленные и принятые заголовки, код и тело ответа.

Дальнейшее разбиение не нужно. Возможно, это не понадобится никогда. А если и понадобится, то сначала нужно почувствовать такую необходимость, а затем уже реализовывать ее, когда появится боль. Причём главное основание для такого разделения – это не абстрактная единственная ответственность, а выделение чистого кода, который не связан с побочными эффектами.

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

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

import Reporter from './Reporter.js';

// Делать ли Reporter абстракцией данных (то есть объектом, описывающим конкретный отчет)
// или нет, это большой вопрос.
// По умолчанию так делать не стоит, иначе весь код превратится
// в бесполезное (new Reporter('path/to/file'))->generate()
const reporter = new Reporter();
const report = reporter.generate('/path/to/report');

На что стоит обратить внимание в первую очередь? На то, что этот класс одновременно выполняет грязную работу (с побочными эффектами): читает файл с диска, так и чистую: обрабатывает данные для формирования отчёта. Это не значит, что надо кидаться переписывать код, но это то, на что надо обращать внимание в первую очередь. Код выше сложнее в тестировании и отладке, чем код с разделенными операциями по побочным эффектам. Кроме того, если вынести чтение файла наружу, то репортер станет значительно более универсальным. Он сможет работать с данными, которые лежат не только на диске, но и были загружены каким-то другим способом, например, по http через форму. После несложных манипуляций получаем такой код:

import fs from 'fs';
import Reporter from './Reporter.js';

const reporter = new Reporter();
const data = fs.readFileSync('/path/to/report');
const report = reporter.generate(data);

Остальные принципы требуют знаний, которые приобретаются в следующем курсе: полиморфизм в js. Там они и рассматриваются.


Дополнительные материалы

  1. Снесите это немедленно (Андрей Аксенов). Доклад с конференции HighLoad.
  2. Архитектура и ООП

Аватары экспертов Хекслета

Остались вопросы? Задайте их в разделе «Обсуждение»

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

Ошибки, сложный материал, вопросы >
Нашли опечатку или неточность?

Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.

Что-то не получается или материал кажется сложным?

Загляните в раздел «Обсуждение»:

  • задайте вопрос. Вы быстрее справитесь с трудностями и прокачаете навык постановки правильных вопросов, что пригодится и в учёбе, и в работе программистом;
  • расскажите о своих впечатлениях. Если курс слишком сложный, подробный отзыв поможет нам сделать его лучше;
  • изучите вопросы других учеников и ответы на них. Это база знаний, которой можно и нужно пользоваться.

Об обучении на Хекслете

Для полного доступа к курсу нужен базовый план

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

Получить доступ
900
упражнений
2000+
часов теории
3200
тестов

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.

  • 130 курсов, 2000+ часов теории
  • 900 практических заданий в браузере
  • 360 000 студентов
Даю согласие на обработку персональных данных, соглашаюсь с «Политикой конфиденциальности» и «Условиями оказания услуг»

Наши выпускники работают в компаниях:

Логотип компании Альфа Банк
Логотип компании Aviasales
Логотип компании Yandex
Логотип компании Tinkoff
Рекомендуемые программы

С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.

Иконка программы Фронтенд-разработчик
Профессия
Разработка фронтенд-компонентов веб-приложений
25 мая 10 месяцев
Иконка программы Node.js-разработчик
Профессия
Разработка бэкенд-компонентов веб-приложений
25 мая 10 месяцев
Иконка программы Fullstack-разработчик
Профессия
Новый
Разработка фронтенд и бэкенд компонентов веб-приложений
25 мая 16 месяцев

Используйте Хекслет по максимуму!

  • Задавайте вопросы по уроку
  • Проверяйте знания в квизах
  • Проходите практику прямо в браузере
  • Отслеживайте свой прогресс

Зарегистрируйтесь или войдите в свой аккаунт

Даю согласие на обработку персональных данных, соглашаюсь с «Политикой конфиденциальности» и «Условиями оказания услуг»