Инструменты пользователя

Инструменты сайта


bb:redbook:301

Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

bb:redbook:301 [2018/11/30 01:13] (текущий)
Строка 1: Строка 1:
 +===== 3.1  Библиотеки и каркасы =====
 +
 +==== 1. Программные библиотеки ====
 +Для правильного понимания того, что есть каркас,​ стоит начать издалека.
  
 +В доисторические времена,​ когда программы были маленькими,​ а компьютеры большими формировались первые языки программирования. Одним из них стал уже многократно упомянутый Фортран ("​Формул транслятор"​). Не было чёткого разделения на физиков,​ математиков и программистов. Все считали делом чести что-нибудь запрограммировать (ещё бы, ведь первые компьютеры стоили лютые миллионы рублей;​ кто ещё даст развлечься с такими игрушками?​). Но очень скоро оказалось,​ что дело это не такое простое,​ нужно знать особенности работы компьютеров,​ их устройство,​ нужно знать сам язык программирования,​ да и такой, поначалу казавшийся,​ совсем несложный раздел знаний,​ как алгоритмика (от имени арабского учёного Аль Хорезми) -- оказался весьма сложным и зачастую не поддающимся алоритмизации. Или поддающимся,​ но требовавшим таких ресурсов компьютеров,​ что первые программисты просто отступали от их решения.
 +
 +Так или иначе, разные коллективы поначалу сталкивались с задачами примерно одинаковой сложности. Так например,​ один из первых компьютеров "​Марк-1"​ занимался всего-навсего тем, что рассчитывал баллистические таблицы для нужд военных (синусы,​ косинусы,​ притяжение,​ сопротивление воздуха,​ неосность снарядов,​ разные температуры воздуха на разных высотах и всё такое). Программы для вычисления подобных величин были написаны довольно быстро. Одни из них работали быстрее,​ другие чуть медленней,​ а третьи вовсе неправильно. Поначалу учёные обменивались текстами программ (и алгоритмами) совершенно свободно,​ без всяких копирайтов. По крайней мере, из того времени крупных скандалов до нас не дошло.
 +
 +Задачи решаемые с помощью ЦВМ постепенно усложнялись. Обмен алгоритмами и совершенствование ЦВМ приводило к тому, что алгоритмы постепенно были доведены до технического совершенства,​ и внести своё исправление в такой алгоритм -- знначит испортить его. Алгоритмы объединялись в объёмные книги, утверждались большим начальством,​ и являлись образцом для подражания (все эти алгоритмы,​ если кто не понял, были в лучшем случае ​ напечатаны на бумаге). И каждый раз при наборе алгоритма была вероятность внесения ошибки.
 +
 +В какой-то момент какой-то неизвестный программист сообразил:​ а зачем каждый раз набирать текст алгоритма,​ если можно его хранить в электронном виде? (на самом деле так все втихаря и делали,​ просто начальству не говорили). К этому моменту начали использовать разделение на модули, ​ но ещё оставалось несколько вопросов:​ надо было скрывать исходный текст (конечно,​ на самом деле -- не надо), надо было проверять целостность файлов (были придуманы контрольные коды -- crc16; crc32; md5). И на этом этап создания библиотек можно считать законченным.
 +
 +Суть библиотеки сводится к тому, что она содержит набор процедур/​функций,​ которые по мере необходимости подключаются к основной программе. До сих пор многие языки программирования не могут подключать отдельные процедуры,​ и подключают код библиотеки целиком. Это проблема жирных программ. Кроме того, зачастую подключение происходит с ошибками. Устаревшая документация,​ лень программиста и всякое такое. [↑]
 +
 +
 +==== 2. Программные каркасы ====
 +Постепенно в мир компьютеров пришли сетевые технологии и графические интерфейсы пользователя. Они чем-то похожи. Они уже по факту, -- есть. Изменять их можно, но очень дорого,​ либо изменять нельзя. Количество наработок к этому моменту было такое, что делать резкие телодвижения стало уже опасно. ​
 +
 +Компьютерные сети позволили подключать вычислительные мощности удалённых машин. Например,​ точное время по сети, файловые хранилища,​ электронная почта. Все такие явления получили название сервис:​ что-то полезное,​ что нельзя изменить. По сути, это всё ещё были библиотеки в машинном и запущенном виде. Но вот кто-то придумал сетевой чат. Все пишут на один сервер,​ и этот сервер рассылает всем новые сообщения. В самом начале,​ все клиенты самостоятельно опрашивали сервер. Понятно,​ что сервер был не очень рад тому, что его постоянно дёргают все подряд:​ "Эй! Мне там ничего получить не надо?"​. И в какой-то момент был придуман весьма полезный трюк: вместо того, чтобы бесконечно дёргать сервер,​ клиенту достаточно передать имя процедуры на самом клиенте,​ которое дёрнет сервер,​ когда будет необходимость. Такая техника была названа обратный вызов процедур (или, прямая калька с английского -- колбэк,​ или на сленге -- "​погонять колобка"​). Такой подход усложняет работу систем,​ но приводит к экономии вычислительных ресурсов и сетевого траффика. ​
 +
 +Как правило,​ графический интерфейс пользователя работает на той же машине,​ что и прикладная программа. Сложность заключается в том, что при таком разделении,​ программа больше не контролирует нажатие клавиш,​ перемещение мыши, готовность сетевых данных на ввод или вывод. Всё это теперь делают стандартные сервисы через фиксированные интерфейсы (заранее оговоренные процедурные вызовы,​ которые почти не меняются со временем). Такие интерфейсы получили название API (прикладные програмные интерфейсы,​ applications programming interface). ​ Большие программы сами обычно становятся представителями API, и это в целом удобно. Кроме того, в графических и других локальных сервисах также поддержаны обратные вызовы!!! Можно себе представить,​ какой серпентарий из себя представляет современная операционная система?​!!!
 +
 +Сложность программных систем нарастает снежным комом. Осознать сложность систем могут далеко не все программисты,​ руководители или директора. И в какой-то момент был придуман интересный ход: а давайте всю стандартную рутину (или хотя бы часть её) завернём таким образом,​ чтобы больше программист её не касался. Это сократит время разработки программ,​ уменьшить число совершаемых ошибок,​ станет более понятной поставленная задача,​ и методы её решения.
 +
 +Сказано-сделано. Практически все современные интегрированные среды разработки реализуют подобный подход в той или иной мере: Lazarus, Visual Studio, Delphi, BlackBox Component Builder, устаревший Visual Basic, Django, Qt, Gtk. Все позволяют строить графические интерфейсы,​ описывать обработчики событий,​ контролировать переменные при исполнении,​ подключать ресурсы,​ создавать дистрибутивы для распространения. Такие среды получили названия RAD IDE (быстрая разработка приложений с интегрированным окружением рабочего стола) и framework (грубый перевод "​рабочие слои",​ часто употребляется калька фреймворк,​ но далее по тексту будет использоваться слово каркас,​ как наиболее адекватное). Что такое фреймворк объяснить затруднительно. Каркас -- это то, на что можно опереться! Или чуть более официально:​ программный каркас -- это среда, которая облегчает программисту написание программ на основании предпоределённых ограничений,​ которые в свою очередь делают код более унифицированным (что облегчает взаимодействие с другими программами этого же каркаса) и не позволяют программисту поломать его же код. [↑]
 +
 +
 +==== 3. BlackBox Component Builder ====
 +Это замечательная среда, которая разработана в Швейцарии и распространяется по BSD-лицензии:​ "​Бери кто хочешь,​ делай что хочешь"​. Лицензия не запрещает заменить её на, например,​ GPL или приватную. Сам BlackBox (БлэкБокс) закрывать,​ или открывать под ещё более свободной лицензией смысла нет, так как он всё-равно доступен в сети свободно. А вот компоненты,​ разработанные с его помощью -- вполне могут представлять коммерческий интерес,​ и тут уже можно действовать на усмотрение разработчика. Можно публиковать исходные тексты,​ можно только уже в машинном виде, а можно вообще создать DLL/SO, и распространять в таком виде независимо от BlackBox (правда,​ с полной потерей того преимущества,​ что даёт БлэкБокс).
 +
 +К какому классу программного обеспечения следует отнести БлэкБокс?​ Вопрос не такой простой,​ как может показаться на первый взгляд. БлэкБокс представляет из себя все признаки RAD IDE: можно разрабатывать программы,​ можно компилировать,​ можно разрабатывать графические интерфейсы,​ просматривать и разрабатывать документацию.
 +
 +При распространении программ,​ обычно,​ БлэкБокс распространяется вместе с ними. И тут кроется кардинальное отличие!!! Lazarus, например -- самостоятельное приложение. И оно на столько огромное,​ что таскать его за каждой программой просто невозможно (например,​ вариант комплектации Lazarus -- Typhoon -- в распакованном виде занимем около 2,5 ГБ!!!) БлэкБокс вместе с программой едва переваливает за 50 МБ. И не стоит судить о полезности,​ смотря на размер! Если у пользователя уже есть соответствующая версия БлэкБокс -- достаточно скачать только саму программу. А это уже единицы мегабайт (если нет картинок,​ звука, видео). ​
 +
 +При работе программ внутри БлэкБокс,​ сам БэкБокс следит за согласованностью разных частей себя, и не позволит загрузить модуль,​ который приведёт к ошибке во всей программе! При необходимости,​ модули которые больше не нужны, БлэкБокс способен выгрузить. Т. е. БлэкБокс реализует существенную часть функций операционной системы!!!
 +
 +Так что, БлэкБокс это не просто RAD IDE, или набор библиотек. Это передовая среда, которая хоть и вносит свои ограничения,​ но помогает программисту жить и строить. Нет, это не песня.
 +
 +БлэкБокс -- это каркас!) [↑]
 +
 +
 +==== 4. Выводы ====
 +В первой части были даны первые сведения для комфортной работы в БлэкБокс. Теперь настала пора освоить каркас более детально и основательно. Ведь этот инструмент будет первым помощником и другом на пути создания программ промышленного качества. К изучению БлэкБокса следует отнестись с вниманием,​ не меньше чем к изучению основ Компонетного Паскаля. [↑]
 +
 +
 +[ ← Назад ] [ Вверх ↑ ] [ Далее → ]
bb/redbook/301.txt · Последние изменения: 2018/11/30 01:13 (внешнее изменение)