24.2. Объекты, классы, методы и сообщения

Ниже представлены некоторые основные термины и концепции объектного подхода, а именно — сами объекты (естественно), объектные классы, методы и сообщения. Там, где это возможно и уместно, данные понятия сравниваются с более знакомыми понятия­ми. Фактически в весьма приблизительной форме объектную терминологию вполне можно соотнести с терминологией традиционного программирования (рис. 24.3).

Объектный термин	Традиционный термин
неизменяемый объект изменяемый объект объектный класс метод сообщение	значение переменная тип данных оператор вызов оператора

Рис. 24.3. Объектная терминология (сводка)

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

тальным вопросам (в этом можно убедиться, прочитав работы [24.11], [24.48] и [24.52]). Например, не существует абстрактной, формально определенной "объектной модели данных", нет согласия даже в отношении неформальной модели. (Поэтому в данной кни­ге термин "объектная модель" приводится в кавычках.) Также, как это ни странно, нет четкого разграничения между уровнями абстракции, в частности (ключевого!) разграни­чения между самой моделью и ее реализацией. Напомним, что в главе 1 описано, в чем заключается различие между этими концепциями.

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

Обзор объектной технологии

Вопрос: Что такое объект? Ответ: Все что угодно!

Основной догмат объектного подхода — "объектом может быть все что угодно" (или иногда говорят "все что угодно — объект первого класса"). Одни объекты являются не­изменяемыми; в качестве примера можно привести числа (например, 3, 42) и символь­ные строки (например, "Mozart", "Экономика и бизнес"). Другие объекты — изменяе­мые; примерами могут служить объекты, представляющие отделы и служащих, которые упоминались в начале раздела 24.1. Согласно традиционной терминологии неизменяе­мые объекты соответствуют значениям, а изменяемые — переменным^ с произвольной внутренней сложностью (т.е. такие объекты могут содержать любое количество типов данных, имеющихся в обычных языках программирования, и конструкторов этих ти­пов — чисел, строк, списков, массивов, стеков и т.д.).

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

Каждый объект имеет тип (в объектной терминологии — класс). Отдельные объекты иногда называются экземплярами объектов, чтобы их можно было отличить от соответ­ствующего объектного типа или класса. Обратите внимание, что термин тип здесь ис­пользуется в смысле, принятом в традиционном программировании (как в главе 5), в ча­стности этот термин включает в себя и набор операторов (в объектной терминологии — методов), которые могут применяться для объектов данного типа.

Замечание. На самом деле в некоторых объектных системах понятия типов и классов различаются. Такие системы кратко будут рассмотрены в разделе 24.3; однако пока мы будем использовать эти понятия как взаимозаменяемые.

Объекты инкапсулированы. Это означает, что физическое представление, т.е. внутрен­няя структура объекта, например объекта DEPT (Отдел), остается скрытой от пользователей. В действительности пользователю известно только то, что объект в состоянии выполнять неко-

' Заметим, однако, что термин переменная без дополнительного уточнения в объектном контексте часто используется для обозначения такой переменной, которая содержит иденти­фикатор объекта (о чем пойдет речь далее в этом разделе).

торые операции ("методы")². Например, к объектам DEPT могут применяться методы HIRE_EMP (Нанять сотрудника), FIRE_EMP (Уволить сотрудника), CUT BUDGET (Урезать бюджет) и т.д. Также обратите внимание, что к данным объектам могут применяться ТОЛЬКО те операции, которые упомянуты среди этих методов. Доступ к внутреннему представлению таких объектов разрешен только коду, с помощью которого эти методы реализованы, т.е., употребляя жаргон, можно сказать, что эти и только эти методы могут "взломать инкапсули­рованный объект"³, если, конечно, данный код также невидим для пользователей.

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

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

. ² В литературе много путаницы связано с понятием инкапсуляции. Точка зрения, которая кажется наиболее разумной и которая предлагается в настоящей книге, формулируется так. Говорят, что объект инкапсулирован, если и только если это скаляр в смысле, подразумеваемом в главе 5 (т.е. если и только если он не имеет никаких видимых пользователем компонентов); по­этому инкапсулированный объект и скаляр означают одно и то же. Отметим, что определен­ные "коллекции" объектов (см. раздел 24.3), бесспорно, не являются скалярами, поэтому соглас­но предыдущему определению они не инкапсулированы. Некоторые авторы, напротив, категори­чески утверждают, что все объекты инкапсулированы, и такая точка зрения неизбежно приво­дит к определенным противоречиям. Остальные же считают, что, кроме требования, чтобы внутренняя структура была скрыта, это понятие подразумевает еще и требование, чтобы со­ответствующие методы были физически связаны с объектом или классом данного объекта, т.е. физически являлись его частью. Мы считаем, что в последней трактовке смешиваются понятия модели и ее реализации. И это, конечно, еще одна причина, по которой, как указывалось в главе 5, мы предпочли бы совсем не использовать термин "инкапсулированный". Однако в данной главе мы все же будем вынуждены время от времени к нему обращаться.

