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

Устранение посредника

Устранение посредника

Последний комментарий указывает на весьма интересное следствие правила Утверждений Переобъявления. В общей схеме


Рис. 16.3.  Подпрограмма, клиент и подрядчик

утверждения ? и , введенные при повторном объявлении, предпочтительнее для клиентов, если они отличаются от и ? (предусловия - более слабые, постусловия - более сильные). Но клиент класса A, использующий A' благодаря полиморфизму и динамическому связыванию, не может в полной мере воспользоваться более выгодным контрактом, ибо единственный контракт клиента заключен с классом A.

Воспользоваться преимуществом нового контракта можно лишь став непосредственным клиентом A' (пунктирная связь с вопросительным знаком на рисунке 16.3), как в случае:

a1: A'
...
if a1.? then a1.r end
check a1. end -- постусловие выполняется

При этом вы, естественно, объявляете a1 как объект типа A', а не объект типа A, как прежде. В результате теряется универсальность полиморфизма, идущая от A.

Компромисс ясен. Клиент класса MATRIX должен обеспечивать выполнение исходного (более сильного) предусловия, а в ответ вправе ожидать выполнения исходного (более слабого) постусловия. Даже если его запрос динамически подготовлен к обслуживанию классом NEW_MATRIX, воспользоваться новыми возможностями - большей толерантностью входа и большей точностью выхода - ему никак не удастся. Для обращения к улучшенной спецификации клиент должен объявить матрицу типа NEW_MATRIX, тем самым, потеряв доступ к иным порожденным от MATRIX реализациям, не являющимся производными классами самого NEW_MATRIX.

Оглавление книги


Генерация: 0.053. Запросов К БД/Cache: 0 / 0
поделиться
Вверх Вниз