Вооружившись знаниями, которые мы уже получили по ООП, давайте попробуем ответить на вопрос, как все же правильно писать и структурировать код в классовых языках.
В ООП считается, что набор принципов SOLID — это ответ на вопрос о том, как правильно писать код. Но жизнь показывает, что знание этих принципов слабо помогает хорошей организации кода.
Возьмем принцип SRP (принцип единственной ответственности, S из SOLID). Он говорит следующее:
Должна быть ровно одна причина для изменения класса
Есть и другие формулировки, но это самая лаконичная. Что не так с этим принципом? Он очень общий. Звучит примерно как: нормально делай – нормально будет. Он не дает никаких формальных критериев, по которым можно понять, что в классе есть проблема. В статьях, посвященных этому принципу, всегда все кажется логичным. Но только потому, что автор уже предложил разделение ответственностей. В реальной жизни все было бы по-другому. Когда спрашиваешь разных людей об одних и тех же ситуациях, они дают совершенно разные, иногда противоположные ответы. По факту, все сводится к некоторому внутреннему чутью конкретного программиста.
Возьмем для примера библиотеку для работы с датами и временем. С чего нужно начать ее проектирование?
Правильно начинать с вариантов использования. Представить себе как будто библиотека уже написана и мы пробуем ей воспользоваться (TDD толкает именно к этому, поэтому оно так мощно работает). Прежде чем мы перейдем к коду, попробуйте ответить на вопрос, так ли нужны классы и ООП для реализации этой библиотеки?
Получение текущего времени — это операция, у которой есть конец и начало. Нужны ли объекты для ее выражения? Нет, конечно. Для операций достаточно функций. Поэтому наша библиотека в самом простом случае может выглядеть так:
import { getCurrentTime } from 'dateTimeLib';
const currentTime = getCurrentTime();
console.log(currentTime); // => 2023-04-14T20:13:40.432+05:00
Теперь, когда готов интерфейс библиотеки, можно приступать к ее реализации. Насколько важно, как она выполнена внутри? Откровенно говоря, не так важно. Внутренности останутся внутренностями, и никто про них не узнает, а их размер никогда не станет слишком большим (это всего лишь библиотека для работы с датами и временем). Это значит, что мы в любой момент можем их переписать. И делать это лучше не до, а после, когда накопится опыт поддержки и опыт использования. Только в этом случае появится настоящее понимание того, как лучше структурировать библиотеку внутри.
Генеральная идея звучит так: грамотная абстракция – ключ к успеху. Обозначьте границы, рассмотрите варианты использования и реализуйте как-нибудь.
Пример выше не взят с потолка, вы можете убедиться в этом сами. Например, библиотека luxon для работы с датами и временем в JavaScript — это действительно набор функций:
import { DateTime } from 'luxon';
console.log(DateTime.now().toISO()); // => 2023-04-14T20:13:40.432+05:00
console.log(DateTime.now().toFormat('MMMM dd, yyyy')); // => April 14, 2023
С помощью этой библиотеки мы можем создать объект, но только с одной целью — чтобы запомнить конфигурацию внутри и таким образом избежать дублирования:
import { DateTime } from 'luxon';
const dateTime = new DateTime({ zoneName: 'Asia/Singapore', valid: true });
console.log(dateTime.toISO()); // => 2023-04-14T20:13:40.442+05:00
Какими принципами нужно руководствоваться, чтобы понять внутреннюю архитектуру и количество классов? Для старта достаточно здравого смысла. У нас есть сам клиент, который представлен объектом (но его состояние – это конфигурация, а не запросы и ответы), и есть результат функции получения времени.
Дальнейшее разбиение не нужно. Возможно, это не понадобится никогда. А если и понадобится, то сначала нужно почувствовать такую необходимость, а затем уже реализовывать ее, когда появится боль. Причем главное основание для такого разделения – это не абстрактная единственная ответственность, а выделение чистого кода, который не связан с побочными эффектами.
Внутри нашей библиотеки может быть код, который взаимодействует с системой, проверяет текущее время, а есть код, который работает с данными, приводит их в нормальный вид, чистит и как-то структурирует. В первую очередь, нужно отслеживать такой код и отделять его на уровне функций или методов. Любая операция, которая может быть чисто вычислительной, потенциальный кандидат на вынесение.
Еще один пример, где анализ побочных эффектов позволяет понять, как поступить правильно. В материалах по ООП часто говорят про класс, который отвечает за генерацию отчета. Предположим, что он работает так:
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. Там они и рассматриваются.
Дополнительные материалы
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
- Статья «Как учиться и справляться с негативными мыслями»
- Статья «Ловушки обучения»
- Статья «Сложные простые задачи по программированию»
- Вебинар «Как самостоятельно учиться»
Для полного доступа к курсу нужен базовый план
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