³ Мы бы рекомендовали следовать более строгим требованиям, приведенным в [3.3]. Допус­тимы только выборки и операторы ТНЕ_ (см. главу 5), которым разрешено нарушать инкапсу­ляцию в этом смысле. Все другие операторы должны быть реализованы в терминах данных вы­борок и операторов THE . Иными словами, используется защита кода. Но в объектных системах обычно предоставляются не операторы THE как таковые, а операторы "get and set" (получить и установить), которые не являются их точными аналогами (см. раздел 24.4 и статью [24.22]).

■ Закрытая память состоит из переменных экземпляра, которые также иногда называются членами или атрибутами. Их значения представляют внутреннее со­стояние данного объекта. В истинно объектной системе переменные экземпляра являются полностью защищенными и скрытыми от пользователей, однако, как было сказано выше, они доступны для методов. Здесь следует добавить, что мно­гие объектные системы не являются "чистыми" в этом смысле, поскольку разре­шают пользователям доступ к некоторым переменным экземпляра. К этому во­просу мы еще возвратимся в следующем подразделе.

■ Открытый интерфейс состоит из определений интерфейсов для методов данного объекта. Эти определения соответствуют тому, что в главе 19 мы называли сигна­турами определений. Однако, как будет показано ниже, в объектных системах обычно требуется, чтобы такие сигнатуры были связаны лишь с одним конкрет­ным "целевым" типом или классом. А в главе 19 ни о чем подобном не было и ре­чи, но мы не считаем, что такое требование необходимо или обязательно (см. [3.3]). Как уже отмечалось, код, который реализует методы объекта, как и пе­ременные экземпляра, скрыт от пользователя.

Замечание. Точнее говоря, открытый интерфейс представляет собой часть опре­деления класса рассматриваемого объекта, а не часть самого этого объекта. (Как бы там ни было, открытый интерфейс является общим для всех объектов данного класса, а не конкретным кодом в некотором отдельном объекте.) И для определе­ния класса данный объект является его отдельным экземпляром (как элемент ка­талога в обычной реляционной системе).

Методы вызываются с помощью сообщений, которые, по сути, являются вызовами функций и имеют единственный синтаксически выделенный аргумент— получатель, или цель. Например, ниже приводится сообщение, записанное с использованием гипоте­тического синтаксиса и предназначенное для передачи указания о приеме сотрудника Е на работу в отдел D.

D HIRE_EMP ( Е )

Аргументы D и Е будут рассмотрены в подразделе "Классы, экземпляры и коллекции". Получателем в этом примере является объект отдела, указанный как аргумент D. Соглас­но синтаксису традиционных языков программирования это же сообщение следовало сформулировать иначе⁴.

HIRE_EMP ( D, Е )

Для удобства в любой объектной системе обычно содержится некоторый набор встроенных классов и методов. В частности, в ней почти всегда присутствуют числовые (с методами "=", "<", "+", "-" и т.д.), символьные (с методами "=", "<", "||", S0BSTR и т.д.) и другие классы. Конечно, предоставляются возможности и для опытных пользователей, которые могут создать собственные классы и методы.

Переменные экземпляра

⁴ Выделение одного аргумента в качестве особого может упростить выполнение системой процесса связывания во время выполнения, который был описан в главе 19. Однако такой подход имеет и недостатки: по крайней мере, это может усложнить запись выполняемого кода для со­ответствующего метода. При традиционном подходе (конечно, если есть из чего выбирать, т.е. если есть несколько аргулгентов) целевой аргумент выбирается произвольно.

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

