Одна функция — одна програама

Старый добрый UNIX-подход: «одна функция — одна программа» сейчас
многими забыт. В основном это связано с тем, что большинство нынешних
пользователей и разработчиков под Linux имели до этого опыт работы с
Windows, где принято использовать совершенно другой подход.

В Windows изначально не было столь простых и развитых средств IPC как
в Linux. Фактически использовались в основном семафоры и shared
memory.

Самым простым способом создать код, который мог бы использоваться из
разных программ в Windows всегда были dll.

В последующем также были добавлены стандартизированные подходы к
разработке повторно используемых компонентов (COM). Так что если
программисту было нужно встроить какую-то компоненту другого
приложения в свое – он просто использовал готовый компонент.

В Linux же изначально главным средством IPC были pipes, а также unix
sockets. Их использование крайне просто, и если программа написана
так, что с ней удобно взаимодействовать через pipe, то часто даже не
требуется документация – все просто очевидно.

Главная особенность такого подхода – надежность и безопасность. В
случае ошибки в подгружаемой dll, может упасть приложение целиком.

Также это ненадежно с точки зрения безопасности – уязвимость в любой
dll, делает уязвимой всю программу, какие бы меры предосторожности не
принимались.

Однако такого подхода есть два серьезных плюса:

1. Использовать библиотеки из программ написанных на C/C++ проще, чем
писать код взаимодействия с другой программой через pipe;
2. Использование библиотеки требует меньше накладных расходов на
реализацию протокола обмена данных – следовательно это банально
быстрее.

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

А накладные расходы на реализацию протокола в большинстве приложений
(за исключением тех, где передаются значительные объемы данных – как в
multimedia приложениях, например) незначительны, и уменьшение
производительности на доли процента ради увеличения надежности кода, а
также упрощения его написания и поддержки, по моему мнению вполне
разумно.

Причем упрощение поддержки кода приводит часто к тому, что в целом его
производительность становится лучше.

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

В серверных приложениях до этого подхода уже давно, к счастью,
додумались. Тот же postfix отличный пример именно такого подхода.
Собственно во многом благодаря этому он один из самых безопасных, и
успешно вытеснил остальные сервера, став стандартом де-факто вместо
sendmail.

 

Запись опубликована в рубрике Новости. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Оставьте эти два поля как есть:

Защищено Invisible Defender. Показывать 403 для 308 104 плохих парней.