1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами

1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами

Если разрабатываемые программы не способны взаимодействовать друг с другом, то очень трудно избежать создания сложных монолитных программ.

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

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

Текстовые потоки для Unix-инструментов являются тем же, чем являются сообщения для объектов в объектно-ориентированной среде. Простота интерфейса текстовых потоков усиливает инкапсуляцию инструментальных средств. Более сложные формы межпроцессного взаимодействия, такие как удаленный вызов процедур (remote procedure call), демонстрируют тенденцию к использованию программ с сильными внутренними зависимостями друг от друга.

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

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

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

Данная проблема подробнее обсуждается в главе 7.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

Как бороться с вирусами и другими вредоносными программами

Из книги Интернет-разведка [Руководство к действию] автора Ющук Евгений Леонидович

Как бороться с вирусами и другими вредоносными программами Вирус.Компьютерный вирус – это программа или программный код, введенные и запущенные на компьютере без ведома пользователя и приводящие к нарушению нормального функционирования системы, в том числе


1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами Как однажды заметил Браян Керниган, "управление сложностью является сущностью компьютерного программирования" [41]. Отладка занимает большую часть времени разработки, и выпуск


1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей

Из книги Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ автора Мейерс Скотт

1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей В разделе "Что в Unix делается неверно" отмечалось, что разработчики системы X Window приняли основное решение о реализации "механизма, а не политики". Такой подход был направлен на


1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

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


1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы

Из книги PGP: Кодирование и шифрование информации с открытым ключом. автора Левин Максим

1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы Данное правило также широко известно под названием "Принцип наименьшего удивления" (Principle of Least Astonishment).Простейшими в использовании


1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"

Из книги Цифровой журнал «Компьютерра» № 169 автора Журнал «Компьютерра»

1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути" Даже наилучшие программные инструменты ограничены воображением своих создателей. Никто не обладает умом, достаточным для оптимизации всего или для предвидения всех возможных


Правило 38: Моделируйте отношение «содержит» или «реализуется посредством» с помощью композиции

Из книги 101 совет по работе в социальных сетях автора Соломатина Ольга

Правило 38: Моделируйте отношение «содержит» или «реализуется посредством» с помощью композиции Композиция – это отношение между типами, которое возникает тогда, когда объект одного типа содержит в себе объекты других типов. Например:class Address {...}; // адрес проживанияclass


1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами

Из книги автора

1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами Как однажды заметил Браян Керниган, "управление сложностью является сущностью компьютерного программирования" [41]. Отладка занимает большую часть времени разработки, и выпуск


1.6.3 Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами

Из книги автора

1.6.3 Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами Если разрабатываемые программы не способны взаимодействовать друг с другом, то очень трудно избежать создания сложных монолитных программ.Традиция Unix


1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей

Из книги автора

1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей В разделе "Что в Unix делается неверно" отмечалось, что разработчики системы X Window приняли основное решение о реализации "механизма, а не политики". Такой подход был направлен на


1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой

Из книги автора

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


1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы

Из книги автора

1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы Данное правило также широко известно под названием "Принцип наименьшего удивления" (Principle of Least Astonishment).Простейшими в использовании являются


1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"

Из книги автора

1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути" Даже наилучшие программные инструменты ограничены воображением своих создателей. Никто не обладает умом, достаточным для оптимизации всего или для предвидения всех возможных


Опции команд, которые   могут использоваться в комбинации с другими опциями.

Из книги автора

Опции команд, которые   могут использоваться в комбинации с другими опциями. Для получения зашифрованного файла в формате ASCII Radix-64 добавьте опцию -а при шифровании или подписании сообщения или извлечения ключа:pgp –sea textfile her_useridили: pgp –kxa userid keyfile [keyring]Для полного удаления


Эзоп и Ксанф: О том, как действительно разумные системы будут взаимодействовать со своими простодушными повелителями Михаил Ваннах

Из книги автора

Эзоп и Ксанф: О том, как действительно разумные системы будут взаимодействовать со своими простодушными повелителями Михаил Ваннах Опубликовано 18 апреля 2013 Когда слышишь про проблемы с компьютером, то первая реакция – узнать, а что именно


10 советов о smm-специалистах, которые будут вести ваши страницы

Из книги автора

10 советов о smm-специалистах, которые будут вести ваши страницы 1. Хороший smm-специалист отлично разбирается в вашем продукте или услугах, рынке на котором вы работаете. Кроме того, он хорошо пишет — как с точки зрения изложения информации, так и с точки зрения