Контракты в программной архитектуре

Доводилось ли вам встречать тех, кто занимает радикальную позицию и утверждает: «Мы программируем без контрактов»? Возможно ли это вообще? Попробуем разобраться.

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

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

Аналогичный контракт связывает программиста, выделяющего и освобождающего память в куче процесса средствами системных вызовов Unix: указатель, передаваемый POSIX-совместимой функции free(), должен быть ранее получен как результат вызова malloc(), а не иначе. Вы еще думаете, что программирование без контрактов осуществимо?

Контракты можно найти и в архитектурных шаблонах, например, в шаблоне GoF «посетитель» (англ. visitor), где клиент должен создать экземпляр такого класса-посетителя, который был бы пригоден для обхода элементов принимающей агрегатной структуры. С учетом возможного полиморфизма самой структуры и в ситуации неполного обхода ее элементов статическая проверка пригодности посетителя для работы со структурой может оказаться крайне непростым делом. Еще большие обязательства возникают у клиента при внедрении шаблонов «команда» (англ. command) или «строитель» (англ. builder, особенно в ситуации, когда клиент отказывается от делегирования функции управления созданием продукта классу-распорядителю).

И это лишь несколько примеров того, когда программирование без контрактов попросту невозможно. Впрочем, аналогичные рассуждения можно провести и в отношении защитного программирования. Однако речь о нем пойдет в другой раз.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.