Опубликован: 17.10.2005 | Доступ: свободный | Студентов: 8823 / 588 | Оценка: 4.38 / 4.10 | Длительность: 41:16:00
ISBN: 978-5-7502-0255-3
Специальности: Программист
Лекция 7:

Статические структуры: классы

Обозначение результата функции

Для понимания текстов функций rho, theta и distance в классе POINT необходимо еще одно соглашение.

Любой язык программирования, поддерживающий функции (подпрограммы, возвращающие результат) должен предусматривать нотацию, позволяющую установить в теле функции значение, возвращаемое в результате ее вызова. В качестве значения, возвращаемого функцией, в данной книге будет использоваться предопределенная сущность (entity) Result. (Полное определение сущности будет дано в конце этой лекции.)

Например, тело функции rho содержит следующее присваивание

Result := sqrt (x^2 + y^2)

Result - зарезервированное слово, которое может присутствовать только в теле функций. В функции, возвращающей результат типа T, Result рассматривается наряду с другими сущностями и ему может быть присвоено значение с помощью инструкций присваивания, как это показано выше.

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

non_negative_value (x: REAL): REAL is
         -- Возвращает значение аргумента при x>0; ноль при x<=0
      do
         if x > 0.0 then
            Result := x
         end
      end

будет всегда возвращать вполне определенное значение (как указано в комментарии к заголовку), несмотря на то, что условная инструкция не содержит части else.

Дискуссия в конце данной лекции обсуждает логику использования соглашения Result в сопоставлении с другими приемами, такими как инструкции возврата. Хотя это соглашение касается всех языков программирования, оно является особенно важным при ОО-подходе.

Правила стиля

Исходные тексты классов в данной книге строго подчиняются основным правилам стиля. Они регламентируют отступы, шрифты, выбор имен классов и их компонент, использование нижнего и верхнего регистров.

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

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

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

Наследование функциональных возможностей общего характера

Другим аспектом класса POINT, требующим разъяснений, является присутствие в функциях rho и distance вызовов функции sqrt. Понятно, что эта функция возвращает квадратный корень действительного числа, но откуда она появилась?

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

class POINT inherit
   ARITHMETIC
feature
   ... Остальная часть кода без изменений ...
end
Эта методика наследования функциональных возможностей общего характера является до некоторой степени спорной. Кто-то может полагать, что принципы ОО-подразумевают включение функций типа sqrt в качестве компонентов класса, которому принадлежит объект, например, REAL. Однако существует ряд операций с действительными числами, не все из которых стоит включать в данный класс. В дискуссии о принципах дизайна мы вернемся к вопросу о полезности "вспомогательных" классов, таких как ARITHMETIC. (См. "Наследование функциональных возможностей", лекция 6 курса "Основы объектно-ориентированного проектирования".)
Александр Шалухо
Александр Шалухо
Анатолий Садков
Анатолий Садков

При заказе pdf документа с сертификатом будет отправлен только сертификат или что-то ещё?