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

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

Спросите себя: «Что представляет этот стек, список или эта очередь?» Если стек представляет набор сотрудников, рассматривайте АТД как набор сотрудников, а не как стек. Если список соответствует набору счетов, рассматривайте его как набор счетов. Если очередь представляет ячейки электронной таблицы, обращайтесь с ней как с набором ячеек, а не обобщенных элементов. Используйте как можно более высокий уровень абстракции.

Представляйте в форме АТД часто используемые объекты, такие как файлы Большинство языков включает несколько АТД, которые известны всем программистам, но не всегда воспринимаются как АТД. В качестве примера приведу операции над файлами. При записи данных на диск ОС избавляет вас от забот, связанных с позиционированием головки чтения/записи, выделением новых секторов на диске при заполнении старых и интерпретацией непонятных кодов

ошибок. ОС предоставляет первый уровень абстракции и соответствующие ему АТД. Высокоуровневые языки предоставляют второй уровень абстракции и АТД для этого уровня. Высокоуровневые языки скрывают от вас детали генерации вызовов ОС и работы с буферами данных. Они позволяют рассматривать область диска как «файл».

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

Представляйте в форме АТД даже простые элементы Для оправдания использования АТД не обязательно иметь гигантский тип данных. Одним из АТД в нашем списке примеров был фонарь, поддерживающий только две операции: включение и выключение. Вам может показаться, что создавать для операций «включить» и «выключить» отдельные методы слишком расточительно, однако на самом деле АТД выгодно использовать даже в случае самых простых операций. Представление фонаря и его операций в форме АТД облегчает понимание и изменение кода, ограничивает потенциальные следствия изменений методов TumLightOnQ и Тит-LigbtOffO и снижает число элементов данных, которые нужно передавать в методы.

Обращайтесь к АТД так, чтобы это не зависело от среды, используемой для его хранения Допустим, ваша таблица страховых тарифов настолько велика, что ее нужно всегда хранить на диске. Вы могли бы представить ее как «файл тарифов (rate file)» и создать такие методы доступа, как RateFile.ReadQ. Однако, ссылаясь на таблицу как на файл, вы сообщаете о ней больше информации, чем следовало бы. Если вы когда-нибудь измените программу так, чтобы таблица хранилась в памяти, а не на диске, код, обращающийся к ней как к файлу, станет некорректным и начнет вызывать замешательство. Поэтому старайтесь присваивать классам и методам доступа имена, не зависящие от способа хранения данных, и обращайтесь не к конкретным сущностям, а к АТД, таким как таблица страховых тарифов. В нашем случае класс и метод доступа следовало бы назвать rateTable.Re-adO или просто rates.ReadQ,

Работа с несколькими экземплярами данных при использовании АТД в средах, не являющихся объектно-ориентированными

Объектно-ориентированные языки автоматически поддерживают работу с несколькими экземплярами АТД. Если вы использовали исключительно объектно-ориентированные среды и вам не приходилось реализовывать поддержку работы с несколькими экземплярами данных, можете положиться на свою удачу! (И перейти к следующему разделу - «АТД и классы»).

Если вы программируете на С или другом языке, не являющемся объектно-ориентированным, поддержку работы с несколькими экземплярами данных нужно реализовать вручную. В целом это значит, что вы должны создать для АТД сервисы создания и уничтожения экземпляров данных и спроектировать другие сервисы АТД так, чтобы они могли работать с несколькими экземплярами.

АТД «шрифт» изначально предлагал такие сервисы:

currentFont.SetSize( sizelnPoints ) currentFont. SetBoldOnO currentFont. SetBoldOffO currentFont. SetltalicOnO currentFont.SetltalicOff() currentFont.SetTypeFace( faceName )

В среде, не являющейся объектно-ориентированной, эти методы не были бы связаны с классом и выглядели бы так:

SetCurrentFontSize( sizelnPoints ) SetCurrentFontBoldOnO SetCurrentFontBoldOffO SetCurrentFontItalicOn() SetCurrentFontltalicOffO SetCurrentFontTypeFace( faceName )

Если бы вы хотели работать с несколькими шрифтами одновременно, то должны были бы создать сервисы создания и удаления экземпляров шрифтов вроде этих:

CreateFont( fontid ) DeleteFont( fontid ) SetCurrentFont( fontid )

Идентификатор шрифта fontid позволяет следить за несколькими шрифтами по мере их создания и использования. Что касается других операций, то в этом случае вы можете выбирать один из трех вариантов реализации интерфейса АТД. Вариант 1: явно указывать экземпляр данных при каждом обращении к сервисам АТД. В этом случае «текущий шрифт (current font)» не требуется. В каждый метод, работающий со шрифтами, вы передаете fontid. Методы АТД Font следят за всеми данными шрифта, а клиентский код - лишь за идентификатором fontid. Этот вариант требует, чтобы каждый метод, работающий со шрифтами, принимал дополнительный пгрмегр fontid. Ш Вариант 2: явно предоставлять данные, используемые сервисами АТД. В данном случае вы объявляете нужные АТД данные в каждом методе, использующем сервис АТД. Иначе говоря, вы создаете тип данных Font, который передаете в каждый из сервисных методов АТД. Вы должны спроектировать сервисные методы АТД так, чтобы они использовали данные Font, передаваемые в них при каждом вызове. При этом клиентский код не нуждается в идентификаторе шрифта, потому что он следит за данными шрифтов сам. (Хотя данные типа Font доступны напрямую, к ним надо обращаться только через сервисные методы АТД. Это называется поддержанием структуры «в закрытом виде».)

Преимущество этого подхода в том, что сервисным методам АТД не приходится просматривать информацию о шрифте, опираясь на его идентификатор. Есть и недостаток: такой способ предоставляет доступ к данным шрифта остальным частям программы, из-за чего повышается вероятность того, что клиентский код будет использовать детали реализации АТД, которым следовало бы оставаться скрытыми внутри АТД.