Искусство программирования для Unix

Программисты ранней Unix стали мастерами модульности, поскольку были вынуждены сделать это. Операционная система является одним из наиболее сложных блоков кода. Если она не структурирована должным образом, то она развалится. Было несколько неудачных попыток построения Unix. Можно было бы отнести это на счет раннего (еще без структур) С, однако в основном это происходило ввиду того, что операционная система была слишком сложна в написании. Прежде чем мы смогли "обуздать" эту сложность, нам потребовалось усовершенствование инструментов (таких как структуры С)и хорошая практика их применения (например, правила Роба Пайка для программирования).

Кен Томпсон.

Первые Unix-хакеры решали данную проблему различными способами. В 1970 году вызовы функций в языках программирования были очень затратными либо ввиду запутанной семантики вызовов (PL/1, Algol), либо из-за того, что компилятор был оптимизирован для других целей, например, для увеличения скорости внутренних циклов за счет времени вызова. Таким образом, код часто писали в виде больших блоков. Кен и несколько других первых Unix-разработчиков знали, что модульность является хорошей идеей, однако они помнили о PL/1 и неохотно писали небольшие функции, чтобы не снизить производительность.

Деннис Ритчи поддерживал модульность, повторяя всем без исключения, что вызовы функций в С крайне, крайне малозатратны. Все начали писать небольшие функции и компоновать программы из модулей. Через несколько лет выяснилось, что вызовы функций оставались дорогими на PDP-11, а код VAX часто тратил 50 % времени на обработку инструкции CALLS. Деннис солгал нам! Однако было слишком поздно; все мы попались на удочку...

Стив Джонсон.

Всех сегодняшних программистов, пишущих для Unix или других операционных систем, учат создавать модули внутри программ на уровне подпрограмм. Некоторые учатся делать это на уровне модулей или абстрактных типов данных и называют это "хорошим программированием". Сторонники использования моделей проектирования прилагают благородные усилия для повышения уровня разработки и создают все новые успешные абстрактные модели, которые можно применять для организации крупномасштабной структуры программ.

Здесь авторы не предпринимают попытки слишком подробно осветить все вопросы, связанные с модульностью внутри программ: во-первых, потому, что данная тема сама по себе является предметом целого тома (или нескольких томов), и, во-вторых, ввиду того, что настоящая книга посвящена искусству Unix-программирования.

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

4.1. Инкапсуляция и оптимальный размер модуля

Первым и наиболее важным качеством модульного кода является инкапсуляция. Правильно инкапсулированные модули не открывают свое внутренне устройство друг другу. Они не обращаются к центральной части реализации друг друга, кроме того, они не используют глобальные данные беспорядочно. Они осуществляют связь друг с другом посредством программных интерфейсов приложений (API) — компактных, четких наборов вызовов процедур и структур данных. Именно об этом гласит правило модульности.

API-интерфейсам между модулями отведена двойная роль. На уровне реализации они функционируют как заслонка между модулями, которая предотвращает воздействие внутренних данных модулей на соседние модули. На уровне проектирования именно API-интерфейсы (а не описание структур данных между ними) действительно определяют структуру программ.