8.1. Основные положения объектно-ориентированного подхода
Идея ООП проста: надо объединить вместе и свойства объекта, и относящиеся к нему процедуры и функции.
Объект в программировании – структура данных, объединяющая переменные, называемые СВОЙСТВАМИ (PROPERTIES) и процедуры и функции, называемые МЕТОДАМИ (METHODS). Объект – близкий родственник записи.
Идея ООП была предложена в середине 70-х гг. ХХ века Керниганом и Ричи (США) и тогда же реализована в языках Object Pascal для Apple, С и операционной системе Unix.
Среди преимуществ объектного подхода:
повышение производительности труда программистов;
повышение надежности программ;
возможность создания библиотек стандартных объектов (например, библиотека визуальных объектов VCL для Delphi).
Основной недостаток ООП – сложность реализации компиляторов для объектно-ориентированных языков.
Итак, в объекте заключены как данные, так и программный код для работы с этими данными (Рис. 8 .16).
Рис. 8.16. Понятие объекта.
При написании объектно-ориентированной программы необходимо придерживаться принципа декомпозиции. Под декомпозицией понимается разбиение большой задачи на множество мелких. Это же относится и к файлам, из которых собирается программа. Увы, большинство начинающих программистов твердо убеждены - все, что они ни понапишут, надо обязательно запихнуть в один-единственный программный файл .pas. Delphi не запрещает размещать отдельные процедуры и функции в разных файлах – для этого и введены модули и файл проекта (с расширением dpr), в котором они все перечислены. Давайте будем придерживаться простого правила: каждому объекту – свой файл! (Рис. 8 .17).
Рис. 8.17. Декомпозиция программы
А что, собственно говоря, писать в этих файлах? Например, вот что:
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. Кстати, заголовок метода в описании типа и заголовок в его реализации должны буквально совпадать.