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

Подключаемые подпрограммы используются для осуществления множества специализированных преобразований. В число таких преобразований входят: обработка карты цветов, размывание границ и очистка изображения; чтение и запись форматов, не характерных для ядра GIMP; такие расширения, как редактирование мультипликации и тем оконных менеджеров; многие другие виды обработки изображений, которые могут быть автоматизированы с помощью сценариев, содержащих логику обработки изображений в ядре GIMP. Перечень подключаемых подпрограмм для GIMP доступен в World Wide Web.

Несмотря на то, что большинство подключаемых подпрограмм для GIMP являются небольшими и простыми С-программами, существует также возможность написать подпрограмму, которая открывает библиотечный API-интерфейс для языков сценариев. Данная возможность описывается в главе Ив ходе изучения модели "многопараметрических (polyvalent) программ".

GIMP

Рис. 4.2. Связи между вызывающей и вызываемой программой в редакторе GIMP с загруженной подключаемой подпрограммой

4.5. Unix и объектно-ориентированные языки

С середины 80-х годов прошлого века большинство новых конструкций языков обладают собственной поддержкой объектно-ориентированного программирования (Object-Oriented Programming — 00). Напомним, что в объектно-ориентированном программировании функции, воздействующие на определенную структуру данных, инкапсулируются вместе с данными в объект, который может рассматриваться как единое целое. В противоположность этому, модули в не-ОО-языках делают связь между данными и воздействующими на них функциями весьма второстепенной, и модули часто воздействуют на данные и внутреннее устройство других модулей.

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

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

Выше отмечалось, что Unix-традиция модульности является традицией тонкого связующего, минималистского подхода с несколькими уровнями абстракции между аппаратным обеспечением и объектами верхнего уровня программ. Частично это является влиянием языка С. Моделирование истинных объектов в языке С обычно сопряжено с большими усилиями. Вследствие этого нагромождение уровней абстракции является утомительным. Поэтому иерархии объектов в С склонны к относи-тельной простоте и прозрачности. Даже применяя другие языки, Unix-программис- | ты склонны переносить стиль использования тонкого связующего уровня и простой I иерархии, которому они научились, используя Unix-модели.

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

Все ОО-языки несколько склонны "втягивать" программистов в ловушку избыточной иерархии. Объектные структуры и браузеры объектов не являются заменой хорошего дизайна или документации, но часто рассматриваются как таковые. Чрезмерное количество уровней разрушает прозрачность: крайне затрудняется их просмотр и анализ ментальной модели, которую по существу реализует код. Всецело

нарушаются правила простоты, ясности и прозрачности, а в результате код наполняется скрытыми ошибками и создает постоянные проблемы при сопровождении.