Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 191
Текст из файла (страница 191)
Альтернативой является применение Шаблона Ая«еи(), который генерирует прерывание, а не безусловное прекращение работы программы, так что его можно оста- 24.3.7.2. Утверждения Инвариант — это особая форма утверждения (алвес(«оп), Утверждение же в общем случае есть просто высказывание о том, что некоторое логическое условие выполняется. Вопрос здесь только один — что делать, если условие не выполняется. Стандартная библиотека языка С вЂ” и стало быть С++ — предоставляет макрос атвегг() в заголовочном файле <аввегг. Ь> или <саввегг>. Макрос аввегг() вычисляет значение аргумента и вызывает аЬогт() в случае нулевого результата (гайе). Например: 880 Глава 24. Проектирование и программирование вить в окончательном варианте кода (если это необходимо).
К сожалению, Аззеи() не входит в состав стандартной библиотеки, но он очень просто определяется: !етр1аге<с1азз Х, с1азз А > ЫВпе гоЫ Аззег! (А аззееноп ) ( (Г(! аззегйоп) !Игоп Х(); ) Шаблон Аззегт() генерирует исключение Х(), если условие аззегпоп ложно. Например: с(азз Вай агл ( ); гоЫ !'(Ы!* р) ( Аззег!<Вай агд> (р! =О) ,У... ) Так как здесь условия утверждений формулируются явно, то можно явным образом указать необходимость проверки, например, только в условиях отладки: гоЩ2 (тг* р) ( Аззегз<Вай агл> ()уРЕВЮС )! р1=0) т'...
Применение здесь операции ! ! вместо в в может показаться удивительным. Тем не менее, Аззегг<Е>(а! )Ь) проверяет истинность . (а! (Ь), что эквивалентно .а вв .Ь. Указанное применение МРЕВЮС требует установки для него соответствующего значения в зависимости оттого, осуществляем мы отладку, или нет. Поскольку реализации С++ не делают этого по умолчанию, лучше самим установить некоторое характерное значение. Например: ЩИТ МРЕВЮС сопзг Ьоо1 АЯС СНЕСК =За(зе; аейе сапе! Ьоо1 АВС СНЕСК = и пе; () епй(! гоЫУУ (1аг* р) Аззегз<Вай агд> (!АКС СНЕСК! ! р! =О); гУ ... ) Если генерируемое в процессе проверки утверждения прерывание не перехватывается, то Азвегг() заканчивает выполнение программы вызовом гегпнпаге() (почти так же, как аззегг() заканчивает программу вызовом аЬогг () ).
Обработчик прерывания может выполнить и другие, менее радикальные действия. Обычно, при тестировании любой программы реальных (не учебных) размеров я включаю или выключаю проверочные утверждения группами. Применение МРЕВНС вЂ” это простейший способ реализации такой техники. На ранних стадиях раз- 881 24 3 Классы работки включается большинство проверочных утверждений, в то время как в окончательном коде их остается совсем немного (лишь критически важные проверки).
Как видно из приведенного примера, такой стиль управления отладкой поддерживается разбиением утверждений на две части — одна часть является условием, которое управляет включением/выключением проверки (например, Айб СНЕСК~, а вторая содержит собственно проверяемое условие. Если включающее/выключающее условие является константным выражением, то при его запрещающем значении все утверждение будет удалено компилятором.
Однако включающее/выключающее условие может быть и переменной, значение которой можно динамически изменять во время выполнения программы в соответствии с нуждами отладки. Например: Ьоо( возпа слева = ггпе; 1пЫпе году Бв/па:: слеса ( ) ( Азвегг<1пгалапг> (! зптпд слева ( ( (р ьь ()<=зс ьь вс<ТОО ЕАЙОЕ ьь р [зг) ==О) ); ) пзЩ'( ) ( Ягг/пя в = "иктйег" г // здесь строки проверяются ягтя слева =/а(вез ,У а здесь строки ке проверяются ) Естественно, в этом случае генерируется реальный код, так что стоит следить за тем, чтобы его проверочная часть не разбухла слишком сильно из-за интенсивного применения утверждений.
Отметим, что оператор Авзегг<Е> (а) эквивалентен (у'(! а ) глгозг Е ( ); В связи с этим возникает вопрос, зачем связываться с Аввегг(), а не просто написать этот оператор? Дело в том, что применение Акзегг() четко отражает намерение проектировщика.
Оно явным образом говорит, что некоторое условие предполагается в этом месте программы истинным. Это не обычный программный код, а цепная дополнительная информация для любого человека, читающего программу. Еше одним (более приземленным) преимушеством является большая простота обнаружения аягегг() или Аиегг() в большом коде, нежели нахождение в нем условных выражений, генерирующих исключения. Шаблон Аввегт() может быть обобщен так, чтобы он генерировал переменные исключения и исключения с аргументами: гетр(аге<с1азз А, с1авв Е> 1п1(пе гоИ Аввегг (А авзегг(оп, Е ехсерг) ( (1'(! аззегг(оп) глгоп ехсерг; Глава 24. Проектирование и программирование 882 зггисг Ваг! 0 агл ( ии* р! Вай 0 агл((л1* рр): р(рр) () Ьоо! 0 слесл = ггие! !п10 глох = !00; чо!0 0 (тз* р, гхсериоп е) ( Аззегг(!0 олеся ( ( р!=О, е); Аззегг()0 олеся ( ( (0<чрзв*р<=0 тах), Вал 0 агл(р) ) В ..
) К сожалению, многие компиляторы не сумеют устранить избыточный кол для обобшенного Аззсгг() в случаях, когда условие вычисляется на этапе компиляции. Поэтому двухаргументные Аззегг() следует применять лишь в случае, когда исключение не представимо в форме Е(), или когда код нужно генерировать независимо от значения утверждения. В 523.4.3.5 рассматривались две наиболее распространенные формы реорганизации классовых иерархий — расшепление классов на два класса и выделение обшей части двух классов в общий базовый класс.
В обоих случаях большую помошь могут оказать грамотно спроектированные инварианты. В классе, созревшем для расщепления, хорошо видна избыточность большей части проверок инварианта, сосредоточенных в его операциях; после расщепления подмножества операций будут иметь дело с соответствуюшими подмножествами состояний объекта. В классах с обшими частями будут просматриваться схожие инварианты, несмотря на различие в деталях реализации. 24.3.7.3. Предусловия и лостусловия Популярным применением утверждений является формулировка предусловий и постусловий для функций. Имеется ввиду проверка основных предположений относительно входа в функцию и проверка того, что при выходе функция оставляет мир в наллежашем состоянии.
К сожалению, часто подобные утверждения формулируются на более высоком уровне, так что язык программирования не всегда в состоянии отразить их удобным образом. Например: 1етр!а(е<слгзз Вап> чо!0 зогг (Вап у)гзг, Яап !аз1) ( Аззегз<Вай зедиепсе> (" (у)гз1, !ат) !з а ча!ы зедиепсе" ); У.. сортирующий алгоритм ... о'псевдокод Аззегг<радей зогг> (" (у!гзз, !азг) (з т !псгеаз!лл огйег" ); !псевдокод ) Это фундаментальная проблема.
Обшие высказывания о программе лучше формулируются на высокоуровневом языке, близком к математическому, а не на алгоритмическом языке, на котором пишутся программы. В связи с инвариантами требуется немалая доля интеллекта, чтобы перевести высказываемое нами идеализированное утверждение в нечто такое, что можно проверить алгоритмически. Например: 24.3, Классы 883 гетрЬ(е<с!авв Вап> гоЫ хогг(йап Ягзг, Кап 1ал!) ( гУ Диз(,(оз(! - допустимая последовательность: Алвес!<Вад зеоиеисе> (,'ЧРЕВ!16 ( [ гтл!<=1ал!) УУ ... сортирующий олгорити ... У!1)гл(,1ал() находится в возрастающем порядке. Аллес(<Ее(гед лагг> ( ЧРЕВ!)6 ( [ (!азг-явг<2 [ ( (лг(гвг<=1авг[-1) ва *Дев!<=К~ге! [ (1авг-Вгл!) 12) ай Ягл! [ (!авг-фгв|) У2] <=!ат [-1) ) ) ) ) ) Несмотря на то, что писать обычные проверки аргументов и результатов вычислений намного проше, чем утверждения, я все же рекомендую обязательно попытаться выразить идеальные предусловия и постусловия [хотя бы в виде комментариев), прежде чем свести их к чему-либо менее абстрактному, что можно легко выразить на языке программирования.
Проверка предусловий может лепсо выродиться в тривиальную проверку значений аргументов вызова. Поскольку аргументы часто передаются многим функциям, такая проверка становится дорогой. Кроме того, проверка, например, всех аргументов-указателей на неравенство нулю может вызвать необоснованное успокоение и дать ложное чувство уверенности, особенно если оно выполняется лишь в отладочных вариантах программы. Вот почему я рекомендую сосредоточить внимание на инвариантах. 24.3.7.4. Инкапсуляция Заметьте, что в языке С++ именно класс, а не объект класса, является единицей инкапсуляции.
Например: с!алв Е(вг ( Пег* пехг; риЫ[с: Ьоо1 ои (ЕЬ1*); У... )) Ьоо( Е(лг::ои (Е(вг* р) ( [!'(р == 0) ге!ига Го!хе! 1ог (Е(в!* о = (Ыл; Ьч а=о->иехг) (у (р==о) ге!ига !гие) ге!иго гаЬе; ) Доступ к закрытому указателю Пьт:: иехг разрешен, ибо функция Пвг:: ои () имеет доступ к любым объектам класса Пвг, так или иначе попадаюшим в зону ее действия. Там, где это неудобно, можно упростить ситуацию и без эксплуатации возможностей функций-членов иметь открытый доступ к объектам того же самого класса. Например; Ьоо1 Егл:: оп (Пег* р) ( р" (р == 0) ге(игиуаЬег 884 Глава 24.
Проектирование и программирование Ч'(р == ЙЬ) гегигп ггиег () (пех1 == д) гегпгп~аЬе; гегигп пеи->оп (р); ) Здесь, однако, итерация превращается в рекурсию, а это может нанести удар по быстродействию в случае, если компилятор не способен на оптимизацию, преврашаюшую рекурсию обратно в итерацию. 24.4. Компоненты Единицей проектирования является набор классов, функций и т.д., а не отдельный класс. Это множество часто также называют библиотекой или каркасом (825.8), и оно является предметом повторного использования (823.5Л), сопровождения и т.д. Язык С++ предоставляет три возможности для выражения совокупности средств, объединенных неким единым логическим критерием: 1. Класс — коллекция данных, функций, шаблонов и типизированных членов.
2. Иерархия классов — коллекция классов. 3. Пространство имен — коллекция данных, функций, шаблонов и типизиро- ванных членов. Класс обеспечивает средства, делаюшие удобным создание обьектов типа, представляемого этим классом. В то же время, многие важные компоненты не могут быть описаны механизмом, удобным для создания объектов единственного типа. Иерархия классов предназначена для отражения понятия множества родственных классов. Однако составные части компонентов не всегда представимы именно классами, и не все классы можно вписать в осмысленные иерархии (824.2.5). Поэтому самым непосредственным и универсальным воплошением понятия компонента в языке С++ является пространство имен.