торые операции ( методы ). Например, к объектам 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 HIREJMP ( Е )

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

HIRE EMP ( D, Е )

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

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

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

Выделение одного аргумента в качестве особого может упростить выполнение системой процесса связывания во время выполнения, который был описан в главе 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(is), GET MIDPOINT(is), GET LENGTH(is) и GET SLOPE(is) соответственно. Однако в этом случае уже не имеет значения, каково действительное физическое представление отрезка - вполне достаточно, чтобы при каждом его изменении соответствующим образом были изменены и GET-методы. Более того, не было бы ошибкой, если бы пользователю разрешалось применять выражения наподобие is.START в качестве сокращения для выражения вызова метода GET START(is). Обратите внимание, что для использования такого сокращения объект вовсе не обязательно должен содержать открытую переменную экземпляра START. К сожалению, в реальных системах обычно не придерживаются такого подхода. Как правило, все открытые переменные экземпляра фактически отражают физическое представление объекта (по крайней мере частично, хотя могут сушествовать и некоторые дополнительные переменные экземпляра, которые являются действительно закрытыми). Поэтому в соответствии со сложившейся практикой будем считать, что, если не указано противное, объекты предоставляют определенные открытые переменные экземпляра, хотя это понятие логически излишне.

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

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

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