Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

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

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

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

4 <blockquote>Должна быть ровно одна причина для изменения класса

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

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

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

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

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

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

11 Пример выше не взят с потолка, вы можете убедиться в этом сами. Например, библиотека<a>luxon</a>для работы с датами и временем в JavaScript - это действительно набор функций:

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

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

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

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

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

17 На что стоит обратить внимание в первую очередь? На то, что этот класс одновременно выполняет:

18 <ul><li>Грязную работу (с побочными эффектами) - читает файл с диска</li>

19 <li>Чистую работу - обрабатывает данные для формирования отчета</li>

20 </ul>Это не значит, что надо кидаться переписывать код, но это то, на что надо обращать внимание в первую очередь. Код выше сложнее в тестировании и отладке, чем код с разделенными операциями по побочным эффектам.

21 Кроме того, если вынести чтение файла наружу, то репортер станет значительно более универсальным. Он сможет работать с данными, которые лежат не только на диске, но и были загружены каким-то другим способом, например, по http через форму. После несложных манипуляций получаем такой код:

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