Использование динамически подключаемых библиотек (DLL, Dynamic Link Library)

1. Общие положения

1.1. Суть библиотек DLL

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

Это общие преимущества, предоставляемые любыми программными библиотеками. Их следствиями являются:

-     улучшение структуры и наглядности приложения за счет уменьшения длины кода (замены фрагмента кода вызовом библиотечной процедуры);

-     улучшение модифицируемости приложения за счет возможности модификации кода, вынесенного в библиотеку, без  изменения основной части приложения;

-     накопление результатов труда программистов.

Библиотеки DLL оформляются как файлы с расширением .dll.  В среде Delphi библиотеки по структуре схожи с библиотеками подпрограмм в языках программирования типа Фортран, C и C++. Размещаются библиотеки с расчетом на удобство использования: либо в текущем каталоге приложения (там, где расположен .exe-файл приложения), либо в системных каталогах Windows (стандартно – в Windows\System32). Если одна и та же библиотека используется несколькими приложениями, то она копируется в текущий каталог каждого из приложений.  

Библиотека подключается к приложению динамически, т.е. после его запуска, а не при компиляции. Основной вариант поиска библиотеки – сначала в текущем каталоге, затем в каталоге Windows\System32. В зависимости от настройки ОС при отсутствии библиотеки в указанных каталогах приложение может просто не работать, может производиться поиск в других каталогах либо выдаваться запрос на выбор библиотеки.

Мы рассмотрим вариант включения в библиотеку только процедур и функций.

1.2. Создание и использование библиотек DLL в среде Delphi

•• Выполнить команду File/New/Other/DLL Wizard. Создается пустая заготовка файла проекта библиотеки. Модуль библиотеки инициируется ключевым словом library со стандартным именем:

     library Project2;

     begin

     end.

•• Файлы и модули библиотек именуются по тем же правилам, что и модули Unit: имя модуля должно совпадать с именем файла, где этот модуль сохраняется. Это надо учитывать при переименовании библиотеки, т.е. сохранении ее под желаемым именем.

•• В раздел описаний вставить описания констант и типов, глобальных для процедур библиотеки.  В раздел процедур вставить описания процедур. Добавить раздел экспортируемых процедур:

          <список имен процедур>;

Получится следующее:

     library <имя библиотеки>;

     uses

          SysUtils,

          Classes;

     {$R *.res}

     < описани я констант и типов, глобальных для процедур>

     < описания процедур>

     // раздел экспортируемых процедур

     exports

     begin

     end.

•• Для изменения библиотеки (коррекции, добавления процедур) следует открыть проект, внести изменения, скомпилировать проект.

•• В программе, использующей библиотеку, в разделе описаний должны содержаться описания констант и типов, глобальных для процедур – такие же, как в библиотеке.

•• В разделе описания процедур программы каждая из процедур библиотеки описывается как импортируемая, или внешняя:

     <заголовок процедуры>;

     external  ‘<имя библиотеки>.dll’

1.3. DLL и разработка интерфейса

Здесь представляет интерес ситуация, когда некоторое приложение едино с точки зрения выполняемых функций, но должно иметь различные интерфейсы в различных использованиях (например, для разных классов пользователей). В таком случае должна быть обеспечена относительная автономность разработки компонентов, реализующих интерфейс, и интерфейсно-независимых компонентов, выполняющих обработку данных – «движок». Последний может быть занесен в библиотеку, и тогда по сути различные приложения могут использовать единую общую часть.

Такое разделение просто только на первый взгляд; это довольно нетривиальная задача уже в обычном программировании. Если же разные интерфейсы создаются с помощью инструментов разного уровня (например, средствами языка программирования и интегрированными визуальными средствами разработки приложений), то картина становится с ног на голову: различия в реализации в большой степени должны учитываться на уровне проекта. Методы здесь могут быть только эвристическими, а общие принципы остаются теми же, что при проектировании ПО в целом. Возможно, что «одно и то же приложение с разными интерфейсами» для одних задач окажется рациональнее выполнить программно как несколько независимых приложений, для других – с выделением разных интерфейсных и общей обрабатывающей части.

2. Пример использования DLL

Полностью два варианта приложения, использующих библиотеку, размещены в прилагаемых каталогах  primer_tema3vopr2dll и InterfForTopDown (архивы .rar). Цель приводимого ниже текста – пояснение основных моментов, касающиеся разработки библиотеки.  

2.1. Разработка процедуры, заносимой в библиотеку

В рамках задания по лабораторной работе № 4 для задачи top_down оформим обработку данных (т.е. собственно решение задачи) в виде процедуры и запишем в библиотеку DLL.

Будем базироваться на имеющейся разработке (см. курс «Технология разработки ПО», тема 3, вопрос 2). Здесь на уровне 0 проектирования алгоритма обработка совмещена с выводом результатов и представлена абстракцией А0.3:

     .......................

     {решение задачи} {вх.: n, b, m, a; вых.: a или maxmin}       

     А0.3. <решение задачи с выводом результатов по обр 3>

     .......................

Чтобы процедура решения была пригодна для использования во всех вариантах приложения (т.е. вариантах с разными интерфейсами), из нее следует убрать ввод-вывод.

Задача имеет три варианта решения, или три вида результатов, каждому из которых соответствует своя форма (см. уровень 1, задача А0.3):

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

Тогда абстракция A0.3 уровня 0 детализируется следующим образом:

     A0.3a <Решение задачи с фиксацией варианта решения>

     A0.3b <Анализ варианта решения и вывод по соответствующему образцу>

Разработка процедуры для задачи А0.3a выполняется обычным образом и приведена ниже.

1. Задача А0.3a

Если в одномерном целочисленном массиве b есть хотя бы два одинаковых элемента, то заменить первую строку матрицы a , все элементы которой больше нуля, на этот массив, иначе найти максимальное значение минимальных элементов строк матрицы.

2. Входные данные

цел n - число элементов массива b; число столбцов матрицы a; простая переменная;

цел b - исходный одномерный массив;

цел a - исходная матрица; двумерный массив.

Данные во внутреннем представлении (так как к моменту решения задачи А0.1 они введены); входная форма отсутствует.

3. Выходные данные

цел a - измененная матрица;

цел maxmin - максимальное значение минимальных элементов строк; простая переменная.

цел resvar – вариант решения;

                   1, изменение матрицы;

resvar =        2, поиск максимального значения минимальных элементов строк матрицы;

                   3, обработка не производится (ситуация, когда в массиве b есть хотя бы два одинако-                                         вых элемента, но в матрице нет строки со всеми положительными элементами)

Оформление процедуры

Ÿ Вид - общего вида

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

• Заголовок - проц reshenie (n, m, b,a, maxmin, resvar);

{поиск строки со всеми положит. элементами в матрице}

     арг