Представленное выше описание абстрактных типов данных вполне достаточно для использования АТД в рамках данной книги. (Чтобы дополнить его, выполните упражнения, которые помогут уточнить ваше понимание этого понятия).
Если же, как я надеюсь, АТД уже завоевали вас своей элегантностью, простотой и мощью, то не исключено, что вам захочется узнать побольше об их свойствах, даже о таких, которые не будут использоваться в обсуждении ОО-методов. Далее на нескольких страницах рассмотрены следующие дополнительные темы, которые можно опустить при первом чтении:
[x]. неявность и ее связь с процессом конструирования ПО;
[x]. различие между спецификацией и проектированием;
[x]. различие между классами и записями;
[x]. возможные альтернативы использованию частичных функций;
[x]. решение о полноте или неполноте спецификации.
Библиографические ссылки к этой лекции указывают на более специальную литературу по АТД.
Еще раз о неявности
Неявная природа абстрактных типов данных и классов, рассмотренная выше, отражает одну из важных проблем конструирования программ.
Вполне законен вопрос о различии между упрощенной спецификацией АТД, использующей объявление функций
x: POINT REAL
y: POINT REAL
и объявлением типа в таком традиционном языке программирования, как Pascal:
type
POINT =
record
x, y: real
end
На первый взгляд эти два объявления представляются эквивалентными: оба утверждают, что с типом
[x]. Запись в языке Pascal является законченной и явной: она показывает, что объект
[x]. Объявление функций АТД не несут такого смысла. Они показывают, что объект типа
С упрощенной математической точки зрения можно считать, что приведенное выше объявление в Паскале является определением математического множества
POINT REAL × REAL,
где знак
Если имеются спецификации некоторого понятия, то может появиться желание переместить ее из неявного мира в явный, идентифицируя понятие с декартовым произведением применимых к нему простых запросов, например захочется идентифицировать точки с парами
Соотношение спецификации и проектирования
Предыдущее наблюдение помогает уточнить один из центральных вопросов, возникающих при изучении ПО: различие между начальным этапом разработки ПО - его спецификацией, называемым также анализом, - и более поздними стадиями такими, как проектирование и реализация.
В литературе по разработке программ обычно объясняется, что это различие между "определением задачи" и "построением ее решения". Будучи в принципе правильным, такое объяснение не всегда применимо на практике и иногда бывает трудно понять, где заканчивается спецификация и начинается проектирование. Даже в среде исследователей люди запросто критикуют друг друга в связи с этой темой: "вы рекламируете язык x как язык спецификаций, но на самом деле он предназначен для проектирования". Наивысшим оскорблением считается обвинение некоторой системы обозначений в обслуживании реализации (подробнее об этом в одной из следующих лекций).
Приведенное выше определение дает более точный критерий: пересечь Рубикон между спецификацией и проектированием - это перейти от неявного к явному, другими словами:
Определение: переход от анализа (спецификации) к проектированию
Перейти от спецификации к проектированию - это идентифицировать каждую абстракцию с декартовым произведением ее простых запросов.
Вильям Л Саймон , Вильям Саймон , Наталья Владимировна Макеева , Нора Робертс , Юрий Викторович Щербатых
Зарубежная компьютерная, околокомпьютерная литература / ОС и Сети, интернет / Короткие любовные романы / Психология / Прочая справочная литература / Образование и наука / Книги по IT / Словари и Энциклопедии