Предположим, что имеется объектный класс отрезков линии LINESEG. Будем считать, что каждый отрезок имеет начало (точка START) и конец (точка END). Чтобы "получить" значения координат этих точек для заданного сегмента Is, обычно используются выраже­ния наподобие Is.START и Is.END. Таким образом, START и END— открытые переменные экземпляра. Заметим, что по определению доступ к таким переменным должен осуществ­ляться с помощью специального синтаксиса (обычно используется точка после имени объ­екта, как в нашем примере). Если физическое представление отрезков линии заменить, на­пример, комбинацией координат средней точки (MIDPOINT), длины отрезка (LENGTH) и его наклона (SLOPE), в любой программе, которая содержит такие выражения, как Is.START и Is. END, возникнет ошибка. Другими словами, будет утрачена независимость данных.

Обратите внимание, что открытые переменные экземпляра не являются логически необходимыми. Предположим, что для получения значений переменных экземпляра от­резка линии определены методы GET_START, GET_END, GET_MIDPOINT, GET_LENGTH и GET_SLOPE. Тогда пользователь сможет "получить" значения координат начала, конца, средней точки отрезка Is, его длины и наклона, вызвав методы GET_START(Is), GET_END(2s), GET_MIDPOINT(Is), GET_LENGTH(Is) и GET_SLOPE(Is) соответственно. Од­нако в этом случае уже не имеет значения, каково действительное физическое представ­ление отрезка — вполне достаточно, чтобы при каждом его изменении соответствующим образом были изменены и GET-методы. Более того, не было бы ошибкой, если бы поль­зователю разрешалось применять выражения наподобие Is.START в качестве сокраще­ния для выражения вызова метода GET_START(Is). Обратите внимание, что для исполь­зования такого сокращения объект вовсе не обязательно должен содержать открытую переменную экземпляра START. К сожалению, в реальных системах обычно не придер­живаются такого подхода. Как правило, все открытые переменные экземпляра фактиче­ски отражают физическое представление объекта (по крайней мере частично, хотя могут существовать и некоторые дополнительные переменные экземпляра, которые являются действительно закрытыми). Поэтому в соответствии со сложившейся практикой будем считать, что, если не указано противное, объекты предоставляют определенные откры­тые переменные экземпляра, хотя это понятие логически излишне.

В связи со сказанным выше необходимо рассмотреть еще один практический случай. Предположим, что определенные аргументы (которые пользователь в первом приближении может считать аргументами — "переменными экземпляра") требуются для создания объектов специфического класса⁵. Однако отсюда вовсе не следует, что подобные "переменные экзем­пляра" могут применяться для любых целей. Пусть, например, для создания объекта отрезка линии необходимы значения координат точек START и END. Однако отсюда не следует, что всегда можно будет составить запрос, например, для получения сведений обо всех отрезках линий, которые имеют одни и те же заданные координаты точки START. Возможность выпол­нения такого запроса зависит от того, был ли определен подходящий для этого случая метод.

Рассматриваемые объекты должны быть, между прочим, изменяемыми (почему?).

Наконец следует отметить, что некоторые системы поддерживают особый вид пере­менных экземпляра, называемых защищенными. Если объекты класса С имеют защи­щенную переменную экземпляра Р, то эта переменная доступна только для методов, оп­ределенных для класса С, и для методов, определенных для любого подкласса (на любом уровне) класса С. Подклассы кратко описаны в подразделе 24.3.

Идентификатор объекта

Каждый объект обладает уникальным идентификатором объекта (object ID — OID). Такие примитивные ("неизменяемые") объекты, как целое число 3, являются самоиден-тифж1ирующимися, т.е. они сами являются собственными идентификаторами объекта. Изменяемые объекты, напротив, имеют в качестве идентификаторов адреса (концептуальные). Эти адреса можно использовать повсюду в базе данных как указатели (концептуальные) на данные объекты. Адреса объектов пользователю непосредственно не предоставляются, но они могут быть присвоены, например, программной переменной и переменным экземпляра в других объектах. Обсуждение этого вопроса будет продол­жено в разделах 24.3 и 24.4.

Кстати, отметим, что иногда можно встретить утверждения о том, что, с точки зрения пользователя, преимущество объектных систем заключается в абсолютной идентичности двух разных объектов, т.е. они могут быть дубликатами по отношению друг к другу, но отличаться своими идентификаторами. Однако, с точки зрения автора этой книги, по­добное утверждение обманчиво. Ибо каким же образом пользователь действительно сможет внешне различить оба объекта? (Более подробно этот вопрос описан в [5.3], [5.6] и особенно — в [24.19].)