Упарвление разрастающимися проектами с помощью пакетов, крейтов и модулей

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

Программы, которые мы писали до сих пор, располагались в одном файле одного модуля. По мере роста проекта, мы можем организовывать код иначе, разделяя его на несколько модулей и несколько файлов. Пакет может содержать несколько бинарных крейтов и (опционально) один библиотечный крейт. По мере роста пакета, вы можете выносить части программы в отдельные крейты, которые затем станут внешними зависимостями для основного кода нашей программы. Эта глава охватывает все эти техники. Для очень крупных проектов, состоящих из набора взаимосвязанных пакетов, развивающихся вместе, Cargo предоставляет рабочие пространства; мы рассмотрим их в разделе "Рабочие пространства Cargo" Главы 14.

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

Близкое к нашей текущей теме понятие — это область видимости: вложенный блок, в котором написан код, имеющий набор имён, определённых только в этой области. При чтении, разработке и компиляции кода, программистам и компиляторам необходимо знать, относится ли конкретное имя в определённом месте к переменной, функции, структуре, перечислению, модулю, константе или другому элементу и что он собой представляет. Можно создавать области видимости и определять то, какие имена они содержат и не содержат. Нельзя иметь два элемента с тем же именем в одной области видимости; для решения конфликтов имён есть некоторые инструменты.

Rust имеет ряд механизмов, которые позволяют управлять организацией кода, в том числе управлять тем, какие детали доступны снаружи, какие детали скрыты, и какие имена есть в каждой области видимости в вашей программе. Эти механизмы, иногда обобщённо называемые системой модулей, включают в себя:

• Пакеты — механизм Cargo, позволяющий собирать, тестировать и делиться крейтами
• Крейты — дерево модулей, которое создаёт библиотеку или исполняемый файл
• Модули и use — позволяют контролировать организацию частей кода, области видимости и скрытие путей
• Пути: способ именования элемента, такого как структура, функция или модуль

В этой главе мы рассмотрим всё перечисленное, обсудим их взаимодействие и объясним, как использовать их для управления областями видимости. К концу у вас должно появиться солидное понимание системы модулей и умение работать с областями видимости на уровне профессионала! (Примечание переводчика: материал этой главы может сломать вам мозг. Настоятельно рекомендуется самостоятельный поиск дополнительных материалов. Hang in there!)