Основные положения объектно-ориентированного подхода

Идея ООП проста: надо объединить вместе и свойства объекта, и относящиеся к нему процедуры и функции.

Объектв программировании – структура данных, объединяющая переменные, называемые СВОЙСТВАМИ (PROPERTIES) и процедуры и функции, называемые МЕТОДАМИ (METHODS). Объект – близкий родственник записи.

Идея ООП была предложена в середине 70-х гг. ХХ века Керниганом и Ричи (США) и тогда же реализована в языках Object Pascal для Apple, С и операционной системе Unix.

Среди преимуществ объектного подхода:

- повышение производительности труда программистов;

- повышение надежности программ;

- возможность создания библиотек стандартных объектов (например, библиотека визуальных объектов VCL для Delphi).

Основной недостаток ООП – сложность реализации компиляторов для объектно-ориентированных языков.

Итак, в объекте заключены как данные, так и программный код для работы с этими данными (Рис. 4.1).

Рис. 8.2. Понятие объекта.

При написании объектно-ориентированной программы необходимо придерживаться принципа декомпозиции. Под декомпозицией понимается разбиение большой задачи на множество мелких. Это же относится и к файлам, из которых собирается программа. Увы, большинство начинающих программистов твердо убеждены - все, что они ни понапишут, надо обязательно запихнуть в один-единственный программный файл .pas. Delphi не запрещает размещать отдельные процедуры и функции в разных файлах – для этого и введены модули и файл проекта (с расширением dpr), в котором они все перечислены. Давайте будем придерживаться простого правила: каждому объекту – свой файл! (Рис. 4.2).

Рис. 8.3. Декомпозиция программы

А что, собственно говоря, писать в этих файлах? Например, вот что:

TYPE TO1=CLASS
….
END; { это объект как тип данных }

VAR a:TO1; { это переменная типа «объект»}

В Delphi объект как тип данных называется классом, чтобы не путать объектный тип данных и объекты-переменные.

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

TYPE имя_типа=CLASS
свойство1:тип1;
…
свойство N:типN;
заголовок_метода1;
…
заголовок_ методаM;
END;

В описании объектного типа всегда сначала идут свойства, а потом – методы. Почему? Потому что в методах используются свойства, а железное правило Паскаля гласит: "все упоминаемые в программе вещи должны быть предварительно описаны".

Интересная особенность описания методов состоит в том, что отдельно описывается заголовокметода (первая строчка, содержащая слова PROCEDURE или FUNCTION, список аргументов, для функции – тип возвращаемого значения), а отдельно – реализация метода, т.е. собственно исполняемый код процедуры или функции:

TYPE TO1=CLASS
a,b:REAL;
PROCEDURE PrintSum; { заголовок метода }
END;

….

PROCEDURE TO1.PrintSum; { реализация метода }

BEGIN
Label1.Caption:=FloatToStr(a+b)
END;

При этом в реализации перед именем метода через точку ставится имя типа. Такая запись (TO1.PrintSum) указывает на то, что процедура PrintSum существует не сама по себе, а внутри объектного типа TO1. Кстати, заголовок метода в описании типа и заголовок в его реализации должны буквально совпадать.