От структур и подпрограмм к объектам.

Целями структурного программирования являлись структуризация данных и декомпозиция кода. Объединение данных в структуры позволяло, с одной стороны, более естественно описывать сущности реального мира, имеющие самые разнотипные наборы атрибутов. А, с другой стороны, делало процесс разработки программ более простым, поскольку однородные данные были сгруппированы в одном месте и под одним общим именем.

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

Такое решение не только повышало надежность программ, но и позволяло многократно использовать одни и те же подпрограммы в различных программах. Как следствие, стали появляться библиотеки подпрограмм, как самостоятельные программные продукты. Часть библиотек поставлялась вместе с компиляторами с языков программирования и операционными системами, другая часть распространялась свободно или на коммерческой основе. Применение библиотек существенно ускоряло процесс разработки программного обеспечения, так как подпрограммы, применяемые многократно, требовалось отлаживать только единожды.

Локализация данных имела ничуть не меньшее значение, чем локализация кода. Три вида данных в подпрограмме:

Локальные данные подпрограммы, которые автоматически создавались при ее вызове и уничтожались при возврате из подпрограммы;

Локальные данные, сохраняемые между несколькими вызовами одной подпрограммы;

Глобальные данные, доступные нескольким или всем подпрограммам, и доступ к которым осуществлялся прямо из подпрограммы;

Фактические параметры, передаваемые подпрограммам, замещающие объявленные формальные параметры.

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

В отличие от этого, локальные данные, наоборот, позволяли подпрограмме быть независимой от программ, использующих ее. Но они не обеспечивали передачу данных между различными подпрограммами. Для передачи данных или ссылок на них использовался механизм формальных/фактических параметров. При описании подпрограммы объявляются формальные параметры, которые она принимает при вызове. Когда реально происходит вызов подпрограммы, на место формальных параметров подставляются фактические параметры того же типа.

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

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

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

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

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

Если теперь сложить все элементы полученной мозаики воедино, то получится знакомая картина: все подпрограммы модуля собраны вместе по функциональному признаку и работают над одними данными; модуль имеет области кода, которые вызываются при инициализации и окончании работы модуля. Такой модуль можно назвать прообразом объекта.

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