Многофайловые программы: библиотеки классов, интерфейс, реализация. Структура многофайловых приложений

При разработке достаточно больших программ бывает удобным разрабатывать программу не в виде одного файла, а в виде нескольких. В отдельном файле сохраняем функцию main(), подпрограммы — каждую в отдельном файле или группируем по назначению. Что это даёт? Подпрограмма, сохранённая в отдельном файле, может быть очень легко использована в другой программе. Достаточно будет только подключить к проекту новой программы файл с этой подпрограммой.

Библиотеки классов

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

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

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

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

Крайне важный пример библиотеки классов, который мы увидим в главе 15,
это Стандартная библиотека C++ (STL).

Обычно библиотека классов состоит из интерфейса (interface) и реализации
(implementation). Это две основные части, которые присутствуют практически
всегда. Рассмотрим их подробнее.

Интерфейс

Назовем того человека, который написал библиотеку классов, разработчиком
библиотеки, а того, кто использует эту библиотеку, — программистом.

Для того чтобы библиотеку можно было использовать, программисту необ-
ходим доступ к различным определениям, включая объявления классов. Они
представляют собой общедоступную часть библиотеки и обычно поставляются
в виде исходного кода в составе заголовочного файла с расширением.H. Обыч-
но этот файл включается в текст программы с помощью директивы #include.

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

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

Реализация

Если интерфейсную часть можно назвать фасадом здания, то реализация пред-
ставляет собой его внутренности. В контексте библиотеки классов реализация —
это содержимое классов. Как туристу, любующемуся архитектурными памятни-
ками, вовсе не обязательно знать, что находится внутри зданий, так и програм-
мисту не нужно вникать в то, как происходит внутренняя работа библиотечных
классов. К тому же разработчики библиотек в большинстве случаев просто не
предоставляют клиентам исходных кодов, так как они могут быть нелегально ис-
пользованы или изменены. Поэтому методы классов чаще всего поставляются в
виде объектных (.OBJ) или библиотечных (.LIB) файлов.

На рис. 13.1 показано, как соотносятся между собой компоненты многофай-
ловых систем.

Сборка программы.

Процесс создания программы из исходных файлов называется сборкой (building). Сборка включает в себя две стадии: компиляцию (compiling) и связывание (linking, другой перевод - компоновка).

Во время компиляции происходит создание объектных файлов (обычно с расширением.obj) из исходных (с расширением.cpp или.cc) и заговочных (с расширением.h). После того как скомпилировались объектные файлы в дело вступает компоновщик и связывает объектные и библиотечные файлы (c расширением.lib). В конце сборки, если ни компилятор, ни компоновщик не выдали ошибок, мы получем исполняемый файл (с расширением.exe).
Дополнительные файлы

Создайте новый проект (или даже решение). Создайте в нём файл pg. Добавьте ещё один исходный файл, например, sub_lib. В первый файл скопируйте всё содержимое pseudo_game из урока по структурам. Сейчас Вы можете запустить программу, она прекрасно работает. Два эти файла находятся в одном проекте и связываются компоновщиком в объектный файл. Эти два файла могут использовать общие переменные с помощью ключевого слова extern. Они могут использовать общие функции. Для этого в одном из них функция должна быть объявлена, а в другом определена. Чтобы использовать общие структуры в файлах, потребуется написать определения структур в каждом файле.

Заметьте, что файлы никак не связаны друг с другом: не нужно указывать о существовании файла sub_lib.cc в pg.cc, за нас это делает компоновщик.
Заголовочные файлы

Для облегчения взаимодействия между файлами используют заголовочные файлы (с расширением.h). Мы уже сталкивались с ними: с помощью директивы #inlude мы добавляли заголовчные файлы в наши программы. Напомню, что директива #include копирует содержимое заголовочного файла (вообще-то любого файла, который вы укажете), в файл где она вызывается. Угловые скобки говорят компилятору, что заголовочный файл нужно искать в специальных папках.

Давайте добавим заголовочный файл в нашу программу. Назовите его sub_lib.h. Имя этого файла может быть любым и оно необязано совпадать с именем второго исходного файла. для добавления заголовчного файла выберите File -> New -> File, а в открывшемся окне выберите Header file (.h). Присоедините его к проекту.

В заголовочный файл вынесите все директивы #include, определение структуры tank, определение перечисления cardinal_dirs, определения констант и объявления всех функций. Всё это удалите из первого файла и добавьте только одну строчку:

#inlcude "sub_lib.h";

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

В файл sub_lib.cc добавьте эту же директиву и скопируйте все функции кроме main() из файла pg.cc.

Ну вот в общем и всё! Программа работает: мы можем передвигаться по полю, у нас всё ещё кончается топливо, а наш болван всё так же жизнерадостно совершает броуновское движение.

Поиск по сайту: