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

В то же время некомпактные конструкции автоматически не являются безнадежными или плохими. Некоторые предметные области просто являются слишком сложными, для того чтобы компактный дизайн мог их охватить. Иногда необходимо пожертвовать компактностью в обмен на некоторые другие преимущества, такие как большая мощность и диапазон. Разметка Troff, а также API BSD-сокетов являются хорошими примерами таких конструкций. Компактность как преимущество подчеркивается здесь не для того, чтобы заставить трактовать ее как абсолютное требование, а для того, чтобы научить читателей поступать подобно Unix-программистам: должным образом ценить компактность, по возможности использовать ее в конструкциях и не отбрасывать ее по неосторожности.

4.2.2. Ортогональность

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

Монитор компьютера имеет ортогональное управление. Яркость можно изменить независимо от уровня контрастности, а управление цветовым балансом не зависит от них обоих (если монитор имеет данную функцию). Представим, насколько более сложно было бы настраивать монитор, в котором регулятор яркости влиял бы на цветовой баланс: пришлось бы корректировать настройки цветового баланса каждый раз после изменения яркости. Еще хуже, если бы управление контрастностью также влияло на цветовой баланс. Пришлось бы манипулировать обоими регуляторами совершенно точно и одновременно, для того чтобы изменить по отдельности контраст или цветовой баланс при сохранении другого параметра постоянным.

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

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

В главе 9 рассматривается программа ascii, которая печатает синонимы для названий ASCII-символов, включая шестнадцатеричные, восьмеричные и двоичные значения. Побочный эффект программы заключается в том, что она может служить в качестве быстрого конвертера для чисел в диапазоне 0-255. Это второе ее применение не является нарушением ортогональности, поскольку все функции, поддерживающие его, необходимы для реализации основной функции; они не усложняют документирование или поддержку программы.

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

Превосходное обсуждение ортогональности и способов ее достижения приведено в книге "The Pragmatic Programmer" [37]. Как указывают ее авторы, ортогональность сокращает время тестирования и разработки, поскольку проверка кода, который не вызывает побочных эффектов и не зависит от побочных эффектов другого кода, упрощается, и следовательно уменьшается количество тестовых комбинаций. Если ортогональный код работает неверно, то его просто заменить другим без нарушения остальной части системы. Наконец, ортогональный код является более простым для документирования и повторного использования.

Идея рефакторинга (refactoring), которая впервые возникла как явная идея школы "экстремального программирования" (Extreme Programming), тесно связана с ортогональностью. Рефакторинг кода означает изменение его структуры и организации без изменения его видимого поведения. Инженеры программной индустрии, несомненно, решают эту проблему с момента возникновения отрасли, однако определение данной практики и идентификация главного набора методик рефакторинга способствовало решению данного вопроса. Поскольку все это хорошо согласуется с основными концепциями проектирования Unix, Unix-разработчики быстро переняли терминологию и идеи рефакторинга[42].