Оберон / Компонентный Паскаль / Вики

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
===== 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. Выводы ====
В первой части были даны первые сведения для комфортной работы в БлэкБокс. Теперь настала пора освоить каркас более детально и основательно. Ведь этот инструмент будет первым помощником и другом на пути создания программ промышленного качества. К изучению БлэкБокса следует отнестись с вниманием, не меньше чем к изучению основ Компонетного Паскаля. [↑]


[ ← Назад ]		 		[ Вверх ↑ ]					[ Далее → ]