Второе: родовые параметры представляют произвольные типы. Это хорошо для стеков и массивов, поскольку объекты любого типа по своей сути являются хранимыми в различных контейнерах. Но при работе, например, с векторами, хотелось бы иметь возможность складывать элементы векторов или сами векторы. При работе с классом, задающим хеш-таблицы, хотелось бы быть уверенным, что хеш-функция применима к любому элементу таблицы. Такая форма универсализации, где формальный родовой параметр уже не может быть произвольным типом, а является типом, гарантирующим предоставление ряда операций, называется ограниченной универсализацией (constrained genericity).
Для обеих этих проблем ОО-метод обеспечивает простые и элегантные решения, оба основанные на комбинировании универсализации и наследования.
Ключевые концепции
[x]. Классы могут иметь формальные родовые параметры, представляющие типы.
[x]. Родовые классы служат для описания общих контейнерных структур данных, реализуемых одинаково, независимо от элементов, которые они содержат.
[x]. Универсализация требуется только в типизированном языке, гарантирующем статически проверяемую безопасность типов.
[x]. Клиент родового класса должен предоставлять фактические типы для формальных параметров.
[x]. Единственные допустимые операции над сущностью, чей тип является формальным родовым параметром, - это операции, применимые к любому типу. Сущность может быть правой и левой частью оператора присваивания, фактическим аргументом подпрограммы или операндом теста на равенство или неравенство.
[x]. Понятие массива не требует специального языкового механизма и вполне укладывается в обычную схему родового библиотечного класса.
[x]. Более гибкое и продвинутое использование универсализации - полиморфные структуры данных и ограниченная универсализация - требует введения наследования.
Библиографические замечания
Один из первых языков, поддерживающий универсализацию - LPG [Bert 1983]. Язык Ada сделал эту концепцию широко известной введением механизма родовых пакетов.
Универсализация была также введена в языки формальной спецификации, такие как Z, CLEAR и OBJ-2, на которые были ссылки в лекции 6 по АТД. Родовой механизм, описанный здесь, был построен на основе механизма, представленного в ранней версии Z [Abrial 1980] [Abrial 1980a] и расширенного в [M 1985b].
Если не считать эту книгу, то одним из первых ОО-языков, поддерживающих универсализацию, был DEC's Trellis язык [Schaffert 1986].
Упражнения
У10.1 Ограниченная универсализация
Это упражнение немного специфично - оно ставит вопрос, детальный ответ на который будет дан позднее в этой книге. Его цель - дать возможность сравнить ваше решение с решением, предложенным в книге. Оно особенно полезно, если вы не знакомы с решениями, предлагаемыми в ОО-языках. Подход языка Ada может помочь в поиске решения, но и без него можно обойтись.
Продумайте механизм ограниченной универсализации, совместимый по духу с ОО-подходом. Он должен позволять автору родового класса указать, что правильные фактические родовые параметры должны обладать определенным набором операций.
У10.2 Двумерные массивы
Используя класс ARRAY как источник вдохновения и как основу реализации, напишите класс ARRAY2, описывающий двумерные массивы.
У10.3 Использование своего формального родового параметра фактически как чужого
Сконструируйте пример, в котором подпрограмма родового класса C [G] вызывает подпрограмму, объявленную в другом родовом классе D [G], имеющую формальный параметр типа G.
Лекция 11. Проектирование по контракту: построение надежного ПО
Вооруженные базисными концепциями класса, объекта, параметризации вы можете теперь создавать программные модули, реализующие возможно параметризованные типы структур данных. Мои поздравления! Сделан важный шаг в битве за лучшую программную архитектуру. Но рассмотренных методов явно недостаточно для реализации всеобъемлющего видения качества, введенного в начале книги. Факторы качества, на которых было сконцентрировано наше внимание, - повторное использование, расширяемость, совместимость - не должны достигаться ценой надежности (корректность и устойчивость). Хотя концепция надежности просматривалась по ходу обсуждения, мы добиваемся большего.
Базисные механизмы надежности
Необходимость уделить больше внимания семантическим свойствам классов становится особенно очевидной, если вспомнить что класс - это реализация АТД. Рассматриваемые до сих пор классы состояли из атрибутов и программ, реализующих функции спецификации АТД. Но АТД это не просто список операций: вспомните роль семантических свойств, выражаемых аксиомами и предусловиями. Они являются основой, проясняющей природу экземпляров данного типа. В классах мы - временно - потеряли этот семантический аспект концепции АТД. Необходимо вернуться назад, чтобы наше ПО было не только гибким и повторно используемым, но и корректным и устойчивым.
Утверждения и связанные с ними концепции, проясняемые в этой лекции, частично дают ответы. Не являясь полным доказательством, представленные ниже механизмы снабжают программиста основными средствами для формулирования и проверки аргументов корректности. Ключевой концепцией будет Проектирование по контракту (Design by Contract) - установление отношений между классом и его клиентами в виде формального соглашения, недвусмысленно устанавливающее права и обязанности сторон. Только через точное определение для каждого модуля требований и ответственности можно надеяться на достижение существенной степени доверия к большим программным системам.
При обзоре концепций мы впервые столкнемся с ключевой проблемой программной инженерии - как справиться с ошибками периода выполнения, возникающими при нарушении контракта. Этой теме - обработке исключительных ситуаций посвящена следующая лекция. Распределение ролей между двумя главами примерно отражает разницу между двумя компонентами надежности: корректностью и устойчивостью. Корректность - это возможность ПО выполнять свои задачи в соответствии со спецификациями, устойчивость - способность должным образом реагировать на ситуации, выходящие за пределы спецификации. Утверждения (эта лекция), как правило, покрывают корректность, а исключения (следующая лекция) - устойчивость.
Некоторые важные расширения основных идей проектирования по контракту должны ожидать введения наследования, полиморфизма и динамического связывания, что позволит нам перейти от контрактов к выдаче субподрядов.
Технические приемы, введенные в предыдущих лекциях, были направлены на создание надежного ПО. Дадим их краткий обзор - было бы бесполезно рассматривать более продвинутые концепции до приведения в порядок основных механизмов надежности. Первым и определяющим свойством объектной технологии является почти навязываемая структура программной системы - простая, модульная, расширяемая, - проще гарантирующая надежность, чем в случае "кривых" структур, возникающих при применении ранних методов разработки. В частности, усилия по ограничению межмодульного взаимодействия, сведения его к минимуму, были в центре дискуссии о модульности. Результатом стал запрет общих рисков, снижающих надежность, - отказ от глобальных переменных, механизм ограниченного взаимодействия модулей, отношения наследования и вложенности. Общее наблюдение: самый большой враг надежности (и качества ПО в целом) - это сложность. Создавая наши структуры настолько простыми, сколь это возможно, мы достигаем необходимого, но не достаточного условия, гарантирующего надежность. Прежнее обсуждение служит лишь верной отправной точкой в последующих систематических усилиях.