Основы объектно-ориентированного программирования

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

Однажды я невольно провел один небольшой эксперимент, который хорошо иллюстрирует такое состояние дел. Как-то, когда в курсе, который я читал, пришло время готовить проекты, я решил предоставить студентам нечто вроде анонимного рынка, куда бы они могли помещать шутливые объявления о продаже программных модулей, не раскрывая их источников. (Идея, хорошая или не очень, состояла в том, чтобы процесс выбора модулей происходил только на основе точных спецификаций их возможностей.) Почтовые средства знаменитой операционной системы, предпочитаемой американскими университетами, казалось бы, предоставляли соответствующий базовый механизм, но, естественно, эта почтовая система показывала имя отправителя при доставке сообщения получателям. У меня был доступ к исходному коду - огромной программе на Си, и я решил, наверное, по глупости, взять этот код, убрать в нем все ссылки на имя отправителя в доставляемых сообщениях и перекомпилировать. С помощью своего ассистента я взялся за работу, казавшуюся достаточно очевидной, хотя ей и не учат в курсах по разработке ПО, - систематическую разборку программы. Будучи уверенными в себе, мы быстро нашли первое место, в котором программа обращалась к имени отправителя, и удалили соответствующий код. После чего наивно решили, что работа сделана, и перекомпилировали код. Но когда мы послали тестовое сообщение, то обнаружили, что имя отправителя все еще сохранилось! После чего начался долгий и сюрреалистический процесс: снова и снова, веря, что мы, наконец, обнаружили последнее обращение к имени отправителя, мы удаляли его, перекомпилировали программу и посылали тестовое сообщение, чтобы в очередной раз исправно обнаружить имя отправителя на обычном месте. Как знаменитая стоглавая гидра, почтовая программа отращивала новую голову всякий раз, когда мы считали, что отрубили ей последнюю. Наконец, повторив в нашу эру древний подвиг Геракла, мы полностью уничтожили этого зверя, удалив более двадцати участков кода, каждый из которых, так или иначе, задавал информацию об отправителе.

В предыдущих разделах нам удалось сделать первые шаги по дороге к АТД. Их достаточно для понимания того, что программа, написанная в соответствии с самыми элементарными представлениями об абстракции данных, должна была бы рассматривать MAIL_MESSAGE (ПОЧТОВОЕ_СООБЩЕНИЕ) как точно определенное абстрактное понятие. Одной из операций сообщения мог быть запрос, называемый, например, sender (отправитель), возвращающий информацию об отправителе сообщения. Любой элемент почтовой программы, которому была бы нужна эта информация, получал бы ее только через этот запрос sender. Если бы почтовая программа была разработана в соответствии с этим, кажущимся очевидным, принципом, то для моего небольшого упражнения достаточно было бы изменить только код запроса sender. Более того, весьма вероятно, что в этом случае программа предоставляла бы также и операцию set_sender (установить_отправителя), которая позволила бы выполнить требуемую работу еще проще.

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

Формализация спецификаций

Представленный выше беглый набросок абстракции данных слишком неформален, чтобы его можно было постоянно использовать. Вернемся к нашему главному примеру. Стек, как мы это поняли, должен определяться в терминах применимых к нему операций, но тогда нам нужно определить эти операции!

Приведенные содержательные описания явно недостаточны - put вталкивает элемент на 'вершину' стека, remove выталкивает элемент, находящийся на вершине. Нам нужно точно знать, как клиенты могут использовать эти операции и что они для этого должны делать.

Спецификация АТД предоставит эту информацию. Она состоит из четырех разделов, разъясняемых в следующих разделах:

[x]. ТИПЫ

[x]. ФУНКЦИИ

[x]. АКСИОМЫ

[x]. ПРЕДУСЛОВИЯ

Для спецификации АТД в этих разделах будут использоваться простая математическая нотация.

Эту нотацию - математический формализм - не надо путать с программной нотацией в остальной части книги, даже если для согласования она использует тот же стиль синтаксиса. У нее нет специального имени, и она не является нотацией языка программирования. Она могла бы послужить отправной точкой для формального языка спецификаций, но мы удовлетворимся использованием не требующих объяснения соглашений для однозначной спецификации АТД.

Специфицирование типов

В разделе ТИПЫ указываются специфицируемые типы. В общем случае, может оказаться удобным определять одновременно несколько АТД, хотя в нашем примере имеется лишь один тип STACK(СТЕК). Между прочим, что такое тип? Ответ на этот вопрос объединит все положения, развиваемые далее в этой лекции: тип - это совокупность объектов, характеризуемая функциями, аксиомами и предусловиями. Не будет большой ошибкой рассматривать пока тип как множество объектов в математическом смысле слова 'множество' - тип STACK как множество всех возможных стеков, тип INTEGER как множество всех целых чисел и т.д.

Однако при этом не должно быть никакой путаницы: АТД, такой как STACK, - это не объект (один конкретный стек), а совокупность объектов (множество всех стеков). Напомним, в чем состоит наша главная цель: найти подходящую основу для модулей наших программных систем. Очевидно, не имеет смысла делать основой для модуля один конкретный объект - один стек, один самолет, один счет в банке. ОО-проектирование даст нам возможность строить модули, отражающие свойства всех стеков, всех самолетов, всех банковских счетов, или, по крайней мере, значительной их части.

Объект, принадлежащий множеству объектов, описываемых спецификацией АТД, называется