Инкапсуляция

Идея инкапсуляции, как явного разделения логики и реализации с целью сокрытия сложности, не нова в программировании. Сами языки высокого уровня скрывают детали реализации той машинной программы, в которой они транслируются. Пользовательские процедуры и функции скрывают детали алгоритма определения функции от самой функции. Той же цели служит фактически любое наименование. В рамках модульного и объектного программирования это понимается как разделение интерфейса, доступного пользователю, и реализации, ему не доступной. Это старая идея локализации, которая, правда, теперь приобретает относительный смысл: не только, что прятать, но и от кого прятать. Поставленная перед описанием опция private обеспечивает самую жёсткую локализацию, ограничивая доступ (область видимости) пределами модуля, в котором описан данный класс. Пользователь этого модуля не видит полей и методов private, обращение к ним объявляется синтаксической ошибкой. Опция public – напротив, расширяет область видимости не все модули, которые ссылаются на данный (как и опция по умолчанию - published).

Пример. Описание класса «Доска для рисования».

unit GridUnit;

interface

type tPosition=record

row, column: 1..nMax;

end;

tColor=(red, green, blue);

tIndex=1..nMax;

GridClass=class

Grid: array of array of tColor;

CurrentColor: tColor;

MaxPosition: integer;

CurrentPosition: tPosition; {текущая позиция}

{Добавляем средства чтения и записи полей. Это в прграммировании

называется set-get подходом}

procedure SetPosition (NewRow, NewColumn: tIndex);

procedure SetColor (NewColor: tColor);

procedure Get (var Row, Column: tIndex);

procedure GetColor (var Color: tColor);

end;

Замечание (*). Сейчас считается, что хороший стиль программирования исключает прямое обращение к полям класса.

Представление данных Данные как функции доступа Свойства

Последнее замечание (*) разделяет фактическое хранение данных и пользовательское представление о данных и возвращает к вопросу: «Что такое данные?»

Разделение логических и физических данных знакомо нам по СУБД (view). С другой стороны, оно заставляет нас пересмотреть некоторые вещи. А именно: «Что такое состояние?» С точки зрения процедурного программирования, состояние – это значения переменных, а объектного – несколько иное. К примеру, работаем с декартовыми координатами, а пользователю представляем как полярные.

Таким образом, иной взгляд на состояния (данные) предлагает их рассмотрение как процедуры, но не собственно функции. Идея пользовательского представления данных отражается в Delphi в виде понятия свойства (property) как виртуального (или пользовательского) поля.

property (имя свойства): (тип свойства) [дополнительные функции]

С точки зрения пользователя оно (property) не отличимо от поля. Точно так же он использует их в присваиваниях и других операторах. В реальности семантика свойства определяется двумя процедурами, записываемыми в его спецификации (на которые ссылается его спецификация).

[read (имя поля или метода)]

[write (имя поля или метода)]

Обе спецификации могут отсутствовать, делая свойство доступным только для чтения или только для записи. Опция «имя поля» означает тривиальное взаимно однозначное соответствие между фактическим и пользовательским. Вторая опция – ссылка на функцию, возвращающая значение указанного типа. Обычно подразумевается некоторое преобразование значений полей. В действительности это произвольная функция (например, random). Имя метода в спецификации write принимает значения указанного типа. Подразумевается, что он преобразует его в значения полей. (Данные – это то, что можно читать и записывать).