Зададимся простым вопросом: зачем пишутся компьютерные программы? Большинство программ моделируют работу какого-либо объекта. Например, в реальном мире есть объект "зубчатая передача". Программа, рассчитывающая число зубьев, передаточное отношение, межцентровое расстояние и т.д. на самом деле моделирует работу настоящей пары шестеренок.
Чем сложнее моделируемый объект, тем большим количеством данных он описывается. Представьте, сколько информации нужно хранить для моделирования работы привода главного движения металлорежущего станка. При традиционном подходе к программированию в моделирующих программах появляется куча не связанных между собой переменных, описывающих свойства одного и того же объекта. Для зубчатого колеса параметрами будут являться модуль зубьев, число зубьев, толщина, посадочный диаметр. В итоге в программе появится что-то вроде:
VAR module, module1: REAL;
z, z1:WORD:
s, s1:REAL;
diam, diam1: REAL;
Выглядит все это запутанно и некрасиво. Переменные, относящиеся к одной и той же шестеренке, никак не связаны между собой, и легко перепутать diam и diam1.
Очевидный выход – использовать записи:
TYPE Tgear=RECORD
module:REAL;
z:WORD;
s:REAL;
diam:REAL
END;
VAR g1, g2 : Tgear;
Но этого недостаточно для моделирования: реальную шестеренку можно повернуть, нагрузить, остановить и т.д. Все действия над компьютерной моделью выполняются соответствующими процедурами и функциями. Казалось бы, дальше пути нет: переменные и процедуры – две принципиально разные вещи. Переменная – это "коробочка" в памяти, где хранится значение определенного типа, а процедура – последовательность кодов команд процессора.
По определению Н. Вирта, "Программы = алгоритмы + структуры данных". Увы, в рассматриваемом случае знака "плюс" не получается. Программа на Паскале жестко отделена от переменных (структур данных). Вот и получается, что относящиеся к одному объекту процедуры и функции раскиданы по всей программе:
VAR g1, ga :Tgear;
…
FUNCTION CalcRation(g1,g2:Tgear):REAL;
…
FUNCTION CalsLoad(g1:Tgear; Load: REAL):REAL;
…
Помимо очевидных трудностей с отладкой, есть и более серьезные проблемы. Значения переменных или полей записи, описывающих реальный объект, как правило, связаны между собой. Скажем, у нашей шестерни четко связаны модуль зубьев, их число и делительный диаметр. Однако ничто не мешает программисту просто забыть пересчитать один из этих параметров при изменении другого. В итоге на свет может появиться невиданная чудо-шестеренка диаметром 5мм, имеющая 120 зубьев с модулем 2,5.
Все эти проблемы многократно усугубляются при написании программ, управляющих работой сложных технических систем. При подготовке лунных экспедиций в 60-х гг. ХХ века впервые потребовалась разработка крайне сложного программного обеспечения, управлявшего бортовыми компьютерами межпланетного корабля Apollo и лунного посадочного модуля. Разумеется, требования к надежности программ были исключительно высоки: речь шла о жизнях космонавтов. Многочисленные трудности, с которыми столкнулись разработчики в ходе реализации лунной программы, дали толчок к исследованию ряда принципиально новых возможностей по радикальному повышению надежности программного обеспечения и избавлению от запутанности и громоздкости. Наилучшим решением, кардинально поменявшим ситуацию, стало создание объектно-ориентированного подхода (ООП).