Бьерн Страуструп - Язык программирования С++. Главы 11-13

Главы 11 - 13 посвящены вопросам, связанным с применением С++ для проектирования и реализации больших программных систем. В главе 11 в основном рассматриваются вопросы проектирования и управления программными проектами.  В главе 12 обсуждается взаимосвязь между языком С++ и проблемами проектирования. В главе 13 показаны способы создания библиотек. Завершается книга справочным руководством по С++.

ПРОЕКТИРОВАНИЕ  И РАЗВИТИЕ

            "Серебряной пули не существует."
                        - Ф. Брукс

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

11.1 Введение

Создание любой нетривиальной программной системы - сложная и часто выматывающая задача. Даже для отдельного программиста собственно запись операторов программы есть только часть всей работы. Обычно анализ всей задачи, проектирование программы в целом, документация, тестирование, сопровождение и управление всем этим затмевает задачу написания и отладки отдельных частей программы. Конечно, можно все эти виды деятельности обозначить  как  "программирование" и затем вполне обоснованно утверждать: "Я не проектирую, я только программирую". Но как бы не назывались отдельные виды деятельности, бывает иногда важно сосредоточиться на них по отдельности, так же как иногда бывает важно рассмотреть весь процесс в целом. Стремясь поскорее довести систему до поставки, нельзя упускать из вида ни детали, ни картину в целом, хотя довольно часто происходит именно это. Эта глава сосредоточена на тех частях процесса развития программы, которые не связаны с написанием и отладкой отдельных программных фрагментов.

Обсуждение здесь менее точное и детальное, чем во всех остальных частях книги, где рассматриваются конкретные черты языка или определенные приемы программирования. Это неизбежно, поскольку нет готовых рецептов создания хороших программ. Детальные рецепты "как" могут существовать только для определенных, хорошо разработанных областей применения, но не для достаточно широких областей приложения. В программировании не существует заменителей разума, опыта и вкуса. Следовательно, в этой главе вы найдете только общие рекомендации, альтернативные подходы и осторожные выводы.

Сложность данной тематики связана с абстрактной природой программ и тем фактом, что приемы, применимые для небольших проектов (скажем, программа в 10000 строк, созданная одним или двумя людьми), не распространяются на средние или большие проекты. По этой причине иногда мы приводим  примеры из менее абстрактных инженерных дисциплин, а не только из программирования. Не преминем напомнить, что "доказательство по аналогии" является мошенничеством, и аналогии служат здесь только в качестве примера. Понятия проектирования, формулируемые с помощью определенных конструкций С++, и поясняемые примерами, мы будем обсуждать в главах 12 и 13. Предложенные в этой главе рекомендации, отражаются как в самом языке С++, так и в решении конкретных программных задач по всей книге.

Снова напомним, что в силу чрезвычайного разнообразия областей применения, программистов и среды, в которой развивается программная система, нельзя ожидать, что каждый вывод, сделанный здесь, будет прямо применим для вашей задачи. Эти выводы применимы во многих самых разных случаях, но их нельзя считать универсальными законами. Смотрите на них со здоровой долей скептицизма.

Язык С++ можно просто использовать как лучший вариант С. Однако, поступая так, мы не используем наиболее мощные возможности С++ и определенные приемы программирования на нем, так что реализуем лишь малую долю потенциальных достоинств С++. В этой главе излагается такой подход к проектированию, который позволяет полностью использовать возможности абстрактных данных и средства объектного программирования С++. Такой подход обычно называют объектно-ориентированным проектированием. В главе 12 обсуждаются основные приемы программирования на С++, там же содержится предостережение от сомнительных идей, что есть только один правильный" способ использования С++, и что для получения максимального выигрыша следует всякое средство С++
применять в любой программе ($$12.1).

Укажем некоторые основные принципы, рассматриваемые в этой главе:

   - из всех вопросов, связанных с процессом развития программного обеспечения, самый важный - четко сознавать, что собственно вы пытаетесь создать.
   - Успешный процесс развития программного обеспечения - это длительный процесс.
   - Системы, которые мы создаем, стремятся к пределу сложности по отношению как к самим создателям, так и используемым средствам.
   - Эксперимент является необходимой частью проекта для разработки всех нетривиальных программных систем.
   - Проектирование и программирование - это итеративные процессы.
   - Различные стадии проекта программного обеспечения, такие как: проектирование, программирование и тестирование - невозможно строго разделить.
   - Проектирование и программирование нельзя рассматривать в отрыве от вопросов управления этими видами деятельности.

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

Может быть все эти емкие принципы можно сжать в один: проектирование и программирование - виды человеческой деятельности; забудь про это - и все пропало. Слишком часто мы забываем про это и рассматриваем процесс развития программного обеспечения просто как "последовательность хорошо определенных шагов, на каждом из которых по заданным правилам производятся некоторые действия над входными данными, чтобы получить требуемый результат". Сам стиль предыдущего предложения выдает присутствие человеческой природы!
Эта глава относится к проектам, которые можно считать честолюбивыми, если учитывать ресурсы и опыт людей, создающих систему. Похоже, это в природе как индивидуума, так и организации - браться за проекты на пределе своих возможностей. Если задача не содержит определенный вызов, нет смысла уделять особое внимание ее проектированию. Такие задачи решаются в рамках уже устоявшейся структуры, которую не следует разрушать. Только если замахиваются на что-то амбициозное, появляется потребность в новых, более мощных средствах и приемах. Кроме того, существует тенденция у тех, кто "знает как делать", перепоручать проект новичкам, которые не имеют таких знаний.

Не существует "единственного правильного способа" для проектирования и создания всей системы. Я бы считал веру в "единственный правильный способ" детской болезнью, если бы этой болезнью слишком часто не заболевали и опытные программисты. Напомним еще раз: только по той причине, что прием успешно использовался в течение года для одного проекта, не следует, что он без всяких изменений окажется столь же полезен для другого человека или другой задачи. Всегда важно не иметь предубеждений.

Убеждение в том, что нет единственно верного решения, пронизывает весь проект языка С++, и, в основном, по этой причине в первом издании книги не было раздела, посвященного проектированию: я не хотел, чтобы его рассматривали как "манифест" моих личных симпатий. По этой же причине здесь, как и в главах 12 и 13, нет четко определенного взгляда на процесс развития программного обеспечения, скорее здесь просто дается обсуждение определенного круга, часто возникающих, вопросов и предлагаются некоторые решения, оказавшиеся полезными в определенных условиях.

За этим введением следует краткое обсуждение целей и средств развития программного обеспечения в $$11.2, а дальше глава распадается на две основных части:
- $$11.3 содержит описание процесса развития  программного обеспечения.
- $$11.4 содержит некоторые практические рекомендации по организации этого процесса. Взаимосвязь между проектированием и языком программирования обсуждается в главе 12, а глава 13 посвящена вопросам проектирования библиотек для С++.

Очевидно, большая часть рассуждений относится к программным проектам большого объема. Читатели, которые не участвуют в таких разработках, могут сидеть спокойно и радоваться, что все эти ужасы  их миновали, или же они могут выбрать вопросы, касающиеся только их интересов. Нет нижней границы размера программы, начиная с которой имеет смысл заняться проектированием прежде, чем начать писать программу. Однако все-таки есть нижняя граница, начиная с которой можно использовать какие-либо методы проектирования. Вопросы, связанные с размером, обсуждаются в $$11.4.2.

Труднее всего в программных проектах бороться с их сложностью. Есть только один общий способ борьбы со сложностью: разделяй и властвуй. Если задачу удалось разделить на две подзадачи, которые можно решать в отдельности, то можно считать ее решенной за счет разделения более, чем наполовину. Этот простой принцип применим для удивительно большого числа ситуаций. В частности, использование модулей или классов при разработке программных систем позволяет разбить программу на две части: часть реализации и часть, открытую пользователю - которые связаны между собой (в идеале) вполне определенным интерфейсом. Это основной, внутренне присущий программированию, принцип борьбы со сложностью. Подобно этому и процесс проектирования программы можно разбить на отдельные виды деятельности с четко определенным (в идеале)
взаимодействием между людьми, участвующими в них. Это основной, внутренне присущий проектированию, принцип борьбы со сложностью и подход к управлению людьми,занятыми в проекте.

В обоих случаях выделение частей и определение интерфейса между частями - это то место, где требуется максимум опыта и чутья. Такое выделение не является чисто механическим процессом, обычно оно требует проницательности, которая может появиться только в  результате  досконального понимания   системы  на  различных  уровнях  абстракции  (см. $$11.3.3, $$12.2.1 и $$13.3). Близорукий взгляд на программу или на процесс разработки программного обеспечения часто приводит к дефектной системе. Отметим, что как программы, так и программистов разделить просто. Труднее достигнуть эффективного взаимодействия между участниками по обе стороны границы, не нарушая ее и не делая взаимодействие слишком жестким.

Здесь предложен определенный подход к проектированию, а не полное формальное описание метода проектирования. Такое описание выходит за предметную область книги. Подход, предложенный здесь, можно применять с различной степенью формализации, и он может служить базой для различных формальных спецификаций. В тоже время нельзя считать эту главу рефератом, и здесь не делается попытка рассмотреть каждую тему, относящуюся к процессу разработки программ или изложить каждую точку зрения. Это тоже выходит за предметную область книги. Реферат по этой тематике можно найти в [2]. В этой книге используется достаточно общая и традиционная терминология. Самые "интересные" термины, как: проектирование, прототип, программист - имеют в литературе несколько определений, часто противоречащих друг другу, поэтому предостерегаем вас от того, чтобы, исходя из принятых в вашем окружении определений терминов, вы не вынесли из книги то, на что автор совершенно не рассчитывал.

11.2 Цели и средства

Цель программирования - создать продукт, удовлетворяющий пользователя. Важнейшим средством для достижении этой цели является создание программы с ясной внутренней структурой и воспитание коллектива программистов и разработчиков, имеющих достаточный опыт и мотивацию, чтобы быстро и эффективно реагировать на все изменения.

Почему это так? Ведь внутрення структура программы и процесс, с помощью которого она получена, в идеале никак не касаются конечного пользователя. Более того, если конечный пользователь почему-то интересуется тем, как написана программа, то что-то с этой программой не так. Почему, несмотря на это, так важны структура программы и люди, ее создавшие?  В  конце  концов  конечный пользователь ничего об этом не должен знать.

Ясная внутренняя структура программы облегчает:

   - тестирование,
   - переносимость,
   - сопровождение,
   - расширение,
   - реорганизацию и
   - понимание.

Главное здесь в том, что любая удачная большая программа имеет долгую жизнь, в течение которой над ней работают поколения программистов и разработчиков, она переносится на новую машину, приспосабливается к непредусмотренным требованиям и несколько раз перестраивается. Во все время жизни необходимо в приемлемое время и с допустимым числом ошибок выдавать версии программы. Не планировать все это - все равно, что запланировать неудачу.

Отметим, что, хотя в идеальном случае случае пользователи не должны знать внутреннюю структуру системы, на практике они обычно хотят ее знать. Например, пользователь может желать познакомиться в деталях с разработкой системы с целью научиться контролировать возможности и надежность системы на случай переделок и расширений. Если рассматриваемый программный продукт есть не полная система, а набор библиотек для получения программных систем, то пользователь захочет узнать побольше "деталей", чтобы они служили источником идей и помогали лучше использовать библиотеку.

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

Организация должна создавать программный продукт и сопровождать его, несмотря на изменения в штате, в направлении работы или в управляющей структуре. Распространенный способ решения этих проблем заключался в попытке сведения процесса создания системы к нескольким относительно простым задачам, укладывающимся в жесткую структуру. Например, создать группу легко обучаемых (дешевых) и взаимозаменяемых программистов низкого уровня ("кодировщиков") и группу не таких дешевых, но взаимозаменяемых (а значит также не уникальных) разработчиков. Считается, что кодировщики не принимают решений по проектированию, а разработчики не утруждают  себя  "грязными" подробностями кодирования. Обычно такой подход приводит к неудаче, а где он срабатывает, получается слишком громоздкая система с плохими характеристиками.

Недостатки такого подхода состоят в следующем:

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

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

С другой стороны, нельзя создать систему, представить документацию по ней и бесконечно ее сопровождать без некоторой жесткой организационной структуры. Для чисто новаторского проекта хорошо начать с того, что просто найти лучших специалистов и позволить им решать задачу в соответствии с их идеями.  Но по мере развития проекта  требуется  все больше планирования,  специализации и строго определенного взаимодействия между занятыми в нем людьми. Под строго определенным понимается не математическая или автоматически верифицируемая запись (хотя это безусловно хорошо там, где возможно и применимо), а скорее набор указаний по записи, именованию, документации, тестированию и т.п. Но и здесь необходимо чувство меры. Слишком жесткая структура может мешать росту и затруднять совершенствование. Здесь подвергается проверке талант и опыт менеджера. Для отдельного работника аналогичная проблема сводится к определению, где нужно проявить смекалку, а где действовать по рецептам.

Можно рекомендовать планировать не на период до выдачи следующей версии системы, а на более долгий срок. Строить планы только до выпуска очередной версии - значит планировать неудачу. Нужно иметь организацию и стратегию развития программного обеспечения, которые нацелены на создание и поддержание многих версий разных систем, т.е. нужно многократное планирование успеха.

Цель проектирования в выработке ясной и относительно простой внутренней структуры программы, называемой иногда архитектурой, иными словами каркаса, в который укладываются отдельные программные фрагменты, и который помогает написанию этих фрагментов.

Проект - конечный результат процесса проектирования (если только бывает конечный продукт у итеративного процесса). Он является средоточием взаимодействий между разработчиком и программистом и между программистами. Здесь необходимо соблюсти чувство меры. Если я, как отдельный программист, проектирую небольшую программу, которую собираюсь написать завтра, то точность и полнота описания проекта может свестись к нескольким каракулям на обратной стороне конверта. На другом полюсе находится система, над которой работают сотни программистов и разработчиков, и здесь могут потребоваться тома тщательно составленных спецификаций проекта на формальном или полуформальном языке. Определение нужной степени точности, детализации и формальности проектирования является уже само по себе нетривиальной технической и административной задачей.

Далее будет предполагаться, что проект системы записывается как ряд определений классов (в которых частные описания опущены как лишние детали) и взаимоотношений между ними. Это упрощение, т.к. конкретный проект может учитывать: вопросы параллельности, использование глобального пространства имен, использование глобальных функций и данных, построение программы для минимизации перетрансляции, устойчивость, многомашинный режим и т.п. Но при обсуждении на данном уровне детализации без упрощения не обойтись, а классы в контексте С++ являются ключевым понятием проектирования. Некоторые из указанных вопросов будут обсуждаться ниже, а те, которые прямо затрагивают проектирование библиотек С++, будут рассмотрены в главе 13. Более подробное обсуждение и примеры определенных методов объектно-
ориентированного проектирования содержатся в [2].

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

11.3 Процесс развития

Процесс развития программного обеспечения - это итеративный и расширяющийся процесс. По мере развития каждая стадия повторяется многократно, и при всяком возврате на некоторую стадию процесса уточняется конечный продукт, получаемый на этой стадии. В общем случае процесс не имеет ни начала, ни конца, поскольку, проектируя и реализуя систему, вы начинаете, используя как базу другие проекты, библиотеки и прикладные системы, в конце работы после вас остается описание проекта и программа, которые другие могут уточнять, модифицировать, расширять и переносить. Естественно конкретный проект имеет определенное начало и конец, и важно (хотя часто удивительно трудно) четко и строго ограничить время и область действия проекта. Но заявление, что вы начинаете с "чистого листа", может привести к серьезным проблемам для вас, также как и позиция, что после передачи окончательной версии - хоть потоп, вызовет серьезные проблемы для ваших последователей (или для вас в новой роли).

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

У процесса развития три стадии:

 - Анализ: определение области задачи.
 - Проектирование: создание общей структуры системы.
 - Реализация: программирование и тестирование.

Не забудьте об итеративной природе этих процессов (неспроста стадии не были пронумерованы), и заметьте, что никакие важные аспекты процесса развития программы не выделяются в отдельные стадии, поскольку они должны допускать:

 - Экспериментирование.
 - Тестирование.
 - Анализ проектирования и реализации.
 - Документирование.
 - Сопровождение.

Сопровождение программного обеспечения рассматривается просто как еще несколько проходов по стадиям процесса развития (см. также $$11.3.6).

Очень важно, чтобы анализ, проектирование и реализация не были слишком оторваны друг от друга, и чтобы люди, принимающие в них участие, были одного уровня квалификации для налаживания эффективных контактов. В больших проектах слишком часто бывает иначе. В идеале, в процессе развития проекта работники должны сами переходить с одной стадии на другую: лучший способ передачи тонкой информации - это использовать голову работника. К сожалению, в организациях часто устанавливают барьеры для таких переходов, например, у разработчика может быть более высокий статус и (или) более высокий оклад, чем у "простого" программиста. Не принято, чтобы сотрудники ходили по отделам с целью набраться опыта и знаний, но пусть, по крайней мере, будут регулярными собеседования сотрудников, занятых на разных стадиях проекта.

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

Приведенная здесь модель процесса развития программного обеспечения радикально отличается от традиционной модели "каскад" (waterfall). В последней процесс развития протекает линейно от стадии анализа до стадии тестирования. Основной недостаток модели каскад тот, что в ней информация движется только в одном направлении. Если выявлена проблема "ниже по течению", то возникает сильное методологическое и организационное давление, чтобы решить проблему на данном уровне, не затрагивая предыдущих стадий процесса. Отсутствие повторных проходов приводит к дефектному проекту, а в результате локального устранения проблем получается искаженная реализация. В тех неизбежных случаях, когда информация должна быть передана назад к источнику ее получения и вызвать изменения в проекте, мы получим лишь слабое "колыхание" на всех уровнях системы, стремящейся подавить внесенное изменение, а значит система плохо приспособлена к изменениям. Аргумент в пользу "никаких изменений" или "только локальные изменения" часто сводится к тому, что один отдел не хочет перекладывать большую работу на другой отдел "ради их же блага". Часто бывает так, что ко времени, когда ошибка уже найдена, исписано столько бумаги относительно ошибочного решения, что усилия, нужные на исправление документации, затмевают усилия для исправления самой программы. Таким образом, бумажная работа может стать главной проблемой процесса создания системы. Конечно, такие проблемы могут быть и возникают в процессе развития больших систем. В конце концов, определенная работа с бумагами необходима. Но выбор линейной модели развития (каскад) многократно увеличивает вероятность, что эта проблема выйдет из-под контроля. Недостаток модели каскад в отсутствии повторных проходов и неспособности реагировать на изменения. Опасность предлагаемой здесь итеративной модели состоит в искушении заменить размышление и реальное развитие на последовательность бесконечных изменений. Тот и другой недостатки легче указать, чем устранить, и для того, кто организует работу, легко принять простую активность за реальный прогресс.

Вы можете уделять пристальное внимание деталям, использовать разумные приемы управления, развитую технологию, но ничто не спасет вас, если нет ясного понимания того, что вы пытаетесь создать. Больше всего проектов проваливалось именно из-за отсутствия хорошо сформулированных реалистичных целей, а не по какой-либо иной причине. Что бы вы не делали и чем бы не занимались, надо ясно представлять имеющиеся у вас средства, ставить достижимые цели и ориентиры и не искать технических решений социологических проблем. С другой стороны, надо применять только адекватную технологию, даже если она потребует затрат,- люди работают лучше, имея адекватные средства и приемлемую среду. Не заблуждайтесь, думая, что легко выполнить эти рекомендации.

11.3.1 Цикл развития

Процесс развития системы - это итеративная деятельность. Основной цикл сводится к повторяемым в следующей последовательности шагам:

 [1] Создать общее описание проекта.
 [2] Выделить стандартные компоненты.
     [a] Подогнать компоненты под данный проект.
 [3] Создать новые стандартные компоненты.
     [a] Подогнать компоненты под данный проект.
 [4] Составить уточненное описание проекта.

В качестве примера рассмотрим автомобильный завод. Проект должен начинаться с самого общего описания новой машины. Этот первый шаг базируется на некотором анализе и описании машины в самых общих терминах, которые скорее относятся к предполагаемому использованию, чем к характеристикам желаемых возможностей машины. Часто самой трудной частью проекта бывает выбор желаемых возможностей, или, точнее, определение относительно простого критерия выбора желаемых возможностей. Удача здесь, как правило, является результатом работы отдельного проницательного человека и часто называется предвидением. Слишком типично как раз отсутствие ясных целей, что приводит к неуверенно развивающимся или просто проваливающимся проектам.

Итак, допустим необходимо создать машину среднего размера с четырьмя дверцами и достаточно мощным мотором. Очевидно, что на первом этапе проекта не следует начинать проектирование машины
(и всех ее компонентов) с нуля. Хотя программист или разработчик программного обеспечения в подобных обстоятельствах поступит именно так.

На первом этапе надо выяснить, какие компоненты доступны на вашем собственном складе и какие можно получить от надежных поставщиков. Найденные таким образом компоненты не обязательно в точности подойдут для новой машины. Всегда требуется подгонка компонентов. Может быть даже потребуется изменить характеристики следующей версии" выбранных компонентов, чтобы сделать их пригодными для проекта. Например, может существовать вполне пригодный мотор, вырабатывающий немного меньшую мощность.Тогда или вы, или поставщик мотора должны предложить, не изменяя общего описания проекта, в качестве компенсации дополнительный зарядный генератор.  Заметим, что сделать это,"не изменяя общего описания проекта", маловероятно, если только само описание не приспособлено к определенной подгонке. Обычно подобная подгонка требует кооперации между вами и поставщиком моторов. Сходные вопросы возникают и у программиста или разработчика программного обеспечения. Здесь подгонку обычно облегчает эффективное использование производных классов. Но не рассчитывайте провести произвольные расширения в проекте без определенного предвидения или кооперации с создателем таких классов.

Когда исчерпается набор подходящих стандартных компонентов, проектировщик машины не спешит заняться проектированием новых оптимальных компонентов для своей машины. Это было бы слишком расточительно. Допустим, что не нашлось подходящего блока кондиционирования воздуха, зато есть свободное пространство, имеющее форму буквы L, в моторном отсеке. Возможно решение разработать блок кондиционирования указанной формы. Но вероятность того, что блок подобной странной формы будет использоваться в машинах другого типа (даже после значительной подгонки), крайне низка. Это означает, что наш проектировщик машины не сможет разделить затраты на производство такого блока с создателями машин другого типа, а значит время жизни этого блока коротко. Поэтому стоит спроектировать блок, который найдет более широкое применение, т.е. разработать разумный проект блока, более приспособленный для подгонки, чем наше L-образное чудище. Возможно, это потребует больших усилий, и даже придется для приспособления более универсального блока изменить общее описание проекта машины. Поскольку новый блок разрабатывался для более общего применения, чем наше L-образное чудище, предположительно, для него потребуется некоторая подгонка, чтобы полностью удовлетворить наши пересмотренные запросы. Подобная же альтернатива возникает и у программиста или разработчика программного обеспечения: вместо того, чтобы создать программу, привязанную к конкретному проекту, разработчик может спроектировать новую достаточно универсальную программу, которая будет иметь хорошие шансы стать стандартной в определенной области.

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

Мы не пытаемся утверждать, что все разработчики машин действуют столь разумно, как в приведенном примере, а разработчики программ совершают все указанные ошибки. Утверждается, что указанная методика разработки машин применима и для программного обеспечения. Так, в этой и следующей главах даны приемы использования ее для С++. Тем не менее можно сказать, что сама природа программирования способствует совершению указанных ошибок ($$12.2.1 и $$12.2.5). В разделе 11.4.3 опровергается профессиональное предубеждение против использования описанной здесь модели проектирования.
 Заметим, что модель развития программного обеспечения хорошо применима только в расчете на большие сроки. Если ваш горизонт сужается до времени выдачи очередной версии, нет смысла создавать и поддерживать функционирование стандартных компонентов. Это просто приведет к излишним накладным расходам. Наша модель рассчитана на организации со временем жизни, за которое проходит несколько проектов, и с размерами, которые позволяют нести дополнительные расходы и на средства проектирования, программирования, и на сопровождение проектов, и на повышение квалификации разработчиков, программистов и менеджеров. Фактически это эскиз некоторой фабрики по производству программ. Как ни удивительно, она только масштабом отличается от действий лучших программистов, которые для повышения своей производительности в течении лет накапливали запас приемов и методов проектирования, создавали инструменты и библиотеки. Похоже, что большинство организаций просто не умеет воспользоваться достижениями лучших сотрудников, как из-за отсутствия предвидения, так и по неспособности применить эти достижения в достаточно широком объеме.

Все-таки неразумно требовать, чтобы "стандартные компоненты" были стандартными универсально. Существует лишь малое число международных стандартных библиотек, а в своем большинстве компоненты окажутся стандартными только в пределах страны, отрасли, компании, производственной цепочки, отдела или области приложения и т.д. Просто мир слишком велик, чтобы универсальный стандарт всех компонентов и средств был реальной или желанной целью проекта.

11.3.2 Цели проектирования

Каковы самые общие цели проектирования? Конечно, простота, но в чем критерий простоты? Поскольку мы считаем, что проект должен развиваться во времени, т.е. система будет расширяться, переноситься, настраиваться и, вообще, изменяться массой способов, которые невозможно предусмотреть, необходимо стремиться к такой системе проектирования и реализации, которая была бы простой с учетом, что она будет меняться многими способами. На самом деле, практично допустить, что сами требования к системе будут меняться неоднократно за период от начального проекта до выдачи первой версии системы.

Вывод таков: система должна проектироваться максимально простой при условии, что она будет подвергаться серии изменений. Мы должны проектировать в расчете на изменения, т.е. стремиться к

  - гибкости,
  - расширяемости и
  - переносимости

Лучшее решение - выделить части системы, которые вероятнее всего будут меняться, в самостоятельные единицы, и предоставить программисту или разработчику гибкие возможности для модификаций таких единиц. Это можно сделать, если выделить ключевые для данной задачи понятия и предоставить класс, отвечающий за всю информацию, связанную с отдельным понятием (и только с ним). Тогда изменение будет затрагивать только определенный класс. Естественно, такой идеальный способ гораздо легче описать, чем воплотить.

Рассмотрим пример: в задаче моделирования метеорологических объектов нужно представить дождевое облако. Как это сделать? У нас нет общего метода изображения облака, поскольку его вид зависит от внутреннего состояния облака, а оно может быть задано только самим облаком.

Первое решение: пусть облако изображает себя само. Оно подходит для многих ограниченных приложений. Но оно не является достаточно общим, поскольку существует много способов представления облака: детальная картина, набросок очертаний, пиктограмма, карта и т.п. Другими словами, вид облака определяется как им самим, так и его окружением.

Второе решение заключается в том, чтобы предоставить самому облаку для его изображения сведения о его окружении. Оно годится для большего числа случаев. Однако и это не общее решение. Если мы предоставляем облаку сведения об его окружении, то нарушаем основной постулат, который требует, чтобы класс отвечал только за одно понятие, и каждое понятие воплощалось определенным классом. Может оказаться невозможным предложить согласованное определение окружения облака", поскольку, вообще говоря, как выглядит облако зависит от самого облака и наблюдателя. Чем представляется облако мне, сильно зависит от того, как я смотрю на него: невооруженным глазом, с помощью поляризационного фильтра, с помощью метеорадара и т.д. Помимо наблюдателя и облака следует учитывать и "общий фон", например, относительное положение солнца. К дальнейшему усложнению картины приводит добавление новых объектов типа других облаков, самолетов. Чтобы сделать задачу разработчика практически неразрешимой, можно добавить возможность одновременного существования нескольких наблюдателей.

Третье решение состоит в том, чтобы облако, а также и другие объекты, например, самолеты или солнце, сами описывали себя по отношению к наблюдателю. Такой подход обладает достаточной общностью, чтобы удовлетворить большинство запросовЬ. Однако, он может привести к значительному усложнению и большим накладным расходам при выполнении. Как, например, добиться того, чтобы наблюдатель понимал описания, произведенные облаком или другими объектами? Ь Даже эта модель будет, по всей видимости, не достаточной для таких предельных случаев, как графика с высокой степенью разрешимости.
  Я думаю, что для получения очень детальной картины нужен другой уровень абстракции.

Дождевые облака - это не тот объект, который часто встретишь в программах, но объекты, участвующие в различных операциях ввода и вывода, встречаются часто. Поэтому можно считать пример с облаком пригодным для программирования вообще и для разработки библиотек в частности. Логически схожий пример в С++ представляют манипуляторы, которые используются для форматирования вывода в потоковом вводе-выводе ($$10.4.2). Заметим, что третье решение не есть "верное решение", это просто более общее решение. Разработчик должен сбалансировать различные требования системы, чтобы найти уровень общности и абстракции, пригодный для данной задачи в данной области. Золотое правило: для программы с долгим сроком жизни правильным будет самый общий уровень абстракции, который вам еще понятен и который вы можете себе позволить, но не обязательно абсолютно общий. Обобщение, выходящее за пределы данного проекта и понятия людей, в нем участвующих, может принести вред, т.е. привести к задержкам, неприемлемым характеристикам, неуправляемым проектам и просто к провалу.

Чтобы использование указанных методов было экономично и поддавалось управлению, проектирование и управление должно учитывать повторное использование, о чем говорится в $$11.4.1 и не следует совсем забывать об эффективности (см. $$11.3.7).

11.3.3 Шаги проектирования

Рассмотрим проектирование отдельного класса. Обычно это не лучший метод. Понятия не существуют изолированно, наоборот, понятие определяется в связи с другими понятиями. Аналогично и класс не существует изолированно, а определяется совместно с множеством связанных между собой классов. Это множество часто называют библиотекой классов или компонентом. Иногда все классы компонента образуют единую иерархию, иногда это не так (см. $$12.3).

Множество классов компонента бывают объединены некоторым логическим условием, иногда это - общий стиль программирования или описания, иногда - предоставляемый сервис. Компонент является единицей проектирования, документации, права собственности и, часто, повторного использования. Это не означает, что если вы используете один класс компонента, то должны разбираться во всех и уметь применять все классы компонента или должны подгружать к вашей программе модули всех классов компонента. В точности наоборот, обычно стремятся обеспечить, чтобы использование класса вело к минимуму накладных расходов: как машинных ресурсов, так и человеческих усилий. Но для использования любого класса компонента нужно понимать логическое условие, которое его определяет (можно надеяться, что оно предельно ясно изложено в документации), понимать соглашения и стиль, примененный в процессе проектирования и описания компонента, и доступный сервис (если он есть).

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

  [1] Определить понятие / класс и установить основные связи между ними.
  [2] Уточнить определения классов, указав набор операций для каждого.
      [a] Провести классификацию операций. В частности уточнить необходимость построения, копирования и уничтожения.
      [b] Убедиться в минимальности, полноте и удобстве.
  [3] Уточнить определения классов, указав их зависимость от других классов.
      [a] Наследование.
      [b] Использование зависимостей.
  [4] Определить интерфейсы классов.
      [a] Поделить функции на общие и защищенные.
      [b] Определить точный тип операций класса.

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

Далее следует приступить к реализации классов, а затем вернуться, чтобы оценить проект, исходя из опыта реализации. Рассмотрим эти шаги в отдельности.

11.3.3.1 Шаг 1: определение классов

Определите понятия/классы и установите основные связи между ними. Главное в хорошем проекте - прямо отразить какое-либо понятие реальности", т.е. уловить понятие из области приложения классов, представить взаимосвязь между классами строго определенным способом, например, с помощью наследования, и повторить эти действия на разных уровнях абстракции. Но как мы можем уловить эти понятия? Как на практике решить, какие нам нужны классы? Лучше поискать ответ в самой области приложения, чем рыться в программистском хранилище абстракций и понятий. Обратитесь к тому, кто стал экспертом по работе в некогда сделанной системе, а также к тому, кто стал критиком системы, пришедшей ей на смену. Запомните выражения того и другого.

Часто говорят, что существительные играют роль классов и объектов, используемых в программе, это действительно так. Но это только начало. Далее, глаголы могут представлять операции над объектами или обычные (глобальные) функции, вырабатывающие новые значения, исходя из своих параметров, или даже классы. В качестве примера можно рассматривать функциональные объекты, описанные в $$10.4.2. Такие глаголы, как "повторить" или "совершить" (commit) могут быть представлены итеративным объектом или объектом, представляющим операцию выполнения программы в базах данных. Даже прилагательные можно успешно представлять с помощью классов, например, такие, как "хранимый", параллельный", "регистровый", "ограниченный". Это могут быть классы, которые помогут разработчику или программисту, задав виртуальные базовые классы, специфицировать и выбрать нужные свойства для классов, проектируемых позднее.

Лучшее средство для поиска этих понятий / классов - грифельная доска, а лучший метод первого уточнения - это беседа со специалистами в области приложения или просто с друзьями. Обсуждение необходимо, чтобы создать начальный жизнеспособный словарь терминов и понятийную структуру. Мало кто может сделать это в одиночку. Обратитесь к [1], чтобы узнать о методах подобных уточнений.

Не все классы соответствуют понятиям из области приложения. Некоторые могут представлять ресурсы системы или абстракции периода реализации (см. $$12.2.1).

Взаимоотношения, о которых мы говорим, естественно устанавливаются в области приложения или (в случае повторных проходов по шагам проектирования) возникают из последующей работы над структурой классов. Они отражают наше понимание основ области приложения. Часто они являются классификацией основных понятий. Пример такого отношения: машина с выдвижной лестницей есть грузовик, есть пожарная машина, есть движущееся средство. В $$11.3.3.2 и $$11.3.3.5 предлагается некоторая точка зрения на классы и иерархию классов, если необходимо улучшить их структуру.

11.3.3.2 Шаг 2: определение набора операций

Уточните определения классов, указав набор операций для каждого. В действительности нельзя разделить процессы определения классов и выяснения того, какие операции для них нужны. Однако, на практике они различаются, поскольку при определении классов внимание концентрируется на основных понятиях, не останавливаясь на программистских вопросах их реализации, тогда как при определении операций прежде всего сосредотачивается на том, чтобы задать полный и удобный набор операций. Часто бывает слишком трудно совместить оба подхода, в особенности, учитывая, что связанные классы надо проектировать одновременно.

Возможно несколько подходов к процессу определения набора операций. Предлагаем следующую стратегию:

   [1] Рассмотрите, каким образом объект класса будет создаваться, копироваться (если нужно) и уничтожаться.
   [2] Определите минимальный набор операций, который необходим для понятия, представленного классом.
   [3] Рассмотрите операции, которые могут быть добавлены для удобства записи, и включите только несколько действительно важных.
   [4] Рассмотрите, какие операции можно считать тривиальными, т.е. такими, для которых класс выступает в роли интерфейса для реализации производного класса.
   [5] Рассмотрите, какой общности именования и функциональности можно достигнуть для всех классов компонента.

Очевидно, что это - стратегия минимализма. Гораздо проще добавлять любую функцию, приносящую ощутимую пользу, и сделать все операции виртуальными. Но, чем больше функций, тем больше вероятность, что они не будут использоваться, наложат определенные ограничения на реализацию и затруднят эволюцию системы. Так, функции, которые могут непосредственно читать и писать в переменную состояния объекта из класса, вынуждают использовать единственный способ реализации и значительно сокращают возможности перепроектирования. Такие функции снижают уровень абстракции от понятия до его конкретной реализации. К тому же добавление функций добавляет работы программисту и даже разработчику, когда он вернется к проектированию. Гораздо легче включить в интерфейс еще одну функцию, как только установлена потребность в ней, чем удалить ее оттуда, когда уже она стала привычной.

Причина, по которой мы требуем явного принятия решения о виртуальности данной функции, не оставляя его на стадию реализации, в том, что, объявив функцию виртуальной, мы существенно повлияем на использование ее класса и на взаимоотношения этого класса с другими. Объекты из класса, имеющего хотя бы одну виртуальную функцию, требуют нетривиального распределения памяти, если сравнить их с объектами из таких языков как С или Фортран. Класс с хотя бы одной виртуальной функцией по сути выступает в роли интерфейса по отношению к классам, которые "еще могут быть определены", а виртуальная функция предполагает зависимость от классов, которые еще могу быть определены" (см. $$12.2.3)

Отметим, что стратегия минимализма требует, пожалуй, больших усилий со стороны разработчика.

При определении набора операций больше внимания следует уделять тому, что надо сделать, а не тому, как это делать.

Иногда полезно классифицировать операции класса по тому, как они работают с внутренним состоянием объектов:

  - Базовые операции: конструкторы, деструкторы, операции копирования.
  - Селекторы: операции, не изменяющие состояния объекта.
  - Модификаторы: операции, изменяющие состояние объекта.
  - Операции преобразований, т.е. операции порождающие объект другого типа, исходя из значения (состояния) объекта, к которому они применяются.
  - Повторители: операции, которые открывают доступ к объектам класса или используют последовательность объектов.

Это не есть разбиение на ортогональные группы операций. Например, повторитель может быть спроектирован как селектор или модификатор. Выделение этих групп просто предназначено помочь в процессе проектирования интерфейса класса. Конечно, допустима и другая классификация. Проведение такой классификации особенно полезно для поддержания непротиворечивости между классами в рамках одного компонента.

В языке С++ есть конструкция, помогающая заданию селекторов и модификаторов в виде функции-члена со спецификацией const и без нее. Кроме того, есть средства, позволяющие явно задать конструкторы, деструкторы и функции преобразования. Операция копирования реализуется с помощью операций присваивания и конструкторов копирования.

11.3.3.3 Шаг 3: указание зависимостей

Уточните определение классов, указав их зависимости от других классов. Различные виды зависимостей обсуждаются в $$12.2. Основными по отношению к проектированию следует считать отношения наследования и использования. Оба предполагают понимание того, что значит для класса отвечать за определенное свойство системы. Отвечать за что-либо не означает, что класс должен содержать в себе всю информацию, или, что его функции-члены должны сами проводить все необходимые операции. Как раз наоборот, каждый класс, имеющий определенный уровень ответственности, организует работу, перепоручая ее в виде подзадач другим классам, которые имеют меньший уровень ответственности. Но надо предостеречь, что злоупотребление этим приемом приводит к неэффективным и плохо понимаемым проектам, поскольку происходит размножение классов и объектов до такой степени, что вместо реальной работы производится только серия запросов на ее выполнение. То, что можно сделать в данном месте, следует сделать.

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

11.3.3.4 Шаг 4: определение интерфейсов

Определите интерфейсы классов. На этой стадии проектирования не нужно рассматривать приватные функции. Вопросы реализации, возникающие на стадии проектирования, лучше всего обсуждать на шаге 3 при рассмотрении различных зависимостей. Более того, существует золотое правило: если класс не допускает по крайней мере двух существенно отличающихся реализаций, то что-то явно не в порядке с этим классом, это просто замаскированная реализация, а не представление абстрактного понятия. Во многих случаях для ответа на вопрос: Достаточно ли интерфейс класса независим от реализации?"- надо указать, возможна ли для класса схема ленивых вычислений.

Отметим, что общие базовые классы и друзья (friend) являются частью общего интерфейса класса (см. $$5.4.1 и $$12.4). Полезным упражнением может быть определение раздельного интерфейса для классов-наследников и всех остальных классов с помощью разбиения интерфейса на общую и закрытые части.

Именно на этом шаге следует продумать и описать точные определения типов аргументов. В идеале желательно иметь максимальное число интерфейсов со статическими типами, относящимися к области приложения
(см. $$12.1.3 и $$12.4).

При определении интерфейсов следует обратить внимание на те классы, где набор операций представлен более, чем на одном уровне абстракции. Например, в классе file у некоторых функций-членов аргументы имеют тип file_descriptor (дескриптор_файла), а у других аргументы - строка символов, которая обозначает имя файла. Операции с file_descriptor работают на другом уровне (меньшем) абстракции, чем операции с именем файла, так что даже странно, что они относятся к одному классу. Возможно, было бы лучше иметь два класса: один представляет понятие дескриптора файла, а другой - понятие имени файла. Обычно все операции класса должны представлять понятия одного уровня абстракции. Если это не так, то стоит подумать о реорганизации и его, и связанных с ним классов.

11.3.3.5 Перестройка иерархии классов

 Шаги 1 и 3 требуют исследования классов и их иерархии, чтобы убедиться, что они адекватно отвечают нашим требованиям. Обычно это не так, и приходится проводить перестройку для улучшения структуры, проекта или реализации.

Самая типичная перестройка иерархии классов состоит в выделении общей части двух классов в новый класс или в разбиении класса на два новых. В обоих случаях в результате получится три класса: базовый класс и два производных. Когда следует проводить такую перестройку? Каковы общие показания, что такая перестройка будет полезной? К сожалению нет простого и универсального ответа на эти вопросы. Это и не удивительно, поскольку то, что предлагается, не является мелочью при реализации, а изменяет основные понятия системы. Важной и нетривиальной задачей является поиск общности среди классов и выделение общей части.  Нет точного определения общности, но следует обращать внимание на общность для понятий системы, а не просто для удобства реализации. Указаниями, что два класса имеют нечто общее, что возможно выделить в общий базовый класс, служат схожие способы использования, сходство наборов операций, сходство реализаций и просто тот факт, что часто в процессе обсуждения проекта оба   класса   появляются  одновременно.  С другой стороны,  если  есть несколько наборов операций класса с различными способами использования, если эти наборы обеспечивают доступ к раздельным подмножествам объектов реализации, и, если класс возникает в процессе обсуждения несвязанных тем, то этот класс является явным кандидатом для разбиения на части.

В силу тесной связи между понятиями и классами проблемы перестройки иерархии классов высвечиваются на поверхности проблем именования классов и использования имен классов в процессе обсуждения проекта. Если имена классов и их упорядоченность, задаваемая иерархией классов, кажутся неудобными при обсуждении проекта, значит, по всей видимости, есть возможность улучшения иерархии. Заметим, что подразумевается, что анализ иерархии классов лучше проводить не в одиночку. Если вы оказались в таком положении, когда не с кем обсудить проект, хорошим выходом будет попытаться составить учебное описание системы, используя имена классов.

11.3.3.6 Использование моделей

Когда пишешь статью, пытаешься найти подходящую для темы модель. Нужно не бросаться сразу печатать текст, а поискать статьи на сходные темы, вдруг найдется такая, которая может послужить отправной точкой. Если ею окажется моя собственная статья, то можно будет использовать даже куски из нее, изменяя по мере надобности другие части, и вводить новую информацию только там, где требует логика предмета. Таким образом, исходя из первого издания, написана эта книга. Предельный случай такого подхода - это написание открытки-формуляра, где просто нужно указать имя и, возможно, добавить пару строк для придания личного" отношения. По сути такие открытки пишутся с указанием отличия от стандарта.

Во всех видах творческой деятельности использование существующих систем в качестве моделей для новых проектов является скорее правилом, а не исключением. Всегда, когда это возможно, проектирование и программирование должны основываться на предыдущих работах. Это сокращает степени свободы для разработчика и позволяет сосредоточить внимание на меньшем числе вопросов в заданное время. Начать большой проект "практически с нуля" - это может возбуждать, но правильнее будет употребить термин "опьянение", которое приведет к "пьяному блужданию" в множестве вариантов. Построение модели не накладывает каких-либо ограничений и не означает покорного следования ей, это просто освобождает разработчика от некоторых вопросов.

Заметим, что на самом деле использование моделей неизбежно, поскольку каждый проект синтезируется из опыта его разработчиков. Лучше, когда использование модели является явно сформулированным решением, тогда все допущения делаются явно, определяется общий словарь терминов, появляется начальный каркас проекта и увеличивается вероятность того, что у разработчиков есть общий подход.

Естественно, что выбор начальной модели является важным решением, и обычно оно принимается только после поиска потенциальных моделей и тщательной оценки вариантов. Более того, во многих случаях модель подходит только при условии понимания того, что потребуются значительные изменения для воплощения ее идей в иной области приложения. Но проектирование программного обеспечения - тяжелый труд, и надо использовать любую помощь. Не следует отказываться от использования моделей из-за неоправданного пренебрежения к имитации. Имитация - не что иное, как форма искреннего восхищения, а, с учетом права собственности и авторского права, использование моделей и предшествующих работ в качестве источника вдохновения -
допустимый способ для всех новаторских работ во всех видах деятельности. То, что было позволено Шекспиру, подходит и для нас. Некоторые обозначают использование моделей в процессе проектирования как "проектирование повторного использования".

11.3.4 Эксперимент и анализ

В начале честолюбивого проекта нам неизвестен лучший способ построения системы. Часто бывает так, что мы даже не знаем точно, что должна делать система, поскольку конкретные факты прояснятся только в процессе построения, тестирования и эксплуатации системы. Как задолго до создания законченной системы получить сведения, необходимые для понимания того, какие решения при проектировании окажутся существенными, и к каким последствиям они приведут? Нужно проводить эксперименты. Конечно, нужен анализ проекта и его реализации, как только появляется пища для него. Преимущественно обсуждение вертится вокруг альтернатив при проектировании и реализации. За исключением редких случаев проектирование есть социальная активность, которая ведет по пути презентации и обсуждений. Часто самым важным средством проектирования оказывается простая грифельная доска; без нее идеи проекта, находящиеся в зародыше, не могут развиться и стать общим достоянием в среде разработчиков и программистов.

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

Такой подход, если применять его разумно, может привести к успеху. Но он также может служить оправданием неудачно сделанных систем. Дело в том, что уделяя особое внимание прототипу, можно прийти к смещению усилий от "исследование вариантов проекта" к "получение как можно скорее рабочей версии системы". Тогда быстро угаснет интерес к внутренней структуре прототипа
("ведь это только прототип"), а работа по проектированию будет вытесняться манипулированием с реализацией прототипа.  Просчет заключается в том, что такая реализация может легко привести к системе, которая имеет вид "почти законченной", а по сути является пожирателем ресурсов и кошмаром для тех, кто ее сопровождает. В этом случае на прототип тратятся время и энергия, которые лучше приберечь для реальной системы. Для разработчиков и менеджеров есть искушение переделать прототип в конечный программный продукт, а "искусство настройки системы" отложить до выпуска следующей версии. Если идти таким путем, то прототипы отрицают все основы проектирования.

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

И в то же время создание прототипов может сыграть важную роль. Рассмотрим, например, проектирование пользовательского интерфейса. Для этой задачи внутренняя структура той части системы, которая прямо не общается с пользователем, обычно не важна, и использование прототипов - это единственный способ узнать, какова будет реакция пользователя при работе с системой. Другим примером служат прототипы, прямо предназначенные для изучения внутренней структуры системы. Здесь уже интерфейс с пользователем может быть примитивным, возможна работа с моделью пользователей.

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

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

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

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

Помимо экспериментов, предназначенных для оценки решений, принимаемых на этапе проектирования, источником получения полезной информации может быть анализ собственно проектирования и (или)
реализации. Например, может оказаться полезным изучение различных зависимостей между классами (см.$$ 12.2), не следует забывать и о таких традиционных вспомогательных средствах реализации, как граф вызовов функций, оценка производительности и т.п.

Заметим, что спецификация (результат анализа системы) и проект могут содержать ошибки, как и реализация, и возможно, они даже больше подвержены ошибкам, т.к. являются менее точными, не могут быть проверены на практике и обычно не окружены такими развитыми средствами, как те, что служат для анализа и проверки реализации. Введение большей формализации в язык или запись, с помощью которой изложен проект, в какой-то степени облегчает использования этих средств для проектирования. Но, как сказано в $$12.1.1, это нельзя делать за счет ухудшения языка, используемого для реализации. К тому же формальная запись может сама стать источником трудностей и проблем. Это происходит, когда выбранная степень формализации плохо подходит для конкретных задач, когда строгость формализации превосходит математическую основу системы и квалификацию разработчиков и программистов, и когда формальное описание системы начинает расходиться с реальной системой, для которой оно предназначалось.

Заключение о необходимости опыта и о том, что проектирование неизбежно сопровождается ошибками и плохо поддержано программными средствами, служит основным доводом в пользу итеративной модели проектирования и реализации. Альтернатива - это линейная модель процесса развития, начиная с анализа и кончая тестированием, но она существенно дефектна, поскольку не допускает повторных проходов, исходя из опыта, полученного на различных этапах развития системы.

11.3.5 Тестирование

Программа, которая не прошла тестирование, не работает. Идеал, чтобы после проектирования и (или) верификации программа заработала с первого раза, недостижим для всех, за исключением самых тривиальных программ. Следует стремиться к идеалу, но не заблуждаться, что тестирование простое дело.

"Как проводить тестирование?" - на этот вопрос нельзя ответить в общем случае. Однако, вопрос "Когда начинать тестирование?" имеет такой ответ - на самом раннем этапе, где это возможно. Стратегия тестирования должна быть разработана как часть проекта и включена в реализацию, или, по крайней мере, разрабатываться параллельно с ними. Как только появляется работающая система, надо начинать тестирование. Откладывание тестирования до "проведения полной реализации" - верный способ выйти из графика или передать версию с ошибками.

Всюду, где это возможно, проектирование должно вестись так, чтобы тестировать систему было достаточно просто. В частности, имеет смысл средства тестирования прямо встраивать в систему. Иногда это не делается из-за боязни слишком объемных проверок на стадии выполнения, или из-за опасений, что избыточность, необходимая для полного тестирования, излишне усложнит структуры данных. Обычно такие опасения неоправданы, поскольку собственно программы проверки и дополнительные конструкции, необходимые для них, можно при необходимости удалить из системы перед ее поставкой пользователю. Иногда могут пригодится утверждения о свойствах программы (см. $$12.2.7).

Более важной, чем набор тестов, является подход, когда структура системы такова, что есть реальные шансы убедить себя и пользователей, что ошибки можно исключить с помощью определенного набора статических проверок, статического анализа и тестирования. Если разработана стратегия построения системы, устойчивой к ошибкам
(см.$$9.8), стратегия тестирования обычно разрабатывается как вспомогательная.

Если вопросы тестирования полностью игнорируются на этапе проектирования, возникнут проблемы с тестированием, временем поставки и сопровождением системы. Лучше всего начать работать над стратегией тестирования с интерфейсов классов и их взаимозависимостей (как предлагается в $$12.2 и $$12.4).

Трудно определить необходимый объем тестирования. Однако, очевидно, что проблему представляет недостаток тестирования, а не его избыток. Сколько именно ресурсов в сравнении с проектированием и реализацией следует отвести для тестирования зависит от природы системы и методов ее построения. Однако, можно предложить следующее правило: отводить больше ресурсов времени и человеческих усилий на тестирование системы, чем на получения ее первой реализации.

11.3.6 Сопровождение

"Сопровождение программного обеспечения" - неудачный термин. Слово сопровождение" предлагает неверную аналогию с аппаратурой. Программы не требуют смазки, не имеют движущихся частей, которые изнашиваются так, что требуют замены, у них нет трещин, в которые попадает вода, вызывая ржавчину. Программы можно воспроизводить в точности и передавать в течении минуты на длинные расстояния. Короче, программы это совсем не то, что аппаратура. (В оригинале: "Software is not hardware").

Деятельность, которая обозначается, как сопровождение программ, на самом деле, состоит из перепроектирования и повторной реализации, а значит входит в обычный цикл развития программного обеспечения. Если в проекте учтены вопросы расширяемости, гибкости и переносимости, то обычные задачи сопровождения решаются естественным образом.

Подобно тестированию задачи сопровождения не должны решаться вне основного направления развития проекта и их не следует откладывать на потом.

11.3.7 Эффективность

Д. Кнуту принадлежит утверждение "Непродуманная оптимизация - корень всех бед". Некоторые слишком хорошо убедились в справедливости этого и считают вредными все заботы об оптимизации. На самом деле вопросы эффективности надо все время иметь в виду во время проектирования и реализации. Это не означает, что разработчик должен заниматься задачами локальной оптимизации, только задача оптимизации на самом глобальном уровне должна его волновать.

Лучший способ добиться эффективности - это создать ясный и простой проект. Только такой проект может остаться относительно устойчивым на весь период развития и послужить основой для настройки системы с целью повышения производительности. Здесь важно избежать "гаргантюализма", который является проклятием больших проектов. Слишком часто люди добавляют определенные возможности системы "на всякий случай" (см. $$11.3.3.2 и $$11.4.3), удваивая, учетверяя размер выполняемой программы ради завитушек. Еще хуже то, что такие усложненные системы трудно поддаются анализу, а по этому трудно отличить избыточные накладные расходы от необходимых и провести анализ и оптимизации на общем уровне. Оптимизация должна быть результатом анализа и оценки производительности системы, а не произвольным манипулированием с программным кодом, причем это особенно справедливо для больших систем, где интуиция разработчика или программиста не может служить надежным указателем в вопросах эффективности.

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

11.4 Управление проектом

Если только это имеет какой-то смысл, большинство людей делает то, что их поощряют делать. Так, в контексте программного проекта, если менеджер поощряет определенные способы действий и наказывает за другие, редкие программисты или разработчики рискнут своим положением, встречая сопротивления или безразличия администрации, чтобы делать так, как они полагают нужнымЬ. Ь Организация, в которой считают своих программистов недоумками, очень скоро получит программистов, которые будут рады и способны действовать только как недоумки. Отсюда следует, что менеджер должен поощрять такие структуры, которые соответствуют сформулированным целям проекта и реализации. Однако на практике слишком часто бывает иначе. Существенное изменение стиля программирования достижимо только при соответствующем изменении в стиле проектирования, кроме того, обычно и то и другое требует изменения в стиле управления. Мыслительная и организационная инерция слишком просто сводят все к локальным изменениям, хотя только глобальные изменения могут принести успех. Прекрасной иллюстрацией служит переход на язык с объектно-ориентированным программированием, например на С++, когда он не влечет за собой соответствующих изменений в методах проектирования, чтобы воспользоваться новыми возможностями языка (см. $$12.1), и, наоборот, когда переход на "объектно-ориентированное проектирование" не сопровождается переход на язык реализации, который поддерживает этот стиль.

11.4.1 Повторное использование

Часто основной причиной перехода на новый язык или новый метод проектирования называют то, что это облегчает повторное использование программ или проекта. Однако, во многих организациях поощряют сотрудника или группу, когда они предпочитают изобретать колесо. Например, если производительность программиста измеряется числом строк программы, то будет ли он писать маленькие программы, работающие со стандартными библиотеками, за счет своего дохода и, может быть, положения? А менеджер, если он оплачивается пропорционально числу людей в его группе, будет ли он использовать программы, сделанные другими коллективами, если он может просто нанять еще пару программистов в свою группу? Компания может получить правительственный контракт, в котором ее доход составляет фиксированный процент от расходов на проект, будет ли она сокращать свой доход за счет использования наиболее эффективных средств? Трудно обеспечить вознаграждение за повторное использование, но если администрация не найдет способов поощрения и вознаграждения, то его просто не будет.

Повторное использование является прежде всего социальным фактором. Повторное использование программы возможно при условии, что

   [1] она работает; нельзя использовать повторно, если это невозможно и в первый раз;
   [2] она понятна; здесь имеет значение структура программы, наличие комментариев, документации, руководства;
   [3] она может работать вместе с программами, которые не создавались специально с таким условием;
   [4] можно рассчитывать на ее сопровождение (или придется делать это самому, что обычно не хочется);
   [5] это выгодно (хотя можно и разделить расходы по разработке и сопровождению с другими пользователями) и, наконец;
   [6] ее можно найти.

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

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

Нельзя недооценивать такие группы "стандартных компонентов". Укажем, что в первом приближении, система отражает организацию, которая ее создала. Если в организации нет средств поощрения и вознаграждения кооперации и разделения труда, то и на практике они будут исключением. Группа стандартных компонентов должна активно предлагать свои компоненты. Обычная традиционная документация важна, но ее недостаточно. Помимо этого указанная группа должна предоставлять руководства и другую информацию, которая позволит потенциальному пользователю отыскать компонент и понять как он может ему помочь. Значит эта группа должна предпринимать действия, которые обычно связываются с системой образования и маркетинга. Члены группы компонентов должны всегда, когда это возможно, работать в тесном сотрудничестве с разработчиками из областей приложения. Только тогда они будут в курсе запросов пользователей и сумеют почуять возможности использования стандартного компонента в различных областях. Это является аргументом за использование такой группы в роли консультанта и в пользу внутренних поставок программ, чтобы информация из группы компонентов могла свободно распространяться.

Заметим, что не все программы должны быть рассчитаны на повторное использование, иными словами, повторное использование не является универсальным свойством. Сказать, что некоторый компонент может быть повторно использован, означает, что в рамках определенной структуры его повторное использование не потребует значительных усилий. Но в большинстве случаев перенос в другую структуру может потребовать большой работы. В этом смысле повторное использование сильно напоминает переносимость. Важно понимать, что повторное использование является результатом проектирования, ставившего такую цель, модификации компонентов на основе опыта и специальных усилий, предпринятых для поиска среди существующих компонентов кандидатов на повторное использование. Неосознанное использование средств языка или приемов программирования не может чудесным образом гарантировать повторное использование. Такие средства языка С++, как классы, виртуальные функции и шаблоны типа, способствуют проектированию, облегчающему повторное использование (значит делают его более вероятным), но сами по себе эти средства не гарантируют повторное использование.

11.4.2 Размер

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

Вернемся к этапам процесса развития, перечисленным в $$11.3, и к шагам проектирования, указанным в $$11.3.3. Относительно просто переработать эти этапы в точный метод проектирования, когда шаг точно определен, имеет хорошо определенные входные и выходные данные и полуформальную запись для задания входных и выходных данных. Можно составить протокол, которому должно подчиняться проектирование, создать средства, предоставляющие определенные удобства для записи и организации процесса. Далее, исследуя классификацию зависимостей, приведенную в $$12.2, можно постановить, что определенные зависимости являются хорошими, а другие следует считать плохими, и предоставить средства анализа, которые обеспечат проведение таких оценок во всех стадиях проекта. Чтобы завершить такую "стандартизацию" процесса создания программ, можно было бы ввести стандарты на документацию
(в том числе правила на правописание и грамматику и соглашения о формате документации), а так же стандарты на общий вид программ
(в том числе указания какие средства языка следует использовать, а какие нет, перечисление допустимых библиотек и тех, которые не нужно использовать, соглашения об именовании функций, типов, переменных, правила расположения текста программы и т.д.).

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

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

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

Основная проблема состоит в определении степени формализации, пригодной для процесса развития конкретного проекта. Не рассчитывайте легко найти ее решение. По сути для малого проекта каждый метод может сработать. Еще хуже то, что похоже практически каждый метод, даже если он плохо продуман и жесток по отношению к исполнителям, может сработать для большого проекта, если вы готовы затратить уйму времени и денег.

В процессе развития программного обеспечения главная задача - сохранить целостность проекта. Трудность этой задачи зависит нелинейно от размера проекта. Сформулировать и сохранить основные установки в большом проекте может только один человек или маленькая группа. Большинство людей тратит столько времени на решение подзадач, технические детали, повседневную административную работу, что общие цели проекта легко забывает или заменяет их на более локальные и близкие цели. Верный путь к неудаче, когда нет человека или группы с прямым заданием следить за целостностью проекта. Верный путь к неудаче, когда у такого человека или группы нет средств воздействовать на проект в целом.

Отсутствие согласованных дальних целей намного более опасно для проекта и организации, чем отсутствие какого-либо одного конкретного свойства. Небольшая группа людей должна сформулировать такие общие цели, постоянно держать их в уме, составить документы, содержащие самое общее описание проекта, составить пояснения к основным понятиям, и вообще, помогать всем остальным помнить о назначении проекта.

11.4.3 Человеческий фактор

Описанный здесь метод проектирования рассчитан на искусных разработчиков и программистов, поэтому от их подбора зависит успех организации.

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

Многие системы оценок производительности программиста поощряют расточительность и не могут учесть существенный личный вклад человека. Самым очевидным примером служит широко распространенная практика оценивать успех в количестве запрограммированных строк, выданных страниц документации, пропущенных тестов и т.п. Такие цифры эффектно выглядят на диаграммах, но имеют самое отдаленное отношение к действительности. Например, если производительность измерять числом запрограммированных строк, то удачное повторное использование ухудшит оценку труда программиста. Обычно тот же эффект будет иметь удачное применение лучших приемов в процессе перепроектирования большой части системы.

Качество результата измерить значительно труднее, чем количество, и  вознаграждать исполнителя или группу следует за качество их труда, а не на основе грубых количественных оценок. К сожалению, насколько известно, практическая разработка способов оценки качества еще не началась. К тому же оценки, которые неполно описывают состояние проекта, могут исказить процесс его развития. Люди приспосабливаются, чтобы уложиться в отведенный срок и перестраивают свою работу в соответствии с оценками производительности, в результате страдает общая целостность системы и ее производительность. Например, если отведен срок для выявления определенного числа ошибок, то для того, чтобы уложиться в него, активно используют проверки на стадии выполнения, что ухудшает производительность системы. Обратно, если учитываются только характеристики системы на стадии выполнения, то число невыявленных ошибок будет расти при условии недостатка времени у исполнителей. Отсутствие хороших и разумных оценок качества повышает требования к технической квалификации менеджеров, иначе будет постоянная тенденция поощрять произвольную активность, а не реальный прогресс. Не надо забывать, что менеджеры тоже люди, и они должны по крайней мере настолько разбираться в новых технологиях, как и те, кем они управляют.

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

Если мы рассматриваем только достаточно большие временные сроки и отказываемся от методов управления, рассчитанных на взаимозаменяемых недоумков", то надо признать, что индивидууму
(как разработчику или программисту, так и менеджеру) нужен большой срок, чтобы дорасти до более интересной и важной работы. Такой подход не одобряет как "скакание" с места на место, так и передачу работы другому из-за карьерных соображений. Целью должен быть низкий оборот ключевых специалистов и ключевых менеджеров. Никакой менеджер не добьется успеха без подходящих технических знаний и взаимопонимания с основными разработчиками и программистами. В тоже время, в конечном счете никакая группа разработчиков или программистов не добьется успеха без поддержки компетентных менеджеров и без понимания хотя бы основных нетехнических вопросов, касающихся окружения, в котором они работают.

Когда требуется предложить нечто новое, на передний план выходят основные специалисты - аналитики, разработчики, программисты. Именно они должны решить трудную и критическую задачу внедрения новой технологии. Это те люди, которые должны овладеть новыми методами и во многих случаях забыть старые привычки. Это не так легко. Ведь эти люди сделали большой личный вклад в создание старых методов и свою репутацию как специалиста обосновывают успехами, полученными с помощью старых методов. Так же обстоит дело и с многими менеджерами.

Естественно у таких людей есть страх перед изменениями. Он может привести к преувеличению проблем, возникающих при изменениях, и к нежеланию признать проблемы, вызванные старыми методами. Естественно, с другой стороны люди, выступающие за изменения, могут переоценивать выгоды, которые принесут изменения, и недооценивать возникающие здесь проблемы. Эти две группы людей должны общаться, они должны научиться говорить на одном языке и должны помочь друг другу разработать подходящую схему перехода. Альтернативой будет организационный паралич и уход самых способных людей из обоих групп. Тем и другим следует знать, что самые удачливые из "старых ворчунов" могли быть "молодыми львами" в прошлом году, и если человеку дали возможность научиться без всяких издевательств, то он может стать самым стойким и разумным сторонником перемен. Он будет обладать неоценимыми свойствами здорового скептицизма, знания пользователей и понимания организационных препятствий. Сторонники немедленных и радикальных изменений должны осознать, что гораздо чаще  нужен переход, предполагающий постепенное внедрение новых методов. С другой стороны, те, кто не желает перемен, должны поискать для себя такие области, где это возможно, чем вести ожесточенные, арьергардные бои в той области, где новые требования уже задали совершенно иные условия для успешного проекта.

11.5 Свод правил

В этой главе мы затронули много тем, но как правило не давали настоятельных и конкретных рекомендаций по проектированию. Это соответствует моему убеждению, что нет "единственно верного решения". Принципы и приемы следует применять тем способом, который лучше подходит для конкретных задач. Для этого нужен вкус, опыт и разум. Все-таки можно указать некоторый свод правил, который разработчик может использовать в качестве ориентиров, пока не наберется достаточно опыта, чтобы выработать лучшие. Ниже приведен свод таких правил.

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

   - Узнайте, что вам предстоит создать.
   - Ставьте определенные и осязаемые цели.
   - Не пытайтесь с помощью технических приемов решить социальные проблемы.
   - Рассчитывайте на большой срок
     - в проектировании, и
     - управлении людьми.
   - Используйте существующие системы в качестве моделей, источника вдохновения и отправной точки.
   - Проектируйте в расчете на изменения:
     - гибкость,
     - расширяемость,
     - переносимость, и
     - повторное использование.
   - Документируйте, предлагайте и поддерживайте повторно используемые компоненты.
   - Поощряйте и вознаграждайте повторное использование
     - проектов,
     - библиотек, и
     - классов.
   - Сосредоточьтесь на проектировании компоненты.
     - Используйте классы для представления понятий.
     - Определяйте интерфейсы так, чтобы сделать открытым минимальный объем информации, требуемой для интерфейса.
     - Проводите строгую типизацию интерфейсов всегда, когда это возможно.
     - Используйте в интерфейсах типы из области приложения всегда, когда это возможно.
   - Многократно исследуйте и уточняйте как проект, так и реализацию.
   - Используйте лучшие доступные средства для проверки и анализа
     - проекта, и
     - реализации.
   - Экспериментируйте, анализируйте и проводите тестирование на самом раннем возможном этапе.
   - Стремитесь к простоте, максимальной простоте, но не сверх того.
   - Не разрастайтесь, не добавляйте возможности "на всякий случай".
   - Не забывайте об эффективности.
   - Сохраняйте уровень формализации, соответствующим размеру проекта.
   - Не забывайте, что разработчики, программисты и даже менеджеры остаются людьми.

Еще некоторые правила можно найти в $$12.5

11.6 Список литературы с комментариями

В этой главе мы только поверхностно затронули вопросы проектирования и управления программными проектами. По этой причине ниже предлагается список литературы с комментариями. Значительно более обширный список литературы с комментариями можно найти в [2].
[1] Bruce Anderson and Sanjiv Gossain: An Iterative Design Model for
    Reusable Object-Oriented Software. Proc. OOPSLA'90. Ottawa,
    Canada. pp. 12-27.

Описание модели итеративного проектирования и повторного проектирования с некоторыми примерами и обсуждением результатов.
[2] Grady Booch: Object Oriented Design. Benjamin Cummings. 1991.

В этой книге есть детальное описание проектирования, определенный метод проектирования с графической формой записи и несколько больших примеров проекта, записанных на различных языках. Это превосходная книга, которая во многом повлияла на эту главу. В ней более глубоко рассматриваются многие из затронутых здесь вопросов.
[3] Fred Brooks: The Mythical Man Month. Addison Wesley. 1982.

Каждый должен перечитывать эту книгу раз в пару лет.

Предостережение от высокомерия. Она несколько устарела в технических вопросах, но совершенно не устарела во всем, что касается отдельного работника, организации и вопросов размера.
[4] Fred Brooks: No Silver Bullet. IEEE Computer, Vol.20 No.4.
    April 1987.

Сводка различных подходов к процессу развития больших программных систем с очень полезным предостережением от веры в магические рецепты ("золотая пуля").
[5] De Marco and Lister: Peopleware. Dorset House Publishing Co. 1987.

Одна из немногих книг, посвященных роли человеческого фактора в производстве программного обеспечения. Необходима для каждого менеджера. Достаточно успокаивающая для чтения перед сном.

Лекарство от многих глупостей.
[6] Ron Kerr: A Materialistic View of the Software "Engineering"
    Analogy. in SIGPLAN Notices, March 1987. pp 123-125.

Использование аналогии в этой и следующей главах во многом обязано наблюдениям из указанной статьи, а так же беседам с Р. Керром, которые этому предшествовали.
[7] Barbara Liskov: Data Abstraction and Hierarchy. Proc. OOPSLA'87
    (Addendum). Orlando, Florida. pp 17-34.

Исследуется как использование наследования может повредить концепции абстрактных данных. Укажем, что в С++ есть специальные языковые средства, помогающие избежать большинство указанных проблем ($$12.2.5).
[8] C. N. Parkinson: Parkinson's Law and other Studies in
    Administration. Houghton-Mifflin. Boston. 1957.

Одно из забавных и самых язвительных описаний бед, к которым приводит процесс администрирования.
[9] Bertrand Meyer: Object Oriented Software Construction.
    Prentice Hall. 1988.

Страницы 1-64 и 323-334 содержат хорошее описание одного взгляда на объектно-ориентированное программирование и проектирование, а также много здравых, практических советов. В остальной части книги описывается язык Эйффель (Eiffel).
[10] Alan Snyder: Encapsulation and Inheritance in Object-Oriented
    Programming Languages. Proc. OOPSLA'86. Portland, Oregon. pp.38-45.

Возможно первое хорошее описание взаимодействия оболочки и наследования. В статье так же на хорошем уровне рассматриваются некоторые понятия, связанные с множественным наследованием.
[11] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener:
    Designing Object-Oriented Software. Prentice Hall. 1990.

Описывается антропоморфный метод проектирования основанный на специальных карточках CRC (Classes, Responsibilities,
    Collaboration) (т.е. Классы, Ответственность, Сотрудничество).

Текст, а может быть и сам метод тяготеет к языку Smalltalk.

ПРОЕКТИРОВАНИЕ И С++

        Стремись к простоте, максимальной простоте, но не сверх того.
         - А. Эйнштейн

Эта глава  посвящена связи между проектированием и языком программирования С++. В ней исследуется применение классов при проектировании и указываются определенные виды зависимостей, которые следует выделять как внутри класса, так и между классами. Изучается роль статического контроля типов. Исследуется применение наследования и связь наследования и принадлежности. Обсуждается понятие компонента и даются некоторые образцы для интерфейсов.

12.1 Проектирование и язык программирования

Если бы мне надо было построить мост, то я серьезно подумал бы, из какого материала его строить, и проект моста сильно зависел бы от выбранного материала, а, следовательно, разумные проекты каменного моста отличаются от разумных проектов металлического моста или от разумных проектов деревянного моста и т.д. Не стоит рассчитывать на выбор подходящего для моста материала без определенных знаний о материалах и их использовании. Конечно, вам не надо быть специалистом плотником для проектирования деревянного моста, но вы должны знать основы конструирования из дерева, чтобы предпочесть его металлу в качестве материала для моста. Более того, хотя для проектирования деревянного моста вы и не должны быть специалистом плотником, вам необходимо достаточно детально знать свойства дерева и еще больше знать о плотниках.

Аналогично, при выборе языка программирования для определенного программного обеспечения надо знать несколько языков, а для успешного проектирования программы надо достаточно детально знать выбранный язык реализации, даже если вам лично не предстоит написать ни одной строчки программы. Хороший проектировщик моста ценит свойства используемых им материалов и применяет их для улучшения проекта. Аналогично, хороший разработчик программ использует сильные стороны языка реализации и, насколько возможно, стремится избежать такого его использования, которое вызовет трудности на стадии реализации.

Можно подумать, что так получается естественным образом, если в проектировании участвует только один разработчик или программист, однако даже в этом случае программист в силу недостатка опыта или из-за неоправданной приверженности к стилю программирования, рассчитанному на совершенно другие языки, может сбиться на неверное использование языка. Если разработчик существенно отличается от программиста,  особенно если у них разная программистская культура, возможность появления в окончательной версии системы ошибок, неэффективных и неэлегантных решений почти наверняка превратится в неизбежность.

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

Например, многие методы проектирования уделяют значительное внимание зависимостям между различными частями программы (обычно с целью их уменьшения и гарантии того, что эти части будут понятны и хорошо определены). Язык, допускающий явное задание интерфейсов между частями программы, может помочь в этом вопросе разработчикам. Он может гарантировать, что действительно будут существовать только предполагаемые зависимости. Поскольку большинство зависимостей явно выражено в программе на таком языке, можно разработать средства, читающие программу и выдающие графы зависимостей. В этом случае разработчику и другим исполнителям легче уяснить структуру программы. Такие языки программирования как С++
помогают сократить разрыв между проектом и программой, а значит уменьшают возможность путаницы и недопониманий.

Базовое понятие С++ - это класс. Класс имеет определенный тип. Кроме того, класс является первичным средством упрятывания информации. Можно описывать программы в терминах пользовательских типов и иерархий этих типов. Как встроенные, так и пользовательские типы подчиняются правилам статического контроля типов. Виртуальные функции предоставляют, не нарушая правил статических типов, механизм связывания на этапе выполнения. Шаблоны типа позволяют создавать параметризованные типы. Особые ситуации позволяют сделать регулярной реакцию на ошибки. Все эти средства С++ можно использовать без дополнительных накладных расходов в сравнении с программой на С. Таковы главнейшие средства С++, которые должен представлять и учитывать разработчик. Кроме того, существенно повлиять на принятие решений на стадии проектирования может наличие  доступных больших библиотек следующего назначения: для работы с матрицами, для связи с базами данных, для поддержки параллельного программирования, графические библиотеки и т.д.

Страх перед новизной, непригодный здесь опыт работы на других языках, в других системах или областях приложения, бедные средства проектирования - все это приводит к неоптимальному использованию С++. Следует отметить три момента, когда разработчику не удается извлечь выгоду из возможностей С++ и учесть ограничения языка:

[1] Игнорирование классов и составление проекта таким образом, что программистам приходится ограничиваться только С.
[2] Игнорирование производных классов и виртуальных функций, использование только подмножества абстрактных данных.
[3] Игнорирование статического контроля типов и составление проекта таким образом, что программисты вынуждены применять динамические проверки типов.

Обычно указанные моменты возникают у разработчиков, связанных с:

[1] C, или традиционной системой CASE или методами структурного проектирования;
[2] Адой или методами проектирования с помощью абстракции данных;
[3] языками, близкими Smalltalk или Lisp.

В каждом случае следует решить: неправильно выбран язык реализации (считая, что метод проектирования выбран верно), или разработчику не удалось приспособиться и оценить язык (считая, что язык реализации выбран верно).

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

Отметим, что необязательно все программы должны структурироваться опираясь на понятия классов и (или) иерархий классов, и необязательно всякая программа должна использовать все средства, предоставляемые С++. Как раз наоборот, для успеха проекта необходимо, чтобы людям не навязывали использование языковых средств, с которыми они только познакомились. Цель последующего изложения не в том, чтобы навязать догматичное использование классов, иерархий и строго типизированных интерфейсов, а в том, чтобы показать возможности их использования всюду, где позволяет область приложения, ограничения С++ и опыт исполнителей. В $$12.1.4 будут рассмотрены подходы к различному использованию С++ в проекте под заголовком "Проект-гибрид".

12.1.1 Игнорирование классов

Рассмотрим первый из указанных моментов - игнорирование классов. В таком случае получившаяся программа на С++ будет приблизительно эквивалентна С-программе, разработанной по тому же проекту, и, можно сказать, что они будут приблизительно эквивалентны программам на Аде или Коболе, разработанным по нему же. По сути проект составлен как независящий от языка реализации, что принуждает программиста ограничиваться общим подмножеством языков С, Ада или Кобол. Здесь есть свои преимущества. Например, получившееся в результате строгое разделение данных и программного кода позволяет легко использовать традиционные базы данных, которые разработаны для таких программ. Поскольку используется ограниченный язык программирования, от программистов требуется меньше опытности (или, по крайней мере другой ее уровень). Для многих приложений, например, для традиционных баз данных, работающих с файлом последовательно, такой подход вполне разумен, а традиционные приемы, отработанные за десятилетия, вполне адекватны задаче.

Однако там, где область приложения существенно отличается от традиционной последовательной обработки записей (или символов), или сложность задачи выше, как, например, в диалоговой системе
CASE, недостаток языковой поддержки абстрактных данных из-за отказа от классов (если их не учитывать) повредит проекту. Сложность задачи не уменьшится, но, поскольку система реализована на обедненном языке,  структура программы плохо будет отвечать проекту. У нее слишком большой объем, не хватает проверки типов, и, вообще, она плохо приспособлена для использования различных вспомогательных средств. Это путь, приводящий к кошмарам при ее сопровождении.

Обычно для преодоления указанных трудностей создают специальные средства, поддерживающие понятия, используемые в проекте. Благодаря им создаются конструкции более высокого уровня и организуются проверки с целью компенсировать дефекты (или сознательное обеднение) языка реализации. Так метод проектирования становится самоцелью, и для него создается специальный язык программирования. Такие языки программирования в большинстве случаев являются плохой заменой широко распространенных языков программирования общего назначения, которые сопровождаются подходящими средствами проектирования. Использовать С++ с таким ограничением, которое должно компенсироваться при проектировании специальными средствами, бессмысленно. Хотя несоответствие между языком программирования и средствами проектирования может быть просто стадией процесса перехода, а значит временным явлением.

Самой типичной причиной игнорирования классов при проектировании является простая инерция. Традиционные языки программирования не предоставляют понятия класса, и в традиционных методах проектирования отражаются этот недостаток. Обычно в процессе проектирования наибольшее внимание уделяется разбиению задачи на процедуры, производящие требуемые действия. В главе 1 это понятие называлось процедурным программированием, а в области проектирования оно именуется как функциональная декомпозиция. Возникает типичный вопрос "Можно ли использовать С++ совместно с методом проектирования, базирующимся на функциональной декомпозиции?" Да, можно, но, вероятнее всего, в результате вы придете к использованию С++ как просто улучшенного С со всеми указанными выше проблемами. Это может быть приемлемо на период перехода на новый язык, или для уже завершенного проектирования, или для подзадач, в которых использование классов не дает существенных выгод (если учитывать опыт программирования на С++ к данному моменту), но в общем случае на большом отрезке времени отказ от свободного использования классов, связанный с методом функциональной декомпозиции, никак не совместим с эффективным использованием С++.

Процедурно-ориентированный и объектно-ориентированный подходы к программированию различаются по своей сути и обычно ведут к совершенно разным решениям одной задачи. Этот вывод верен как для стадии реализации, так и для стадии проектирования: вы концентрируете внимание или на предпринимаемых действиях, или на представляемых сущностях, но не на том и другом одновременно.

Тогда почему метод объектно-ориентированного проектирования предпочтительнее метода функциональной декомпозиции? Главная причина в том, что функциональная декомпозиция не дает достаточной абстракции данных. А отсюда уже следует, что проект будет

    - менее податливым к изменениям,
    - менее приспособленным для использования различных вспомогательных средств,
    - менее пригодным для параллельного развития и
    - менее пригодным для параллельного выполнения.

Дело в том, что функциональная декомпозиция вынуждает объявлять важные" данные глобальными, поскольку, если система структурирована как дерево функций, всякое данное, доступное двум функциям, должно быть глобальным по отношению к ним. Это приводит к тому, что важные" данные "всплывают" к вершине дерева, по мере того как все большее число функций требует доступа к нимЬ. Ь В точности так же происходит в случае иерархии классов с одним корнем, когда "важные" данные всплывают по направлению к базовому классу. Когда мы концентрируем внимание на описаниях классов, заключающих определенные данные в оболочку, то зависимости между различными частями программы выражены явно и можно их проследить. Еще более важно то, что при таком подходе уменьшается число зависимостей в системе за счет лучшей расстановки ссылок на данные.

Однако, некоторые задачи лучше решаются с помощью набора процедур. Смысл "объектно-ориентированного" проектирования не в том, чтобы удалить все глобальные процедуры из программы или не иметь в системе процедурно-ориентированных частей. Основная идея скорее в том, что классы, а не глобальные процедуры становятся главным объектом внимания на стадии проектирования. Использование процедурного стиля должно быть осознанным решением, а не решением, принимаемым по умолчанию. Как классы, так и процедуры следует применять сообразно области приложения, а не просто как неизменные методы проектирования.

12.1.2 Игнорирование наследования

Рассмотрим вариант 2 - проект, который игнорирует наследование. В этом случае в окончательной программе просто не используются возможности основного средства С++, хотя и получаются определенные выгоды при использовании С++ по сравнению с использованием языков С, Паскаль, Фортран, Кобол и т.п. Обычные доводы в пользу этого, помимо инерции, утверждения, что "наследование - это деталь реализации", или "наследование препятствует упрятыванию информации", или "наследование затрудняет взаимодействие с другими системами программирования".

Считать наследование всего лишь деталью реализации - значит игнорировать иерархию классов, которая может непосредственно моделировать отношения между понятиями в области приложения. Такие отношения должны быть явно выражены в проекте, чтобы дать возможность разработчику продумать их.

Сильные доводы можно привести в пользу исключения наследования из тех частей программы на С++, которые непосредственно взаимодействуют с программами, написанными на других языках. Но это не является достаточной причиной, чтобы отказаться от наследования в системе в целом, это просто довод в пользу того, чтобы аккуратно определить и инкапсулировать программный интерфейс с "внешним миром". Аналогично, чтобы избавиться от беспокойства, вызванного путаницей с упрятыванием информации при наличии наследования, надо осторожно использовать виртуальные функции и закрытые члены, но не отказываться от наследования.

Существует достаточно много ситуаций, когда использование наследования не дает явных выгод, но политика никакого наследования" приведет к менее понятной и менее гибкой системе, в которой наследование "подделывается" с помощью более традиционных конструкций языка и проектирования. Для больших проектов это существенно. Более того, вполне возможно, что несмотря на такую политику, наследование все равно будет использоваться, поскольку программисты, работающие на С++, найдут убедительные доводы в пользу проектирования с учетом наследования в различных частях системы. Таким образом, политика никакого наследования" приведет лишь к тому, что в системе будет отсутствовать целостная общая структура, а использование иерархии классов будет ограничено определенными подсистемами.

Иными словами, будьте непредубежденными. Иерархия классов не является обязательной частью всякой хорошей программы, но есть масса ситуаций, когда она может помочь как в понимании области приложения, так и в формулировании решений. Утверждение, что наследование может неправильно или чрезмерно использоваться, служит только доводом в пользу осторожности, а вовсе не в пользу отказа от него.

12.1.3 Игнорирование статического контроля типов

Рассмотрим вариант 3, относящийся к проекту, в котором игнорируется статический контроль типов. Распространенные доводы в пользу отказа на стадии проектирования от статического контроля типов сводятся к тому, что "типы - это продукт языков программирования", или что более естественно рассуждать об объектах, не заботясь о типах", или "статический контроль типов вынуждает нас думать о реализации на слишком раннем этапе". Такой подход вполне допустим до тех пор, пока он работает и не приносит вреда. Вполне разумно на стадии проектирования не заботиться о деталях проверки типов, и часто вполне допустимо на стадии анализа и начальных стадиях проектирования полностью забыть о вопросах, связанных с типами. В то же время, классы и иерархии классов очень полезны на стадии проектирования, в частности, они дают нам большую определенность понятий, позволяют точно задать взаимоотношения между понятиями и помогают рассуждать о понятиях. По мере развития проекта эта определенность и точность преобразуется во все более конкретные утверждения о классах и их интерфейсах.

Важно понимать, что точно определенные и строго типизированные интерфейсы являются фундаментальным средством проектирования. Язык С++ был создан как раз с учетом этого. Строго типизированный интерфейс гарантирует, что только совместимые части программы могут быть скомпилированы и скомпонованы воедино, и тем самым позволяет делать относительно строгие допущения об этих частях. Эти допущения обеспечиваются системой типов языка. В результате сводятся к минимуму проверки на этапе выполнения, что повышает эффективность и приводит к значительному сокращению фазы интеграции частей проекта, реализованных разными программистами. Реальный положительный опыт интеграции системы со строго типизированными интерфейсами привел к тому, что вопросы интеграции вообще не фигурируют среди основных тем этой главы.

Рассмотрим следующую аналогию: в физическом мире мы постоянно соединяем различные устройства, и существует кажущееся бесконечным число стандартов на соединения. Главная особенность этих соединений: они специально спроектированы таким образом, чтобы сделать невозможным соединение двух устройств, нерассчитанных на него, то есть соединение должно быть сделано единственным правильным способом. Вы не можете подсоединить электробритву к розетке с высоким напряжением. Если бы вы смогли сделать это, то сожгли бы бритву или сгорели сами. Масса изобретательности была проявлена, чтобы добиться невозможности соединения двух несовместимых устройств. Альтернативой одновременного использования нескольких несовместимых устройств может послужить такое устройство, которое само себя защищает от несовместимых с ним устройств, подключающихся к его входу. Хорошим примером может служить стабилизатор напряжения. Поскольку идеальную совместимость устройств нельзя гарантировать только на "уровне соединения", иногда требуется более дорогая защита в электрической цепи, которая позволяет в динамике приспособиться или (и) защититься от скачков напряжения.

Здесь практически прямая аналогия: статический контроль типов эквивалентен совместимости на уровне соединения, а динамические проверки соответствуют защите или адаптации в цепи. Результатом неудачного контроля как в физическом, так и в программном мире будет серьезный ущерб. В больших системах используются оба вида контроля. На раннем этапе проектирования вполне достаточно простого утверждения: Эти два устройства необходимо соединить"; но скоро становится существенным, как именно следует их соединить: "Какие гарантии дает соединение относительно поведения устройств?", или Возникновение каких ошибочных ситуаций возможно?", или Какова приблизительная цена такого соединения?" Применение "статической типизации" не ограничивается программным миром. В физике и инженерных науках повсеместно распространены единицы измерения (метры, килограммы, секунды), чтобы избежать смешивания несовместимых сущностей.

В нашем описании шагов проектирования в $$11.3.3 типы появляются на сцене уже на шаге 2 (очевидно, после несколько искусственного их рассмотрения на шаге 1) и становятся главной темой шага 4.

Статически контролируемые интерфейсы - это основное средство взаимодействия программных частей системы на С++, созданных разными группами, а описание интерфейсов этих частей (с учетом точных определений типов) становится основным способом сотрудничества между отдельными группами программистов. Эти интерфейсы являются основным результатом процесса проектирования и служат главным средством общения между разработчиками и программистами.

Отказ от этого приводит к проектам, в которых неясна структура программы, контроль ошибок отложен на стадию выполнения,  которые трудно хорошо реализовать на С++.

Рассмотрим интерфейс, описанный с помощью "объектов", определяющих себя самостоятельно. Возможно, например, такое описание: Функция f() имеет аргумент, который должен быть самолетом" (что проверяется самой функцией во время ее выполнения), в отличие от описания "Функция f() имеет аргумент, тип которого есть самолет" (что проверяется транслятором). Первое описание является существенно недостаточным описанием интерфейса, т.к. приводит к динамической проверке вместо статического контроля. Аналогичный вывод из примера с самолетом сделан в $$1.5.2. Здесь использованы более точные спецификации, и использован шаблон типа и виртуальные функции взамен неограниченных динамических проверок для того, чтобы перенести выявление ошибок с этапа выполнения на этап трансляции.  Различие времен работы программ с динамическим и статическим контролем может быть весьма значительным, обычно оно находится в диапазоне от 3 до 10 раз.

Но не следует впадать в другую крайность. Нельзя обнаружить все ошибки с помощью статического контроля. Например, даже программы с самым обширным статическим контролем уязвимы к сбоям аппаратуры. Но все же, в идеале нужно иметь большое разнообразие интерфейсов со статической типизацией с помощью типов из области приложения, см. $$12.4.

Может получиться, что проект, совершенно разумный на абстрактном уровне,  столкнется с серьезными проблемами, если не учитывает ограничения базовых средств, в данном случае С++. Например, использование имен, а не типов для структурирования системы приведет к ненужным проблемам для системы типов С++ и, тем самым, может стать причиной ошибок и накладных расходов при выполнении. Рассмотрим три класса:

        class X { // pseudo code, not C++
          f()
          g()
        }

        class Y {
          g()
          h()
        }

        class Z {
          h()
          f()
        }

используемые некоторыми функциями бестипового проекта:

        k(a, b, c)  // pseudo code, not C++
        {
          a.f()
          b.g()
          c.h()
        }

Здесь обращения

        X x
        Y y
        Z z

        k(x,y,z)  // ok
        k(z,x,y)  // ok

будут успешными, поскольку k() просто требует, чтобы ее первый параметр имел операцию f(), второй параметр - операцию g(), а третий параметр - операцию h().  С другой стороны обращения

     k(y,x,z);  // fail
     k(x,z,y);  // fail

завершатся неудачно. Этот пример допускает совершенно разумные реализации на языках с полным динамическим контролем (например,
Smalltalk или CLOS), но в С++ он не имеет прямого представления, поскольку язык требует, чтобы общность типов была реализована как отношение к базовому классу. Обычно примеры, подобные этому, можно представить на С++, если записывать утверждения об общности с помощью явных определений классов, но это потребует большого хитроумия и вспомогательных средств. Можно сделать, например, так:

       class F {
         virtual void f();
       };

       class G {
         virtual void g();
       };

       class H {
         virtual void h();
       };

       class X : public virtual F, public virtual G {
         void f();
         void g();
       };

       class Y : public virtual G, public virtual H {
         void g();
         void h();
       };

       class Z : public virtual H, public virtual F {
         void h();
         void f();
       };

       k(const F& a, const G& b, const H& c)
       {
         a.f();
         b.g();
         c.h();
        }

        main()
        {
          X x;
          Y y;
          Z z;

          k(x,y,z);  // ok
          k(z,x,y);  // ok

          k(y,x,z);  // error F required for first argument
          k(x,z,y);  // error G required for second argument
         }

Обратите внимание, что сделав предположения k() о своих аргументах явными, мы переместили контроль ошибок с этапа выполнения на этап трансляции. Сложные примеры, подобные приведенному, возникают, когда пытаются реализовать на С++ проекты, сделанные на основе опыта работы с другими системами типов. Обычно это возможно, но в результате получается неестественная и неэффективная программа. Такое несовпадение между приемами проектирования и языком программирования можно сравнить с несовпадением при пословном переводе с одного естественного языка на другой. Ведь английский с немецкой грамматикой выглядит столь же неуклюже, как и немецкий с английской грамматикой, но оба языка могут быть доступны пониманию того, кто бегло говорит на одном из них.

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

12.1.4 Гибридный проект

Переход на новые методы работы может быть мучителен для любой организации. Раскол внутри нее и расхождения между сотрудниками могут быть значительными. Но резкий решительный переход, способный в одночасье превратить эффективных и квалифицированных сторонников "старой школы" в неэффективных новичков "новой школы" обычно неприемлем. В то же время, нельзя достичь больших высот без изменений, а значительные изменения обычно связаны с риском.

Язык С++ создавался с целью сократить такой риск за счет постепенного введения новых методов. Хотя очевидно, что наибольшие преимущества при использовании С++ достигаются за счет абстракции данных, объектно-ориентированного программирования и объектно-ориентированного проектирования, совершенно неочевидно, что быстрее всего достичь этого можно решительным разрывом с прошлым. Вряд ли такой явный разрыв будет возможен, обычно стремление к усовершенствованиям сдерживается или должно сдерживаться, чтобы переход к ним был управляемым.  Нужно учитывать следующее:

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

Здесь рассматриваются как раз ситуации, связанные с перечисленными требованиями. Легко недооценить два первых требования.

Поскольку в С++ возможны несколько схем программирования, язык допускает постепенный переход на него, используя следующие преимущества такого перехода:

  - Изучая С++, программисты могут продолжать работать.
  - В окружении, бедном на программные средства, использование С++
    может принести значительные выгоды.
  - Программы, написанные на С++, могут хорошо взаимодействовать с программами, написанными на С или других традиционных языках.
  - Язык имеет большое подмножество, совместимое с С.

Идея заключается в постепенном переходе программиста с традиционного языка на С++: вначале он программирует на С++ в традиционном процедурном стиле, затем с помощью методов абстракции данных, и наконец, когда овладеет языком и связанными с ним средствами, полностью переходит на объектно-ориентированное программирование. Заметим, что хорошо спроектированную библиотеку использовать намного проще, чем проектировать и реализовывать, поэтому даже с первых своих шагов новичок может получить преимущества, используя более развитые средства С++.

Идея постепенного, пошагового овладения С++, а также возможность смешивать программы на С++ с программами, написанными на языках, не имеющих средств абстракции данных и объектно-ориентированного программирования, естественно приводит к проекту, имеющему гибридный стиль. Большинство интерфейсов можно пока оставить на процедурном уровне, поскольку что-либо более сложное не принесет немедленного выигрыша. Например, обращение к стандартной библиотеке math из С определяется на С++ так:

     extern "C" {
        #include <math.h>
     }

и стандартные математические функции из библиотеки можно использовать так же, как и в С. Для всех основных библиотек такое включение должно быть сделано теми, кто поставляет библиотеки, так что программист на С++ даже не будет знать, на каком языке реализована библиотечная функция. Использование библиотек, написанных на таких языках как С, является первым и вначале самым важным способом повторного использования на С++.

На следующем шаге, когда станут необходимы более сложные приемы, средства, реализованные на таких языках как С или Фортран, представляются в виде классов за счет инкапсуляции структур данных и функций в интерфейс классов С++. Простым примером введения более высокого семантического уровня за счет перехода от уровня процедур плюс структур данных к уровню абстракции данных может служить класс строк из $$7.6. Здесь за счет инкапсуляции символьных строк и стандартных строковых функций С получается новый строковый тип, который гораздо проще использовать.

Подобным образом можно включить в иерархию классов любой встроенный или отдельно определенный тип. Например, тип int
можно включить в иерархию классов так:

         class Int : public My_object {
           int i;
         public:
           // definition of operations
           // see exercises [8]-[11] in section 7.14 for ideas
           // определения операций получаются в упражнениях [8]-[11]
           // за идеями обратитесь к разделу 7.14
         }; 

Так следует делать, если действительно есть потребность включить такие типы в иерархию.

Обратно, классы С++ можно представить в программе на С или Фортране как функции и структуры данных. Например:

          class myclass {
             // representation
          public:
            void f();
            T1 g(T2);
            // ...
          };

          extern "C" {  // map myclass into C callable functions:

            void myclass_f(myclass* p) { p->f(); }
            T1 myclass_g(myclass* p, T2 a) { return p->g(a); }
            // ...
          }; 

В С-программе следует определить эти функции в заголовочном файле следующим образом:

  // in C header file

  extern void myclass_f(struct myclass*);
  extern T1 myclass_g(struct myclass*, T2); 

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

12.2 Классы

Основное положение объектно-ориентированного проектирования и программирования заключается в том, что программа служит моделью некоторых понятий реальности. Классы в программе представляют основные понятия области приложения и, в частности, основные понятия самого процесса моделирования реальности. Объекты классов представляют предметы реального мира и продукты процесса реализации.

Мы рассмотрим структуру программы с точки зрения следующих взаимоотношений между классами:

   - отношения наследования,
   - отношения принадлежности,
   - отношения использования и
   - запрограммированные отношения.

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

Подчеркнем, что класс в С++ является типом, поэтому сами классы и взаимоотношения между ними обеспечены значительной поддержкой со стороны транслятора и в общем случае поддаются статическому анализу.

12.2.1 Что представляют классы?

По сути в системе бывают классы двух видов:

[1] классы, которые прямо отражают понятия области приложения, т.е. понятия, которые использует конечный пользователь для описания своих задач и возможных решений; и
[2] классы, которые являются продуктом самой реализации, т.е. отражают понятия, используемые разработчиками и программистами для описания способов реализации.

Некоторые из классов, являющихся продуктами реализации, могут представлять и понятия реального мира. Например, программные и аппаратные ресурсы системы являются хорошими кандидатами на роль классов, представляющих область приложения. Это отражает тот факт, что систему можно рассматривать с нескольких точек зрения, и то, что с одной является деталью реализации, с другой может быть понятием области приложения. Хорошо спроектированная система должна содержать классы, которые дают возможность рассматривать систему с логически разных точек зрения. Приведем пример:

  [1] классы, представляющие пользовательские понятия (например, легковые машины и грузовики),
  [2] классы, представляющие обобщения пользовательских понятий (движущиеся средства),
  [3] классы, представляющие аппаратные ресурсы (например, класс управления памятью),
  [4] классы, представляющие системные ресурсы (например, выходные потоки),
  [5] классы, используемые для реализации других классов (например, списки, очереди, блокировщики) и
  [6] встроенные типы данных и структуры управления. В больших системах очень трудно сохранять логическое разделение типов различных классов и поддерживать такое разделение между различными уровнями абстракции. В приведенном выше перечислении представлены три уровня абстракции:
  [1+2] представляет пользовательское отражение системы,
  [3+4] представляет машину, на которой будет работать система,
  [5+6] представляет низкоуровневое (со стороны языка программирования) отражение реализации. Чем больше система, тем большее число уровней абстракции необходимо для ее описания, и тем труднее определять и поддерживать эти уровни абстракции. Отметим, что таким уровням абстракции есть прямое соответствие в природе и в различных построениях человеческого интеллекта. Например, можно рассматривать дом как объект, состоящий из
  [1] атомов,
  [2] молекул,
  [3] досок и кирпичей,
  [4] полов, потолков и стен;
  [5] комнат.

Пока удается хранить раздельно представления этих уровней абстракции, можно поддерживать целостное представление о доме. Однако, если смешать их, возникнет бессмыслица. Например, предложение Мой дом состоит из нескольких тысяч фунтов углерода, некоторых сложных полимеров, из 5000 кирпичей, двух ванных комнат и 13 потолков" - явно абсурдно. Из-за абстрактной природы программ подобное утверждение о какой-либо сложной программной системе далеко не всегда воспринимают как бессмыслицу.

В процессе проектирования выделение понятий из области приложения в класс вовсе не является простой механической операцией. Обычно эта задача требует большой проницательности. Заметим, что сами понятия области приложения являются абстракциями. Например, в природе не существуют "налогоплательщики", "монахи" или "сотрудники". Эти понятия не что иное, как метки, которыми обозначают бедную личность, чтобы классифицировать ее по отношению к некоторой системе. Часто реальный или воображаемый мир (например, литература, особенно фантастика) служат источником понятий, которые кардинально преобразуются при переводе их в классы. Так, экран моего компьютера (Маккинтош) совсем не походит на поверхность моего стола, хотя компьютер создавался с целью реализовать понятие "настольный" Ь, а окна на моем дисплее имеют самое отдаленное отношение к приспособлениям для презентации чертежей в моей комнате. Ь Я бы не вынес такого беспорядка у себя на экране. Суть моделирования реальности не в покорном следовании тому, что мы видим, а в использовании реальности как начала для проектирования, источника вдохновения и как якоря, который удерживает, когда стихия программирования грозит лишить нас способности понимания своей собственной программы.

Здесь полезно предостеречь: новичкам обычно трудно "находить" классы, но вскоре это преодолевается без каких-либо неприятностей. Далее обычно приходит этап, когда классы и отношения наследования между ними бесконтрольно множатся. Здесь уже возникают проблемы, связанные со сложностью, эффективностью и ясностью полученной программы. Далеко не каждую отдельную деталь следует представлять отдельным классом, и далеко не каждое отношение между классами следует представлять как отношение наследования. Старайтесь не забывать, что цель проекта - смоделировать систему с подходящим уровнем детализации и подходящим уровнем абстракции. Для больших систем найти компромисс между простотой и общностью далеко не простая задача.

12.2.2 Иерархии классов

Рассмотрим моделирование транспортного потока в городе, цель которого достаточно точно определить время, требующееся, чтобы аварийные движущиеся средства достигли пункта назначения. Очевидно, нам надо иметь представления легковых и грузовых машин, машин скорой помощи, всевозможных пожарных и полицейских машин, автобусов и т.п. Поскольку всякое понятие реального мира не существует изолированно, а соединено  многочисленными связями с другими понятиями, возникает такое отношение как наследование. Не разобравшись в понятиях и их взаимных связях,  мы не в состоянии постичь никакое отдельное понятие. Также и модель, если не отражает отношения между понятиями, не может адекватно представлять сами понятия. Итак, в нашей программе нужны классы для представления понятий, но этого недостаточно. Нам нужны способы представления отношений между классами. Наследование является мощным способом прямого представления иерархических отношений. В нашем примере, мы, по всей видимости, сочли бы аварийные средства специальными движущимися средствами и, помимо этого, выделили бы средства, представленные легковыми и грузовыми машинами. Тогда иерархия классов приобрела бы такой вид: движущееся средство
 легковая машина  аварийное средство грузовая машина полицейская машина машина скорой помощи пожарная машина машина с выдвижной лестницей Здесь класс Emergency представляет всю информацию, необходимую для моделирования аварийных движущихся средств, например: аварийная машина может нарушать некоторые правила движения, она имеет приоритет на перекрестках, находится под контролем диспетчера и т.д. На С++ это можно задать так:

    class Vehicle { /*...*/ };
    class Emergency { /*   */ };
    class Car : public Vehicle { /*...*/ };
    class Truck : public Vehicle { /*...*/ };
    class Police_car : public Car , public Emergency {
        //...
    };
    class Ambulance : public Car , public Emergency {
        //...
    };
    class Fire_engine : public Truck , Emergency {
        //...
    };
    class Hook_and_ladder : public Fire_engine {
        //...
    }; 

Наследование - это отношение самого высокого порядка, которое прямо представляется в С++ и используется преимущественно на ранних этапах проектирования. Часто возникает проблема выбора: использовать наследование для представления отношения или предпочесть ему принадлежность. Рассмотрим другое определение понятия аварийного средства: движущееся средство считается аварийным, если оно несет соответствующий световой сигнал. Это позволит упростить иерархию классов, заменив класс Emergency на член класса
Vehicle:

• движущееся средство (Vehicle {eptr})
•  легковая машина (Car) грузовая машина (Truck)
• полицейская машина (Police_car) машина скорой помощи (Ambulance)
•   пожарная машина (Fire_engine)
•   машина с выдвижной лестницей (Hook_and_ladder)

Теперь класс Emergency используется просто как член в тех классах, которые представляют аварийные движущиеся средства:

     class Emergency { /*...*/ };
     class Vehicle { public: Emergency* eptr;  /*...*/ };
     class Car : public Vehicle { /*...*/ };
     class Truck : public Vehicle { /*...*/ };
     class Police_car : public Car { /*...*/ };
     class Ambulance : public Car { /*...*/ };
     class Fire_engine : public Truck { /*...*/ };
     class Hook_and_ladder : public Fire_engine { /*...*/ }; 

Здесь движущееся средство считается аварийным, если Vehicle::eptr не равно нулю. "Простые" легковые и грузовые машины инициализируются Vehicle::eptr равным нулю, а для других Vehicle::eptr должно быть установлено в ненулевое значение, например:

     Car::Car()     // конструктор Car
     {
        eptr = 0;
     }
     Police_car::Police_car()   // конструктор Police_car
     {
        eptr = new Emergency;
     }

Такие определения упрощают преобразование аварийного средства в обычное и наоборот:

     void f(Vehicle* p)
     {
        delete p->eptr;
        p->eptr = 0;   // больше нет аварийного движущегося средства

        //...

        p->eptr = new Emergency;   // оно появилось снова
     }

Так какой же вариант иерархии классов лучше? В общем случае ответ такой: Лучшей является программа, которая наиболее непосредственно отражает реальный мир". Иными словами, при выборе модели мы должны стремиться к большей ее"реальности", но с учетом неизбежных ограничений, накладываемых требованиями простоты и эффективности. Поэтому, несмотря на простоту преобразования обычного движущегося средства в аварийное, второе решение представляется непрактичным. Пожарные машины и машины скорой помощи - это движущиеся средства специального назначения со специально подготовленным персоналом, они действуют под управлением команд диспетчера, требующих специального оборудования для связи. Такое положение означает, что принадлежность к аварийным движущимся средствам - это базовое понятие, которое для улучшения контроля типов и применения различных программных средств должно быть прямо представлено в программе. Если бы мы моделировали ситуацию, в которой назначение движущихся средств не столь определенно, скажем, ситуацию, в которой частный транспорт периодически используется для доставки специального персонала к месту происшествия, а связь обеспечивается с помощью портативных приемников, тогда мог бы оказаться подходящим и другой способ моделирования системы.

Для тех, кто считает пример моделирования движения транспорта экзотичным, имеет смысл сказать, что в процессе проектирования почти постоянно возникает подобный выбор между наследованием и принадлежностью. Аналогичный пример есть в $$12.2.5, где описывается свиток (scrollbar) - прокручивание информации в окне.

12.2.3 Зависимости в рамках иерархии классов

Естественно, производный класс зависит от своих базовых классов. Гораздо реже учитывают, что обратное также может быть справедливоЬ. Ь Эту мысль можно выразить таким способом: "Сумасшествие наследуется, вы можете получить его от своих детей." Если класс содержит виртуальную функцию, производные классы могут по своему усмотрению решать, реализовывать ли часть операций этой функции каждый раз, когда она переопределяется в производном классе. Если член базового класса сам вызывает одну из виртуальных функций производного класса, тогда реализация базового класса зависит от реализаций его производных классов. Точно так же, если класс использует защищенный член, его реализация будет зависеть от производных классов. Рассмотрим определения:

     class B {
         //...
     protected:
         int a;
     public:
         virtual int f();
         int g() { int x = f(); return x-a; }
     }; 

Каков результат работы g()? Ответ существенно зависит от определения f() в некотором производном классе. Ниже приводится вариант, при котором g() будет возвращать 1:

      class D1 : public B {
          int f() { return a+1; }
      }; а при нижеследующем определении g() напечатает "Hello, World" и вернет 0:

      class D1 : public {
          int f() { cout<<"Hello, World\n"; return a; }
      }; 

Этот пример демонстрирует один из важнейших моментов, связанных с виртуальными функциями. Хотя вы можете сказать, что это глупость, и программист никогда не напишет ничего подобного. Дело здесь в том, что виртуальная функция является частью интерфейса с базовым классом, и что этот класс будет, по всей видимости, использоваться без информации о его производных классах. Следовательно, можно так описать поведение объекта базового класса, чтобы в дальнейшем писать программы, ничего не зная о его производных классах. Всякий класс, который переопределяет производную функцию, должен реализовать вариант этой функции. Например, виртуальная функция rotate() из класса Shape вращает геометрическую фигуру, а функции rotate() для производных классов, таких, как Circle и Triangle, должны вращать объекты соответствующих типов, иначе будет нарушено основное положение о классе Shape. Но о поведении класса B или его производных классов D1 и D2 не сформулировано никаких положений, поэтому приведенный пример и кажется неразумным. При построении класса главное внимание следует уделять описанию ожидаемых действий виртуальных функций.

Следует ли считать нормальной зависимость от неизвестных возможно еще неопределенных) производных классов? Ответ, естественно, зависит от целей программиста. Если цель состоит в том, чтобы изолировать класс от всяких внешних влияний и, тем самым, доказать, что он ведет себя определенным образом, то лучше избегать виртуальных функций и защищенных членов. Если цель состоит в том, чтобы разработать структуру, в которую последующие программисты или вы сами через неделю) смогут встраивать свои программы, то именно виртуальные функции и предлагают элегантный способ решения, а защищенные члены могут быть полезны при его реализации.

В качестве примера рассмотрим простой шаблон типа, определяющий буфер:

      template<class T> class buffer {
         // ...
         void put(T);
         T get();
      }; 

Если реакция на переполнение и обращение к пустому буферу, "запаяна" в сам класс, его применение будет ограничено. Но если функции put()
и get() обращаются к виртуальным функциям overflow() и underflow()
соответственно, то пользователь может, удовлетворяя своим нуждам, создать буфера различных типов:

     template<class T> class buffer {
        //...
        virtual int overflow(T);
        virtual int underflow();
        void put(T);   // вызвать overflow(T), когда буфер полон
        T get();   // вызвать underflow(T), когда буфер пуст
     };

     template<class T> class circular_buffer : public buffer<T> {
         //...
         int overflow(T);  // перейти на начало буфера, если он полон
         int underflow();
     };

     template<class T> class expanding_buffer : public buffer<T> {
         //...
         int overflow(T);   // увеличить размер буфера, если он полон
         int underflow();
     }; 

Этот метод использовался в библиотеках потокового ввода-вывода  ($$10.5.3).

12.2.4 Отношения принадлежности

Если используется отношение принадлежности, то существует два основных способа представления объекта класса X:

[1] Описать член типа X.
[2] Описать член типа X* или X&.

Если значение указателя не будет меняться и вопросы эффективности не волнуют, эти способы эквивалентны:

     class X {
         //...
     public:
         X(int);
         //...
     };

     class C {
          X a;
          X* p;
     public:
          C(int i, int j) : a(i), p(new X(j)) { }
          ~C()  { delete p; }
     }; 

В таких ситуациях предпочтительнее непосредственное членство объекта, как X::a в примере выше, потому что оно дает экономию времени, памяти и количества вводимых символов. Обратитесь также к $$12.4 и $$13.9.

Способ, использующий указатель, следует применять в тех случаях, когда приходится перестраивать указатель на объект-элемент" в течении жизни "объекта-владельца". Например:

     class C2 {
         X* p;
     public:
         C(int i) : p(new X(i))  { }
         ~C() { delete p; }

         X* change(X* q)
         {
            X* t = p;
            p = q;
            return t;
         }
     }; 

Член типа указатель может также использоваться, чтобы дать возможность передавать "объект-элемент" в качестве параметра:

     class C3 {
       X* p;
     public:
        C(X* q) : p(q) {  }
        // ...
     }

Разрешая объектам содержать указатели на другие объекты, мы создаем то, что обычно называется "иерархия объектов". Это альтернативный и вспомогательный способ структурирования по отношению к иерархии классов. Как было показано на примере аварийного движущегося средства в $$12.2.2, часто это довольно тонкий вопрос проектирования: представлять ли свойство класса как еще один базовый класс или как член класса. Потребность в переопределении следует считать указанием, что первый вариант лучше. Но если надо иметь возможность представлять некоторое свойство с помощью различных типов, то лучше остановиться на втором варианте. Например:

     class XX : public X { /*...*/ };

     class XXX : public X { /*...*/ };

     void f()
     {
        C3* p1 = new C3(new X);     // C3 "содержит"  X
        C3* p2 = new C3(new XX);    // C3 "содержит"  XX
        C3* p3 = new C3(new XXX);   // C3 "содержит"  XXX
        //...
     }

Приведенные определения нельзя смоделировать ни с помощью производного класса C3 от X, ни с помощью C3, имеющего член типа X, поскольку необходимо указывать точный тип члена. Это важно для классов с виртуальными функциями, таких, например,как класс Shape ($$1.1.2.5), и для класса абстрактного множества ($$13.3).

Заметим, что ссылки можно применять для упрощения классов, использующих члены-указатели, если в течение жизни объекта-владельца ссылка настроена только на один объект, например:

      class C4 {
          X&  r;
      public:
          C(X& q) : r(q) { }
          // ...
       };

12.2.5 Принадлежность и наследование

Учитывая сложность важность отношений наследования, нет ничего удивительного в том, что часто их неправильно понимают и используют сверх меры. Если класс D описан как общий производный от класса B, то часто говорят, что D есть B:

     class B { /* ... */ ;
     class D : public B  /* ... */ }; // D сорта B

Иначе это можно сформулировать так: наследование - это отношение "есть", или, более точно для классов D и B, наследование - это отношение D сорта B. В отличие от этого, если класс D содержит в качестве члена другой класс B, то говорят, что D "имеет" B:

     class D {  // D имеет B
       // ...
     public:
        B b;
       // ...
     }; 

Иными словами, принадлежность - это отношение "иметь" или для классов D и B просто: D содержит B.

Имея два класса B и D, как выбирать между наследованием и принадлежностью? Рассмотрим классы самолет и мотор.Новички обычно спрашивают: будет ли хорошим решением сделать класс самолет производным от класса мотор. Это плохое решение, поскольку самолет не "есть" мотор, самолет "имеет" мотор. Следует подойти к этому вопросу, рассмотрев, может ли самолет "иметь" два или больше моторов. Поскольку это представляется вполне возможным (даже если мы имеем дело с программой, в которой все самолеты будут с одним мотором), следует использовать принадлежность, а не наследование. Вопрос "Может ли он иметь два..?" оказывается удивительно полезным во многих сомнительных случаях. Как всегда, наше изложение затрагивает неуловимую сущность программирования. Если бы все классы было так же легко представить, как самолет и мотор, то было бы просто избежать и тривиальных ошибок типа той, когда самолет определяется как производное от класса мотор. Однако, такие ошибки достаточно часты, особенно у тех, кто считает наследование еще одним механизмом для сочетания конструкций языка программирования. Несмотря на удобство и лаконичность записи, которую предоставляет наследование, его надо использовать только для выражения тех отношений, которые четко определены в проекте. Рассмотрим определения:

     class B {
     public:
         virtual void f();
         void g();
     };

     class D1 {      // D1 содержит B
     public:
         B b;
         void f();   // не переопределяет b.f()
     };

     void h1(D1* pd)
     {
        B* pb = pd;  // ошибка: невозможно преобразование D1* в B*
        pb = &pd->b;
        pb->q();     // вызов B::q
        pd->q();     // ошибка: D1 не имеет член q()
        pd->b.q();
        pb->f();     // вызов B::f (здесь D1::f не переопределяет)
        pd->f();     // вызов D1::f
     }

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

     class D2 : public B {    // D2 есть B
     public:
         void f();            // переопределение B::f()
     };

     void h2(D2* pd)
     {
        B* pb = pd;  // нормально: D2* неявно преобразуется в B*
        pb->q();     // вызов B::q
        pd->q();     // вызов B::q
        pb->f();     // вызов виртуальной функции: обращение к D2::f
        pd->f();     // вызов D2::f
      }

Удобство записи, продемонстрированное в примере с классом D2, по сравнению с записью в примере с классом D1, является причиной, по которой таким наследованием злоупотребляют. Но следует помнить, что существует определенная плата за удобство записи в виде возросшей зависимости между B и D2 (см. $$12.2.3). В частности, легко забыть о неявном преобразовании D2 в B. Если только такие преобразования не относятся к семантике ваших классов, следует избегать описания производного класса в общей части. Если класс представляет определенное понятие, а наследование используется как отношение "есть", то такие преобразования обычно как раз то, что нужно.

Однако, бывают такие ситуации, когда желательно иметь наследование, но нельзя допускать преобразования. Рассмотрим задание класса cfield (controled field - управляемое поле), который, помимо всего прочего, дает возможность контролировать на стадии выполнения доступ к другому классу field. На первый взгляд кажется совершенно правильным определить класс cfield как производный от класса field:

       class cfield : public field {
          // ...
       }; 

Это выражает тот факт, что cfield, действительно, есть сорта field, упрощает запись функции, которая использует член части field класса cfield, и, что самое главное, позволяет в классе cfield переопределять виртуальные функции из field. Загвоздка здесь в том, что преобразование cfield* к field*, встречающееся в определении класса cfield, позволяет обойти любой контроль доступа к field:

     void q(cfield* p)
     {
         *p = "asdf";   // обращение к field контролируется
                        // функцией присваивания cfield:
                        // p->cfield::operator=("asdf")

         field* q = p;  // неявное преобразование cfield* в field*
         *q = "asdf";   // приехали! контроль обойден
     }

Можно было бы определить класс cfield так, чтобы field был его членом, но тогда cfield не может переопределять виртуальные функции field. Лучшим решением здесь будет использование наследования со спецификацией private (частное наследование):

     class cfield : private field { /* ... */ }

С позиции проектирования, если не учитывать (иногда важные) вопросы переопределения, частное наследование эквивалентно принадлежности. В этом случае применяется метод, при котором класс определяется в общей части как производный от абстрактного базового класса заданием его интерфейса, а также определяется с помощью частного наследования от конкретного класса, задающего реализацию ($$13.3). Поскольку наследование, используемое как частное, является спецификой реализации, и оно не отражается в типе производного класса, то его иногда называют "наследованием по реализации", и оно является контрастом для наследования в общей части, когда наследуется интерфейс базового класса и допустимы неявные преобразования к базовому типу. Последнее наследование иногда называют определением подтипа или "интерфейсным наследованием".

Для дальнейшего обсуждения возможности выбора наследования или принадлежности рассмотрим, как представить в диалоговой графической системе свиток (область для прокручивания в ней информации), и как привязать свиток к окну на экране. Потребуются свитки двух видов: горизонтальные и вертикальные. Это можно представить с помощью двух типов horizontal_scrollbar и
vertical_scrollbar или с помощью одного типа scrollbar, который имеет аргумент, определяющий, является расположение вертикальным или горизонтальным. Первое решение предполагает, что есть еще третий тип, задающий просто свиток - scrollbar, и этот тип является базовым классом для двух определенных свитков. Второе решение предполагает дополнительный аргумент у типа scrollbar и наличие значений, задающих вид свитка. Например, так:

      enum orientation { horizontal, vertical }; 

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

Для добавления управляющей кнопки к программе, использующей иерархию из трех свитков, требуется добавить еще один класс, но не нужно менять программу, работающую со старыми свитками: свиток горизонтальный_свиток вертикальный_свиток управляющая_кнопка Это положительная сторона "иерархического решения".

Задание ориентации свитка в качестве параметра приводит к заданию полей типа в объектах свитка и использованию переключателей в теле функций-членов свитка. Иными словами, перед нами обычная дилемма: выразить данный аспект структуры системы с помощью определений или реализовать его в операторной части программы. Первое решение увеличивает объем статических проверок и объем информации, над которой могут работать разные вспомогательные средства. Второе решение откладывает проверки на стадию выполнения и разрешает менять тела отдельных функций, не изменяя общую структуру системы, какой она представляется с точки зрения статического контроля или вспомогательных средств. В большинстве случаев, предпочтительнее первое решение.

Положительной стороной решения с единым типом свитка является то, что легко передавать информацию о виде нужного нам свитка другой функции:

     void helper(orientation oo)
     {
        //...
        p = new scrollbar(oo);
        //...
     }

     void me()
     {
         helper(horizontal);
     }

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

Теперь рассмотрим как привязать свиток к окну. Если считать window_with_scrollbar (окно_со_свитком) как нечто, что является window и scrollbar, мы получим подобное:

     class window_with_scrollbar
     : public window, public scrollbar {
         // ...
     }; 

Это позволяет любому объекту типа window_with_scrollbar выступать и как window, и как scrollbar, но от нас требуется решение использовать только единственный тип scrollbar.

Если, с другой стороны, считать window_with_scrollbar объектом типа window, который имеет scrollbar, мы получим такое определение:

    class window_with_scrollbar : public window {
      // ...
      scrollbar* sb;
    public:
        window_with_scrollbar(scrollbar* p, /* ... */)
        : window(/* ... */), sb(p)
        {
           // ...
        }
      // ...
     }; 

Здесь мы можем использовать решение со свитками трех типов. Передача самого свитка в качестве параметра позволяет окну (window) не запоминать тип его свитка. Если потребуется, чтобы объект типа
window_with_scrollbar действовал как scrollbar, можно добавить операцию преобразования:

    window_with_scrollbar :: operator scrollbar&()
    {
       return *sb;
    }

12.2.6 Отношения использования

Для составления и понимания проекта часто необходимо знать, какие классы и каким способом использует данный класс. Такие отношения классов на С++ выражаются неявно. Класс может использовать только те имена, которые где-то определены, но нет такой части в программе на С++, которая содержала бы список всех используемых имен. Для получения такого списка необходимы вспомогательные средства (или, при их отсутствии, внимательное чтение). Можно следующим образом классифицировать те способы, с помощью которых класс X может использовать класс Y:

  - X использует имя Y
  - X использует Y
      - X вызывает функцию-член Y
      - X читает член Y
      - X пишет в член Y
  - X создает Y
      - X размещает auto или static переменную из Y
      - X создает Y с помощью new
      - X использует размер Y

Мы отнесли использование размера объекта к его созданию, поскольку для этого требуется знание полного определения класса. С другой стороны, мы выделили в отдельное отношение использование имени Y, поскольку, указывая его в описании Y* или в описании внешней функции, мы вовсе не нуждаемся в доступе к определению Y:

      class Y;  // Y - имя класса
      Y* p;
      extern Y f(const Y&); 

Мы отделили создание Y с помощью new от случая описания переменной, поскольку возможна такая реализация С++, при которой для создания Y с помощью new необязательно знать размер Y. Это может быть существенно для ограничения всех зависимостей в проекте и сведения к минимуму перетрансляции после внесения изменений.

Язык С++ не требует, чтобы создатель классов точно определял, какие классы и как он будет использовать. Одна из причин этого заключена в том, что самые важные классы зависят от столь большого количества других классов, что для придания лучшего вида программе нужна сокращенная форма записи списка используемых классов, например, с помощью команды #include. Другая причина в том, что классификация этих зависимостей и, в частности, обЪединение некоторых зависимостей не является обязанностью языка программирования. Наоборот, цели разработчика, программиста или вспомогательного средства определяют то, как именно следует рассматривать отношения использования. Наконец, то, какие зависимости представляют больший интерес, может зависеть от специфики реализации языка.

12.2.7 Отношения внутри класса

До сих пор мы обсуждали только классы, и хотя операции упоминались, если не считать обсуждения шагов процесса развития программного обеспечения ($$11.3.3.2), то они были на втором плане, объекты же практически вообще не упоминались. Понять это просто: в С++ класс, а не функция или объект, является основным понятием организации системы.

Класс может скрывать в себе всякую специфику реализации, наравне с "грязными" приемами программирования, а иногда он вынужден это делать. В то же время объекты большинства классов сами образуют регулярную структуру и используются такими способами, что их достаточно просто описать.  Объект класса может  быть совокупностью других вложенных объектов (их часто называют членами), многие из которых, в свою очередь, являются указателями или ссылками на другие объекты. Поэтому отдельный объект можно рассматривать как корень дерева объектов, а все входящие в него объекты как "иерархию объектов", которая дополняет иерархию классов, рассмотренную в $$12.2.4. Рассмотрим в качестве примера класс строк из $$7.6:

     class String {
         int sz;
         char* p;
     public:
         String(const char* q);
         ~String();
         //...
     }; 

Объект типа String можно изобразить так:

12.2.7.1 Инварианты

Значение членов или объектов, доступных с помощью членов класса, называется состоянием объекта (или просто значением объекта). Главное при построении класса - это: привести объект в полностью определенное состояние (инициализация), сохранять полностью определенное состояние обЪекта в процессе выполнения над ним различных операций, и в конце работы уничтожить объект без всяких последствий. Свойство, которое делает состояние объекта полностью определенным, называется инвариантом.

Поэтому назначение инициализации - задать конкретные значения, при которых выполняется инвариант объекта. Для каждой операции класса предполагается, что инвариант должен иметь место перед выполнением операции и должен сохраниться после операции. В конце работы деструктор нарушает инвариант, уничтожая объект. Например, конструктор String::String(const char*) гарантирует, что p указывает на массив из, по крайней мере, sz элементов, причем sz имеет осмысленное значение и v[sz-1]==0. Любая строковая операция не должна нарушать это утверждение.

При проектировании класса требуется большое искусство, чтобы сделать реализацию класса достаточно простой и допускающей наличие полезных инвариантов, которые несложно задать. Легко требовать, чтобы класс имел инвариант, труднее предложить полезный инвариант, который понятен и не накладывает жестких ограничений на действия разработчика класса или на эффективность реализации. Здесь "инвариант" понимается как программный фрагмент, выполнив который, можно проверить состояние объекта. Вполне возможно дать более строгое и даже математическое определение инварианта, и в некоторых ситуациях оно может оказаться более подходящим. Здесь же под инвариантом понимается практическая, а значит, обычно экономная, но неполная проверка состояния объекта.

Понятие инварианта появилось в работах Флойда, Наура и Хора, посвященных пред- и пост-условиям, оно встречается во всех важных статьях по абстрактным типам данных и верификации программ за последние 20 лет. Оно же является основным предметом отладки в C++.

Обычно, в течение работы функции-члена инвариант не сохраняется. Поэтому функции, которые могут вызываться в те моменты, когда инвариант не действует, не должны входить в общий интерфейс класса. Такие функции должны быть частными или защищенными.

Как можно выразить инвариант в программе на С++? Простое решение - определить функцию, проверяющую инвариант, и вставить вызовы этой функции в общие операции. Например:

     class String {
         int sz;
         int* p;
     public:
         class Range {};
         class Invariant {};

         void check();

         String(const char* q);
         ~String();
         char& operator[](int i);
         int size() { return sz; }
         //...
     };

     void String::check()
     {
         if (p==0 || sz<0 || TOO_LARGE<=sz || p[sz-1])
            throw Invariant;
     }

     char& String::operator[](int i)
     {
         check();                        // проверка на входе
         if (i<0 || i<sz) throw Range;   // действует
         check();                        // проверка на выходе
         return v[i];
     }

Этот вариант прекрасно работает и не осложняет жизнь программиста. Но для такого простого класса как String проверка инварианта будет занимать большую часть времени счета. Поэтому программисты обычно выполняют проверку инварианта только при отладке:

     inline void String::check()
     {
         if (!NDEBUG)
             if (p==0 || sz<0 || TOO_LARGE<=sz || p[sz])
                 throw Invariant;
     }

Мы выбрали имя NDEBUG, поскольку это макроопределение, которое используется для аналогичных целей в стандартном макроопределении С assert(). Традиционно NDEBUG устанавливается с целью указать, что отладки нет. Указав, что check() является подстановкой, мы гарантировали, что никакая программа не будет создана, пока константа
NDEBUG не будет установлена в значение, обозначающее отладку. С помощью шаблона типа Assert() можно задать менее регулярные утверждения, например:

     template<class T, class X> inline void Assert(T expr,X x)
     {
         if (!NDEBUG)
             if (!expr) throw x;
     }

вызовет особую ситуацию x, если expr ложно, и мы не отключили проверку с помощью NDEBUG. Использовать Assert() можно так:

     class Bad_f_arg { };

     void f(String& s, int i)
     {
         Assert(0<=i && i<s.size(),Bad_f_arg());
         //...
     }

Шаблон типа Assert() подражает макрокоманде assert() языка С. Если i не находится в требуемом диапазоне, возникает особая ситуация Bad_f_arg.

С помощью отдельной константы или константы из класса проверить подобные утверждения или инварианты - пустяковое дело. Если же необходимо проверить инварианты с помощью объекта, можно определить производный класс, в котором проверяются операциями из класса, где нет проверки, см. упр.8 в $$13.11.

Для классов с более сложными операциями расходы на проверки могут быть значительны, поэтому проверки можно оставить только для "поимки" трудно обнаруживаемых ошибок. Обычно полезно оставлять по крайней мере несколько проверок даже в очень хорошо отлаженной программе. При всех условиях сам факт определения инвариантов и использования их при отладке дает неоценимую помощь для получения правильной программы и, что более важно, делает понятия, представленные классами, более регулярными и строго определенными. Дело в том, что когда вы создаете инварианты, то рассматриваете класс с другой точки зрения и вносите определенную избыточность в программу. То и другое увеличивает вероятность обнаружения ошибок, противоречий и недосмотров. Мы указали в $$11.3.3.5, что две самые общие формы преобразования иерархии классов состоят в разбиении класса на два и в выделении общей части двух классов в базовый класс. В обоих случаях хорошо продуманный инвариант может подсказать возможность такого преобразования. Если, сравнивая инвариант с программами операций, можно обнаружить, что большинство проверок инварианта излишни, то значит класс созрел для разбиения. В этом случае подмножество операций имеет доступ только к подмножеству состояний объекта. Обратно, классы созрели для слияния, если у них сходные инварианты, даже при некотором различии в их реализации.

12.2.7.2 Инкапсуляция

Отметим, что в С++ класс, а не отдельный объект, является той единицей, которая должна быть инкапсулирована (заключена в оболочку). Например:

     class list {
         list* next;
     public:
         int on(list*);
     };

     int list::on(list* p)
     {
         list* q = this;
         for(;;) {
             if (p == q) return 1;
             if (q == 0) return 0;
             q = q->next;
         }
     }

Здесь обращение к частному указателю list::next допустимо, поскольку
list::on() имеет доступ ко всякому объекту класса list, на который у него есть ссылка. Если это неудобно, ситуацию можно упростить, отказавшись от возможности доступа через функцию-член к представлениям других объектов, например:

     int list::on(list* p)
     {
         if (p == this) return  1;
         if (p == 0) return 0;
         return next->on(p);
     }

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

12.2.8 Программируемые отношения

Конкретный язык программирования не может прямо поддерживать любое понятие любого метода проектирования. Если язык программирования не способен прямо представить понятие проектирования, следует установить удобное отображение конструкций, используемых в проекте, на языковые конструкции. Например, метод проектирования может использовать понятие делегирования, означающее, что всякая операция, которая не определена для класса A, должна выполняться в нем с помощью указателя p на соответствующий член класса B, в котором она определена. На С++ нельзя выразить это прямо. Однако, реализация этого понятия настолько в духе С++, что легко представить программу реализации:

     class A {
         B* p;
         //...
         void f();
         void ff();
     };

     class B {
         //...
         void f();
         void g();
         void h();
      }; 

Тот факт, что В делегирует A с помощью указателя A::p, выражается в следующей записи:

     class A {
         B* p;      // делегирование с помощью p
         //...
         void f();
         void ff();
         void g() { p->g(); }  // делегирование q()
         void h() { p->h(); }  // делегирование h()
      }; 

Для программиста совершенно очевидно, что здесь происходит, однако здесь явно нарушается принцип взаимнооднозначного соответствия. Такие программируемые" отношения трудно выразить на языках программирования, и поэтому к ним трудно применять различные вспомогательные средства. Например, такое средство может не отличить "делегирование" от B к A с помощью A::p от любого другого использования B*.

Все-таки следует всюду, где это возможно, добиваться взаимнооднозначного соответствия между понятиями проекта и понятиями языка программирования. Оно дает определенную простоту и гарантирует, что проект адекватно отображается в программе, что упрощает работу программиста и вспомогательных средств. Операции преобразований типа являются механизмом, с помощью которого можно представить в языке класс программируемых отношений, а именно: операция преобразования X::operator Y() гарантирует, что всюду, где допустимо использование Y, можно применять и X. Такое же отношение задает конструктор Y::Y(X). Отметим, что операция преобразования типа (как и конструктор) скорее создает новый объект, чем изменяет тип существующего объекта. Задать операцию преобразования к функции Y - означает просто потребовать неявного применения функции, возвращающей Y. Поскольку неявные применения операций преобразования типа и операций, определяемых конструкторами, могут привести к неприятностям, полезно проанализировать их в отдельности еще в проекте.

Важно убедиться, что граф применений операций преобразования типа не содержит циклов. Если они есть, возникает двусмысленная ситуация, при которой типы, участвующие в циклах, становятся несовместимыми в комбинации. Например:

     class Big_int {
         //...
         friend Big_int operator+(Big_int,Big_int);
         //...
         operator Rational();
         //...
     };

     class Rational {
         //...
         friend Rational operator+(Rational,Rational);
         //...
         operator Big_int();
     }; 

Типы Rational и Big_int не так гладко взаимодействуют, как можно было бы подумать:

     void f(Rational r, Big_int i)
     {
         //...
         g(r+i);   // ошибка, неоднозначность:
                   //        operator+(r,Rational(i)) или
                   //        operator+(Big_int(r),i)
         g(r,Rational(i));  // явное разрешение неопределенности
         g(Big_int(r),i);   // еще одно
     }

Можно было бы избежать таких "взаимных" преобразований, сделав некоторые из них явными. Например, преобразование Big_int к типу Rational можно было бы задать явно с помощью функции make_Rational()
вместо операции преобразования, тогда сложение в приведенном примере разрешалось бы как g(BIg_int(r),i). Если нельзя избежать взаимных" операций преобразования типов, то нужно преодолевать возникающие столкновения или с помощью явных преобразований (как было показано), или с помощью определения нескольких различных версий бинарной операции (в нашем случае +).

12.3 Компоненты

В языке С++ нет конструкций, которые могут выразить прямо в программе понятие компонента, т.е. множества связанных классов. Основная причина этого в том, что множество классов (возможно с соответствующими глобальными функциями и т.п.) может соединяться в компонент по самым разным признакам. Отсутствие явного представления понятия в языке затрудняет проведение границы между информацией (имена), используемой внутри компонента, и информацией (имена), передаваемой из компонента пользователям. В идеале, компонент определяется множеством интерфейсов, используемых для его реализации, плюс множеством интерфейсов, представляемых пользователем, а все прочее считается "спецификой реализации" и должно быть скрыто от остальных частей системы. Таково может быть в действительности представление о компоненте у разработчика. Программист должен смириться с тем фактом, что С++ не дает общего понятия пространства имен компонента, так что его приходится "моделировать" с помощью понятий классов и единиц трансляции, т.е. тех средств, которые есть в С++ для ограничения области действия нелокальных имен.

Рассмотрим два класса, которые должны совместно использовать функцию f() и переменную v. Проще всего описать f и v как глобальные имена. Однако, всякий опытный программист знает, что такое "засорение" пространства имен может привести в конце концов к неприятностям: кто-то может ненарочно использовать имена f или v не по назначению или нарочно обратиться  к f или v, прямо используя "специфику реализации" и обойдя тем самым явный интерфейс компонента. Здесь возможны три решения:

  [1] Дать "необычные" имена объектам и функциям, которые не рассчитаны на пользователя.
  [2] Объекты или функции, не предназначенные для пользователя, описать в одном из файлов программы как статические (static).
  [3] Поместить объекты и функции, не предназначенные для пользователя, в класс, определение которого закрыто для пользователей.

Первое решение примитивно и достаточно неудобно для создателя программы, но оно действует:

     // не используйте специфику реализации compX,
     // если только вы не разработчик compX:
     extern void compX_f(T2*, const char*);
     extern T3 compX_v;
     // ... 

Такие имена как compX_f и compX_v вряд ли могут привести к коллизии, а на тот довод, что пользователь может быть злоумышленником и использовать эти имена прямо, можно ответить, что пользователь в любом случае может оказаться злоумышленником, и что языковые механизмы защиты предохраняют от несчастного случая, а не от злого умысла. Преимущество этого решения в том, что оно применимо всегда и хорошо известно. В то же время оно некрасиво, ненадежно и усложняет ввод текста.

Второе решение более надежно, но менее универсально:

     // специфика реализации compX:
     static void compX_f(T2* a1, const char *a2) { /* ... */ }
     static T3 compX_v;
     // ... 

Трудно гарантировать, что информация, используемая в классах одного компонента, будет доступна только в одной единице трансляции, поскольку операции, работающие с этой информацией, должны быть доступны везде. Это решение может к тому же привести к громадным единицам трансляции, а в некоторых отладчиках для С++
не организован доступ к именам статических функций и переменных. В то же время это решение надежно и часто оптимально для небольших компонентов. Третье решение можно рассматривать как формализацию и обобщение первых двух:

      class compX_details {  // специфика реализации compX
      public:
         static void f(T2*, const char*);
         static T3 v;
         // ...
     }; 

Описание compX_details будет использовать только создатель класса, остальные не должны включать его в свои программы.

В компоненте конечно может быть много классов, не предназначенных для общего пользования. Если их имена тоже рассчитаны только на локальное использование, то их также можно "спрятать" внутри классов, содержащих специфику реализации:

     class compX_details { // специфика реализации compX.
     public:
        // ...
        class widget {
           // ...
       };
       // ...
     }; 

Укажем, что вложенность создает барьер для использования widget в других частях программы. Обычно классы, представляющие ясные понятия, считаются первыми кандидатами на повторное использование, и, значит составляют часть интерфейса компонента, а не деталь реализации. Другими словами, хотя для сохранения надлежащего уровня абстракции вложенные объекты, используемые для представления некоторого объекта класса, лучше считать скрытыми деталями реализации, классы, определяющие такие вложенные объекты, лучше не делать скрытыми, если они имеют достаточную общность. Так, в следующем примере упрятывание, пожалуй, излишне:

     class Car {
        class Wheel {
          // ...
        };
        Wheel flw, frw, rlw, rrw;
        // ...
     }; 

Во многих ситуациях для поддержания уровня абстракции понятия машины (Car) следует упрятывать реальные колеса (класс Wheel), ведь когда вы работаете с машиной, вы не можете независимо от нее использовать колеса. С другой стороны, сам класс Wheel является вполне подходящим для широкого использования, поэтому лучше вынести его определение из класса Car:

      class Wheel {
        // ...
      };
      class Car {
         Wheel flw, frw, rlw, rrw;
         // ...
      }; 

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

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

Другим средством построения компонента и представления его пользователю служит иерархия. Тогда базовый класс используется как хранилище общих данных и функций. Таким способом устраняется проблема, связанная с глобальными данными и функциями, предназначенными для реализации общих запросов классов данного компонента. С другой стороны, при таком решении классы компонента становятся слишком связанными друг с другом, а пользователь попадает в зависимость от всех базовых классов тех компонентов, которые ему действительно нужны. Здесь также проявляется тенденция к тому, что члены, представляющие "полезные" функции и данные "всплывают"  к базовому классу, так что при слишком большой иерархии классов проблемы с глобальными данными и функциями проявятся уже в рамках этой иерархии. Вероятнее всего, это произойдет для иерархии с одним корнем, а для борьбы с этим явлением можно применять виртуальные базовые классы ($$6.5.4). Иногда лучше выбрать иерархию для представления компонента, а иногда нет. Как всегда сделать выбор предстоит разработчику.

12.4 Интерфейсы и реализации

Идеальный интерфейс должен

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

Отметив необходимость согласованности для всех классов, которые образуют интерфейс компонента с остальным миром, мы можем упростить вопрос интерфейса, рассмотрев только один класс, например:

    class X {  // пример плохого определения интерфейса
      Y a;
      Z b;
    public:
      void f(const char* ...);
      void g(int[],int);
      void set_a(Y&);
      Y& get_a();
    }; 

В этом интерфейсе содержится ряд потенциальных проблем:

   -Типы Y и Z  используются так, что определения Y и Z должны быть известны во время трансляции.
   - У функции X::f может быть произвольное число параметров неизвестного типа (возможно, они каким-то образом контролируются
     "строкой формата", которая передается в качестве первого параметра).
   - Функция X::g имеет параметр типа int[]. Возможно это нормально, но обычно это свидетельствует о том, что определение слишком низкого уровня абстракции. Массив целых не является достаточным определением, так как неизвестно из скольких он может состоять элементов.
   - Функции set_a() и get_a(), по всей видимости, раскрывают представление объектов класса X, разрешая прямой доступ к X::a.

Здесь функции-члены образуют интерфейс на слишком низком уровне абстракции. Как правило классы с интерфейсом такого уровня относятся к специфике реализации большого компонента, если они вообще могут к чему-нибудь относиться. В идеале параметр функции из интерфейса должен сопровождаться такой информацией, которой достаточно для его понимания. Можно сформулировать такое правило: надо уметь передавать запросы на обслуживание удаленному серверу по узкому каналу.

Язык С++ раскрывает представление класса как часть интерфейса. Это представление может быть скрытым (с помощью private или protected), но обязательно доступным транслятору, чтобы он мог разместить автоматические (локальные) переменные, сделать подстановку тела функции и т.д. Отрицательным следствием этого является то, что использование типов классов в представлении класса может привести к возникновению нежелательных зависимостей. Приведет ли использование членов типа Y и Z к проблемам, зависит от того, каковы в действительности типы Y и Z. Если это достаточно простые типы, наподобие complex или String, то их использование будет вполне допустимым в большинстве случаев. Такие типы можно считать устойчивыми, и необходимость включать определения их классов будет вполне допустимой нагрузкой для транслятора. Если же Y и Z сами являются классами интерфейса большого компонента (например, типа графической системы или системы обеспечения банковских счетов), то прямую зависимость от них можно считать неразумной. В таких случаях  предпочтительнее использовать член, являющийся указателем или ссылкой:

      class X {
        Y* a;
        Z& b;
        // ...
      }; 

При этом способе определение X отделяется от определений Y и Z, т.е. теперь определение X зависит только от имен Y и Z. Реализация X, конечно, будет по-прежнему зависеть от определений Y и Z, но это уже не будет оказывать неблагоприятного влияния на пользователей X.

Вышесказанное иллюстрирует важное утверждение: У интерфейса, скрывающего значительный объем информации (что и должен делать полезный интерфейс), должно быть существенно меньше зависимостей, чем у реализации, которая их скрывает. Например, определение класса X можно транслировать без доступа к определениям Y и Z. Однако, в определениях функций-членов класса X, которые работают со ссылками на объекты Y и Z, доступ к определениям Y и Z необходим. При анализе зависимостей следует рассматривать раздельно зависимости в интерфейсе и в реализации. В идеале для обоих видов зависимостей граф зависимостей системы должен быть направленным нецикличным графом, что облегчает понимание и тестирование системы. Однако, эта цель более важна и чаще достижима для реализаций, чем для интерфейсов.

Отметим, что класс определяет три интерфейса:

    class X {
    private:
      // доступно только для членов и друзей
    protected:
      // доступно только для членов и друзей, а также
      // для членов и друзей производных классов
    public:
      // общедоступно
    }; 

Члены должны образовывать самый ограниченный из возможных интерфейсов. Иными словами, член должен быть описан как private, если нет причин для более широкого доступа к нему; если же таковые есть, то член должен быть описан как protected, если нет дополнительных причин задать его как public. В большинстве случаев плохо задавать все данные, представляемые членами, как public. Функции и классы, образующие общий интерфейс, должны быть спроектированы таким образом, чтобы представление класса совпадало с его ролью в проекте как средства представления понятий. Напомним, что друзья являются частью общего интерфейса.

Отметим, что абстрактные классы можно использовать для представления понятия упрятывания более высокого уровня ($$1.4.6, $$6.3, $$13.3).

12.5 Свод правил

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

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

  - Нацеливайте пользователя на применение абстракции данных и объектно-ориентированного программирования.
    - Постепенно переходите на новые методы, не спешите.
    - Используйте возможности С++ и методы обЪектно-ориентированного программирования только по мере надобности.
    - Добейтесь соответствия стиля проекта и программы.
  - Концентрируйте внимание на проектировании компонента.
  - Используйте классы для представления понятий.
    - Используйте общее наследование для представления отношений "есть".
    - Используйте принадлежность для представления отношений "имеет".
    - Убедитесь, что отношения использования понятны, не образуют циклов, и что число их минимально.
    - Активно ищите общность среди понятий области приложения и реализации, и возникающие в результате более общие понятия представляйте как базовые классы.
  - Определяйте интерфейс так, чтобы открывать минимальное количество требуемой информации:
    - Используйте, всюду где это можно, частные данные и функции-члены.
    - Используйте описания public или protected, чтобы отличить запросы разработчика производных классов от запросов обычных пользователей.
    - Сведите к минимуму зависимости одного интерфейса от других.
    - Поддерживайте строгую типизацию интерфейсов.
    - Задавайте интерфейсы в терминах типов из области приложения.

Дополнительные правила можно найти $$11.5.

ПРОЕКТИРОВАНИЕ БИБЛИОТЕК

                      Проект библиотеки - это проект языка,
                            (фольклор фирмы Bell Laboratories)
                      ... и наоборот.
                           - А. Кениг

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

13.1 Введение

Разработка библиотеки общего назначения - это гораздо более трудная задача, чем создание обычной программы. Программа - это решение конкретной задачи для конкретной области приложения, тогда как библиотека должна предоставлять возможность решение для множества задач, связанных с многими областями приложения. В обычной программе позволительны сильные допущения об ее окружении, тогда как хорошую библиотеку можно успешно использовать в разнообразных окружениях, создаваемых множеством различных программ. Чем более общей и полезной окажется библиотека, тем в большем числе окружений она будет проверяться, и тем жестче будут требования к ее корректности, гибкости, эффективности, расширяемости, переносимости, непротиворечивости, простоте, полноте, легкости использования и т.д. Все же библиотека не может дать вам все, поэтому нужен определенный компромисс. Библиотеку можно рассматривать как специальный, интересный вариант того, что в предыдущей главе мы называли компонентом. Каждый совет по проектированию и сопровождению компонентов становится предельно важным для библиотек, и, наоборот, многие методы построения библиотек находят применение при проектировании различных компонентов.

Было бы слишком самонадеянно указывать как следует конструировать библиотеки. В прошлом оказались успешными несколько различных методов, а сам предмет остается полем активных дискуссий и экспериментов. Здесь только обсуждаются некоторые важные аспекты этой задачи и предлагаются некоторые приемы, оказавшиеся полезными при создании библиотек. Не следует забывать, что библиотеки предназначены для совершенно разных областей программирования, поэтому не приходится рассчитывать, что какой-то один метод окажется наиболее приемлемым для всех библиотек. Действительно, нет никаких причин полагать, что методы, оказавшиеся полезными при реализации средств параллельного программирования для ядра многопроцессорной операционной системы, окажутся наиболее приемлемыми при создании библиотеки, предназначенной для решения научных задач, или библиотеки, представляющей графический интерфейс.

Понятие класса С++ может использоваться самыми разными способами, поэтому разнообразие стилей программирования может привести к беспорядку. Хорошая библиотека для сведения такого беспорядка к минимуму обеспечивает согласованный стиль программирования, или, по крайней мере, несколько таких стилей. Этот подход делает библиотеку более "предсказуемой", а значит позволяет легче и быстрее изучить ее и правильно использовать. Далее описываются пять архитипичных" классов, и обсуждаются присущие им сильные и слабые стороны: конкретные типы ($$13.2), абстрактные типы ($$13.3), узловые классы ($$13.4), интерфейсные классы ($$13.8), управляющие классы ($$13.9). Все эти виды классов относятся к области понятий, а не являются конструкциями языка. Каждое понятие воплощается с помощью основной конструкции - класса. В идеале надо иметь минимальный набор простых и ортогональных видов классов, исходя из которого можно построить любой полезный и разумно-определенный класс. Идеал нами не достигнут и, возможно, недостижим вообще. Важно понять, что любой из перечисленных видов классов играет свою роль при проектировании библиотеки и, если рассчитывать на общее применение, никакой из них не является по своей сути лучше других.

В этой главе вводится понятие обширного интерфейса ($$13.6), чтобы выделить некоторый общий случай всех этих видов классов. С помощью него определяется понятие каркаса области приложения ($$13.7).

Здесь рассматриваются прежде всего классы, относящиеся строго к одному из перечисленных видов, хотя, конечно, используются классы и гибридного вида. Но использование класса гибридного вида должно быть результатом осознанного решения, возникшего при оценке плюсов и минусов различных видов, а не результатом пагубного стремления уклониться от выбора вида класса (слишком часто "отложим пока выбор" означает просто нежелание думать). Неискушенным разработчикам библиотеки лучше всего держаться подальше от классов гибридного вида. Им можно посоветовать следовать стилю программирования той из существующих библиотек, которая обладает возможностями, необходимыми для проектируемой библиотеки. Отважиться на создание библиотеки общего назначения может только искушенный программист, и каждый создатель библиотеки впоследствии будет "осужден" на долгие годы использования, документирования и сопровождения своего собственного создания.

В языке С++ используются статические типы. Однако, иногда возникает необходимость в дополнение к возможностям, непосредственно предоставляемым виртуальными функциями, получать динамическую информацию о типах. Как это сделать, описано в $$13.5. Наконец, перед всякой нетривиальной библиотекой встает задача управления памятью. Приемы ее решения рассматриваются в $$13.10. Естественно, в этой главе невозможно рассмотреть все методы, оказавшиеся полезными при создании библиотеки. Поэтому можно отослать к другим местам книги, где рассмотрены следующие вопросы: работа с ошибками и устойчивость к ошибкам ($$9.8), использование функциональных объектов  и обратных вызовов ($$10.4.2 и $$9.4.3) , использование шаблонов типа для построения классов ($$8.4).

Многие темы этой главы связаны с классами, являющимися контейнерами, (например, массивы и списки). Конечно, такие контейнерные классы являются шаблонами типа (как было сказано в $$1.и 4.3 $$8). Но здесь для упрощения изложения в примерах используются классы, содержащие указатели на объекты типа класс. Чтобы получить настоящую программу, надо использовать шаблоны типа, как показано в главе 8.

13.2 Конкретные типы

Такие классы как vector ($$1.4), Slist ($$8.3), date ($$5.2.2) и complex ($$7.3) являются конкретными в том смысле, что каждый из них представляет довольно простое понятие и обладает необходимым набором операций. Имеется взаимнооднозначное соответствие между интерфейсом класса и его реализацией. Ни один из них  (изначально) не предназначался в качестве базового для получения производных классов. Обычно в иерархии классов конкретные типы стоят особняком. Каждый конкретный тип можно понять изолированно, вне связи с другими классами. Если реализация конкретного типа удачна, то работающие с ним программы сравнимы по размеру и скорости со сделанными вручную программами, в которых используется некоторая специальная версия общего понятия. Далее, если произошло значительное изменение реализации, обычно модифицируется и интерфейс, чтобы отразить эти изменения. Интерфейс, по своей сути, обязан показать какие изменения оказались существенными в данном контексте. Интерфейс более высокого уровня оставляет больше свободы для изменения реализации, но может ухудшить характеристики программы. Более того, хорошая реализация зависит только от минимального числа действительно существенных классов. Любой из этих классов можно использовать без накладных расходов, возникающих на этапе трансляции или выполнения, и вызванных приспособлением к другим, "сходным" классам программы.

Подводя итог, можно указать такие условия, которым должен удовлетворять конкретный тип:

   [1] полностью отражать данное понятие и метод его реализации;
   [2] с помощью подстановок и операций, полностью использующих полезные свойства понятия и его реализации, обеспечивать эффективность по скорости и памяти, сравнимую с "ручными программами";
   [3] иметь минимальную зависимость от других классов;
   [4] быть понятным и полезным даже изолированно.

Все это должно привести к тесной связи между пользователем и программой, реализующей конкретный тип. Если в реализации произошли изменения, программу пользователя придется перетранслировать, поскольку в ней наверняка содержатся вызовы функций, реализуемые подстановкой, а также локальные переменные конкретного типа.

Для некоторых областей приложения конкретные типы обеспечивают основные типы, прямо не представленные в С++, например: комплексные числа, вектора, списки, матрицы, даты, ассоциативные массивы, строки символов и символы, из другого (не английского) алфавита. В мире, состоящем из конкретных понятий, на самом деле нет такой вещи как список. Вместо этого есть множество списочных классов, каждый из которых специализируется на представлении какой-то версии понятия список. Существует дюжина списочных классов, в том числе: список с односторонней связью; список с двусторонней связью; список с односторонней связью, в котором поле связи не принадлежит объекту; список с двусторонней связью, в котором поля связи не принадлежат объекту; список с односторонней связью, для которого можно просто и эффективно определить входит ли в него данный объект; список с двусторонней связью, для которого можно просто и эффективно определить входит ли в него данный объект и т.д.

Название "конкретный тип" (CDT - concrete data type, т.е. конкретный тип данных) , было выбрано по контрасту с термином абстрактный тип" (ADT - abstract data type, т.е. абстрактный тип данных). Отношения между CDT и ADT обсуждаются в $$13.3.

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

Это потенциальное неудобство компенсируется наличием всех естественных" для данного класса операций, например таких, как индексация для массива и удаление элемента для списка. Эти операции представлены в оптимальном варианте, без "неестественных" операций типа индексации списка или удаления массива, что могло бы вызвать путаницу. Приведем пример:

         void my(slist& sl)
         {
           for (T* p = sl.first(); p; p = sl.next())
           {
              // мой код
           }
           // ...
         }

         void your(vector& v)
         {
           for (int i = 0; i<v.size(); i++)
           {
             // ваш код
           }
           // ...
         }

Существование таких "естественных" для выбранного метода реализации операций обеспечивает эффективность программы и значительно облегчает ее написание. К тому же, хотя реализация вызова подстановкой обычно возможна только для простых операций типа индексации массива или получения следующего элемента списка, она оказывает значительный эффект на скорость выполнения программы. Загвоздка здесь состоит в том, что фрагменты программы, использующие по своей сути эквивалентные операции, как, например, два приведенных выше цикла, могут выглядеть непохожими друг на друга, а фрагменты программы, в которых для эквивалентных операций используются разные конкретные типы, не могу заменять друг друга. Обычно, вообще, невозможно свести сходные фрагменты программы в один.

Пользователь, обращающийся к некоторой функции, должен точно указать тип объекта, с которым работает функция, например:

        void user()
        {
          slist sl;
          vector v(100);

          my(sl);
          your(v);

          my(v);    // ошибка: несоответствие типа
          your(sl); // ошибка: несоответствие типа
        }

Чтобы компенсировать жесткость этого требования, разработчик некоторой полезной функции должен предоставить несколько ее версий, чтобы у пользователя был выбор:

        void my(slist&);
        void my(vector&);

        void your(slist&);
        void your(vector&);

        void user()
        {
          slist sl;
          vector v(100);

          my(sl);
          your(v);

          my(v);     // теперь нормально: вызов my(vector&)
          your(sl);  // теперь нормально: вызов your(slist&)
        }

Поскольку тело функции существенно зависит от типа ее параметра, надо написать каждую версию функций my() и your() независимо друг от друга, что может быть хлопотно.

С учетом всего изложенного конкретный тип, можно сказать, походит на встроенные типы. Положительной стороной этого является тесная связь между пользователем типа и его создателем, а также между пользователями, которые создают объекты данного типа, и пользователями, которые пишут функции, работающие с этими объектами. Чтобы правильно использовать конкретный тип, пользователь должен разбираться в нем детально. Обычно не существует каких-то универсальных свойств, которыми обладали бы все конкретные типы библиотеки, и что позволило бы пользователю, рассчитывая на эти свойства, не тратить силы на изучение отдельных классов. Такова плата за компактность программы и эффективность ее выполнения. Иногда это вполне разумная плата, иногда нет. Кроме того, возможен такой случай, когда отдельный конкретный класс проще понять и использовать, чем более общий (абстрактный) класс. Именно так бывает с классами, представляющими хорошо известные типы данных, такие как массивы или списки.

Тем не менее, укажем, что в идеале надо скрывать, насколько возможно, детали реализации, пока это не ухудшает характеристики программы. Большую помощь здесь оказывают функции-подстановки. Если сделать открытыми переменные, являющиеся членами, с помощью описания public, или непосредственно работать с ними с помощью функций, которые устанавливают и получают значения этих переменных, то почти всегда это приводит к плохому результату. Конкретные типы должны быть все-таки настоящими типами, а не просто программной кучей с нескольким функциями, добавленными ради удобства.

13.3 Абстрактные типы

Самый простой способ ослабить связь между пользователем класса и его создателем, а также между программами, в которых объекты создаются, и программами, в которых они используются, состоит в введении понятия абстрактных базовых классов. Эти классы представляют интерфейс со множеством реализаций одного понятия. Рассмотрим класс set, содержащий множество объектов типа T:

          class set {
          public:
             virtual void insert(T*) = 0;
             virtual void remove(T*) = 0;

             virtual int is_member(T*) = 0;

             virtual T* first() = 0;
             virtual T* next() = 0;

             virtual ~set() { }
          }; 

Этот класс определяет интерфейс с произвольным множеством (set), опираясь на встроенное понятие итерации по элементам множества. Здесь типично отсутствие конструктора и наличие виртуального деструктора, см. также $$6.7. Рассмотрим пример:

          class slist_set : public set, private slist {
              slink* current_elem;
          public:
              void insert(T*);
              void remove(T*);

              int is_member(T*);

              virtual T* first();
              virtual T* next();

              slist_set() : slist(), current_elem(0) { }
          };

          class vector_set : public set, private vector {
             int current_index;
          public:
             void insert(T*);
             void remove(T*);

             int is_member(T*);

             T* first() { current_index = 0; return next(); }
             T* next();

             vector_set(int initial_size)
               : array(initial_size), current_index(0) { }
          }; 

Реализация конкретного типа используется как частный базовый класс, а не член класса. Это сделано и для удобства записи, и потому, что некоторые конкретные типы могут иметь защищенный интерфейс с целью предоставить более прямой доступ к своим членам из производных классов. Кроме того, подобным образом в реализации могут использоваться некоторые классы, которые имеют виртуальные функции и не являются конкретными типами. Только с помощью образования производных классов можно в новом классе изящно переопределить (подавить) виртуальную функцию класса реализации. Интерфейс определяется абстрактным классом.

Теперь пользователь может записать свои функции из $$13.2 таким образом:

           void my(set& s)
           {
             for (T* p = s.first(); p; p = s.next())
             {
                // мой код
             }
             // ...
           }

           void your(set& s)
           {
             for (T* p = s.first(); p; p = s.next())
             {
               // ваш код
             }
             // ...
           }

Стало очевидным сходство между двумя функциями, и теперь достаточно иметь только одну версию для каждой из функций my() или your(), поскольку для общения с slist_set и vector_set обе версии  используют интерфейс, определяемый классом set:

           void user()
           {
             slist_set sl;
             vector_set v(100);

             my(sl);
             your(v);

             my(v);
             your(sl);
           }

Более того, создатели функций my() и your() не обязаны знать описаний классов slist_set и vector_set, и функции my() и your() никоим образом не зависят от этих описаний. Их не надо перетранслировать или как-то изменять, ни если изменились классы slist_set или vector_set ни даже, если предложена новая реализация этих классов. Изменения отражаются лишь на функциях, которые непосредственно используют эти классы, допустим vector_set. В частности, можно воспользоваться традиционным применением заголовочных файлов и включить в программы с функциями my() или your() файл определений set.h, а не файлы slist_set.h или vector_set.h.

В обычной ситуации операции абстрактного класса задаются как чистые виртуальные функции, и такой класс не имеет членов, представляющих данные (не считая скрытого указателя на таблицу виртуальных функций). Это объясняется тем, что добавление невиртуальной функции или члена, представляющего данные, потребует определенных допущений о классе, которые будут ограничивать возможные реализации. Изложенный здесь подход к абстрактным классам близок по духу традиционным методам, основанным на строгом разделении интерфейса и его реализаций. Абстрактный тип служит в качестве интерфейса, а конкретные типы представляют его реализации.

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

Подводя итог, перечислим каким целям должен служить абстрактный тип:

  [1] определять некоторое понятие таким образом, что в программе могут сосуществовать для него несколько реализаций;
  [2] применяя виртуальные функции, обеспечивать достаточно высокую степень компактности и эффективности выполнения программы;
  [3] сводить к минимуму зависимость любой реализации от других классов;
  [4] представлять само по себе осмысленное понятие.

Нельзя сказать, что абстрактные типы лучше конкретных типов, это просто другие типы. Какие из них предпочесть - это, как правило, трудный и важный вопрос для пользователя. Создатель библиотеки может уклониться от ответа на него и предоставить варианты с обеими типами, тем самым выбор перекладывается на пользователя. Но здесь важно ясно понимать, с классом какого вида имеешь дело. Обычно неудачей заканчивается попытка ограничить общность абстрактного типа, чтобы скорость программ, работающих с ним, приблизилась к скорости программ, рассчитанных на конкретный тип. В этом случае нельзя использовать взаимозаменяемые реализации без большой перетрансляции программы после внесения изменений. Столь же неудачна бывает попытка дать "общность" в конкретных типах, чтобы они могли по мощности понятий приблизиться к абстрактным типам. Это снижает эффективность и применимость простых классов. Классы этих двух видов могут сосуществовать, и они должны мирно сосуществовать в программе. Конкретный класс воплощает реализацию абстрактного типа, и смешивать его с абстрактным классом не следует.

Отметим, что ни конкретные, ни абстрактные типы не создаются изначально как базовые классы для построения в дальнейшем производных классов. Построение производных к абстрактным типам классов скорее нужно для задания реализаций, чем для развития самого понятия интерфейса. Всякий конкретный или абстрактный тип предназначен для четкого и эффективного представления в программе отдельного понятия. Классы, которым это удается, редко бывают хорошими кандидатами для создания на их базе новых, но связанных с ними, классов. Действительно, попытки построить производные, "более развитые" классы на базе конкретных или абстрактных типов, таких как, строки, комплексные числа, списки или ассоциативные массивы приводят обычно к громоздким конструкциям. Как правило эти классы следует использовать как члены или частные базовые классы, тогда их можно эффективно применять, не вызывая путаницы и противоречий в интерфейсах и реализациях этих и новых классов.

Когда создается конкретный или абстрактный тип, акцент следует сделать на том, чтобы предложить простой, реализующий хорошо продуманное понятие, интерфейс. Попытки расширить область приложения класса, нагружая его описание всевозможными "полезными" свойствами, приводят только к беспорядку и неэффективности. Этим же кончаются напрасные усилия гарантировать повторное использование класса, когда каждую функцию-член объявляют виртуальной, не подумав зачем и как эти функции будут переопределяться.

Почему мы не стали определять классы slist и vector как прямые производные от класса set, обойдясь тем самым без классов slist_set и vector_set? Другими словами зачем нужны конкретные типы, когда уже определены абстрактные типы? Можно предложить три ответа:

   [1] Эффективность: такие типы, как vector или slist надо создавать без накладных расходов, вызванных отдалением реализаций от интерфейсов (разделения интерфейса и реализации требует концепция абстрактного типа).
   [2] Множественный интерфейс: часто разные понятия лучше всего реализовать как производные от одного класса.
   [3] Повторное использование: нужен механизм, который позволит приспособить для нашей библиотеки типы, разработанные "где-то в другом месте". Конечно, все эти ответы связаны.

В качестве примера [2] рассмотрим понятие генератора итераций. Требуется определить генератор итераций (в дальнейшем итератор) для любого типа так, чтобы с его помощью можно было порождать последовательность объектов этого типа. Естественно для этого нужно использовать уже упоминавшийся класс slist. Однако, нельзя просто определить общий итератор над slist, или даже над set, поскольку общий итератор должен допускать итерации и более сложных объектов, не являющихся множествами, например, входные потоки или функции, которые при очередном вызове дают следующее значение итерации. Значит нам нужны и множество и итератор, и в тоже время нежелательно дублировать конкретные типы, которые являются очевидными реализациями различных видов множеств и итераторов. Можно графически представить желательную структуру классов так: Здесь классы set и iter предоставляют интерфейсы, а slist и stream являются частными классами и представляют реализации. Очевидно, нельзя перевернуть эту иерархию классов и, предоставляя общие интерфейсы, строить производные конкретные типы от абстрактных классов. В такой иерархии каждая полезная операция над каждым полезным абстрактным понятием должна представляться в общем абстрактном базовом классе. Дальнейшее обсуждение этой темы содержится в $$13.6.

Приведем пример простого абстрактного типа, являющегося итератором объектов типа T:

         class iter {
            virtual T* first() = 0;
            virtual T* next() = 0;
            virtual ~iter() { }
         };

         class slist_iter : public iter, private slist {
            slink* current_elem;
         public:
            T* first();
            T* next();

            slist_iter() : current_elem(0) { }
         };

         class input_iter : public iter {
            isstream& is;
         public:
            T* first();
            T* next();

            input_iter(istream& r) : is(r) { }
         };

Можно таким образом использовать определенные нами типы:

         void user(const iter& it)
         {
           for (T* p = it.first(); p; p = it.next()) {
               // ...
           }
         }

         void caller()
         {
           slist_iter sli;
           input_iter ii(cin);

           // заполнение sli

           user(sli);
           user(ii);
         }

Мы применили конкретный тип для реализации абстрактного типа, но можно использовать его и независимо от абстрактных типов или просто вводить такие типы для повышения эффективности программы, см. также $$13.5. Кроме того, можно использовать один конкретный тип для реализации нескольких абстрактных типов.

В разделе $$13.9 описывается более гибкий итератор. Для него зависимость от реализации, которая поставляет подлежащие итерации объекты, определяется в момент инициализации и может изменяться в ходе выполнения программы.

13.4 Узловые классы

В действительности иерархия классов строится, исходя из совсем другой концепции производных классов, чем концепция интерфейс-реализация, которая использовалась для абстрактных типов. Класс рассматривается как фундамент строения. Но даже, если в основании находится абстрактный класс, он допускает некоторое представление в программе и сам предоставляет для производных классов какие-то полезные функции. Примерами узловых классов могут служить классы rectangle ($$6.4.2) и satellite ($$6.5.1). Обычно в иерархии класс представляет некоторое общее понятие, а производные классы представляют конкретные варианты этого понятия. Узловой класс является неотъемлемой частью иерархии классов. Он пользуется сервисом, представляемым базовыми классами, сам обеспечивает определенный сервис и предоставляет виртуальные функции и (или) защищенный интерфейс, чтобы позволить дальнейшую детализацию своих операций в производных классах.

Типичный узловой класс не только предоставляет реализацию интерфейса, задаваемого его базовым классом (как это делает класс реализации по отношению к абстрактному типу), но и сам расширяет интерфейс, добавляя новые функции. Рассмотрим в качестве примера класс dialog_box, который представляет окно некоторого вида на экране. В этом окне появляются вопросы пользователю и в нем он задает свой ответ с помощью нажатия клавиши или "мыши":

        class dialog_box : public window {
           // ...
        public:
           dialog_box(const char* ...); // заканчивающийся нулем список
                                        // обозначений клавиш
           // ...
        virtual int ask();
       }; 

Здесь важную роль играет функция ask() и конструктор, с помощью которого программист указывает используемые клавиши и задает их числовые значения. Функция ask() изображает на экране окно и возвращает номер нажатой в ответ клавиши. Можно представить такой вариант использования:

        void user()
        {
          for (;;) {
              // какие-то команды

              dialog_box cont("continue",
                              "try again",
                              "abort",
                              (char*) 0);
              switch (cont.ask()) {
              case 0:  return;
              case 1:  break;
              case 2:  abort();
              }
            }
          }

Обратим внимание на использование конструктора. Конструктор, как правило, нужен для узлового класса и часто это нетривиальный конструктор. Этим узловые классы отличаются от абстрактных классов, для которых редко нужны конструкторы.

Пользователь класса dialog_box ( а не только создатель этого класса) рассчитывает на сервис, представляемый его базовыми классами. В рассматриваемом примере предполагается, что существует некоторое стандартное размещение нового окна на экране. Если пользователь захочет управлять размещением окна, базовый для
dialog_box класс window (окно) должен предоставлять такую возможность, например:

          dialog_box cont("continue","try again","abort",(char*)0);
          cont.move(some_point); 

Здесь функция движения окна move() рассчитывает на определенные функции базовых классов.

Сам класс dialog_box является хорошим кандидатом для построения производных классов. Например, вполне разумно иметь такое окно, в котором, кроме нажатия клавиши или ввода с мышью, можно задавать строку символов (скажем, имя файла). Такое окно dbox_w_str строится как производный класс от простого окна dialog_box:

          class dbox_w_str : public dialog_box {
              // ...
          public:
             dbox_w_str (
              const char* sl,  // строка запроса пользователю
              const char* ...  // список обозначений клавиш
             );
             int ask();
             virtual char* get_string();
             //...
          };

 Функция get_string() является той операцией, с помощью которой программист получает заданную пользователем строку. Функция ask() из класса dbox_w_str гарантирует, что строка введена правильно, а если пользователь не стал вводить строку, то тогда в программу возвращается соответствующее значение (0).

          void user2()
          {
            // ...
            dbox_w_str file_name("please enter file name",
                                 "done",
                                 (char*)0);
            file_name.ask();
            char* p = file_name.get_string();
            if (p) {
               // используем имя файла
            }
            else {
              // имя файла не задано
            }
            //
          }

Подведем итог - узловой класс должен:

   [1] рассчитывать на свои базовые классы как для их реализации, так и для представления сервиса пользователям этих классов;
   [2] представлять более полный интерфейс (т.е. интерфейс с большим числом функций-членов) пользователям, чем базовые классы;
   [3] основывать в первую очередь (но не исключительно) свой общий интерфейс на виртуальных функциях;
   [4] зависеть от всех своих (прямых и косвенных) базовых классов;
   [5] иметь смысл только в контексте своих базовых классов;
   [6] служить базовым классом для построения производных классов;
   [7] воплощаться в объекте.

Не все, но многие, узловые классы будут удовлетворять условиям 1, 2, 6 и 7. Класс, который не удовлетворяет условию 6, походит на конкретный тип и может быть назван конкретным узловым классом. Класс, который не удовлетворяет условию 7, походит на абстрактный тип и может быть назван абстрактным узловым классом. У многих узловых классов есть защищенные члены, чтобы предоставить для производных классов менее ограниченный интерфейс.

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

13.5 Динамическая информация о типе

Иногда бывает полезно знать истинный тип объекта до его использования в каких-либо операциях. Рассмотрим функцию my(set&) из $$13.3.

           void my_set(set& s)
           {
              for ( T* p = s.first(); p; p = s.next()) {
                  // мой код
              }
              // ...
           }

Она хороша в общем случае, но представим,- стало известно, что многие параметры множества представляют собой объекты типа
slist. Возможно также стал известен алгоритм перебора элементов, который значительно эффективнее для списков, чем для произвольных множеств. В результате эксперимента удалось выяснить, что именно этот перебор является узким местом в системе. Тогда, конечно, имеет смысл учесть в программе отдельно вариант с slist. Допустив возможность определения истинного типа параметра, задающего множество, функцию
my(set&) можно записать так:

         void my(set& s)
         {
            if (ref_type_info(s) == static_type_info(slist_set)) {
               // сравнение двух представлений типа

               // s типа slist

               slist& sl = (slist&)s;
               for (T* p = sl.first(); p; p = sl.next()) {

                  // эффективный вариант в расчете на list

               }
          }
          else {

             for ( T* p = s.first(); p; p = s.next()) {

                  // обычный вариант для произвольного множества

              }
          }
          // ...
       }

Как только стал известен конкретный тип slist, стали доступны определенные операции со списками, и даже стала возможна реализация основных операций подстановкой.

Приведенный вариант функции действует отлично, поскольку slist - это конкретный класс, и действительно имеет смысл отдельно разбирать вариант, когда параметр является slist_set. Рассмотрим теперь такую ситуацию, когда желательно отдельно разбирать вариант как для класса, так и для всех его производных классов. Допустим, мы имеем класс dialog_box из $$13.4 и хотим узнать, является ли он классом dbox_w_str. Поскольку может существовать много производных классов от dbox_w_str, простую проверку на совпадение с ним нельзя считать хорошим решением. Действительно, производные классы могут представлять самые разные варианты запроса строки. Например, один производный от dbox_w_str класс может предлагать пользователю варианты строк на выбор, другой может обеспечить поиск в каталоге и т.д. Значит, нужно проверять и на совпадение со всеми производными от dbox_w_str классами. Это так же типично для узловых классов, как проверка на вполне определенный тип типична для абстрактных классов, реализуемых конкретными типами.

         void f(dialog_box& db)
         {
            dbox_w_str* dbws = ptr_cast(dbox_w_str, &db);
            if (dbws) {  // dbox_w_str
               // здесь можно использовать dbox_w_str::get_string()
            }
            else {

              // ``обычный'' dialog_box
            }

            // ...
          }

Здесь "операция" приведения ptr_cast() свой второй параметр (указатель) приводит к своему первому параметру (типу) при условии, что указатель настроен на объект тип, которого совпадает с заданным
(или является производным классом от заданного типа). Для проверки типа dialog_box используется указатель, чтобы после приведения его можно было сравнить с нулем.

Возможно альтернативное решение с помощью ссылки на dialog_box:

          void g(dialog_box& db)
          {
            try {
                dbox_w_str& dbws = ref_cast(dialog_box,db);

                // здесь можно использовать dbox_w_str::get_string()

             }
             catch (Bad_cast) {

                // ``обычный'' dialog_box

             }

             // ...
          }

Поскольку нет приемлемого представления нулевой ссылки, с которой можно сравнивать, используется особая ситуация, обозначающая ошибку приведения (т.е. случай, когда тип не есть dbox_w_str). Иногда лучше избегать сравнения с результатом приведения.

Различие функций ref_cast() и ptr_cast() служит хорошей иллюстрацией различий между ссылками и указателями: ссылка обязательно ссылается на объект, тогда как указатель может и не ссылаться, поэтому для указателя часто нужна проверка.

13.5.1 Информация о типе

В С++ нет иного стандартного средства получения динамической информации о типе, кроме вызовов виртуальных функцийЬ. Ь Хотя было сделано несколько предложений по расширению С++ в этом направлении. Смоделировать такое средство довольно просто и в большинстве больших библиотек есть возможности динамических запросов о типе. Здесь предлагается решение, обладающее тем полезным свойством, что объем информации о типе можно произвольно расширять. Его можно реализовать с помощью вызовов виртуальных функций, и оно может входить в расширенные реализации С++.

Достаточно удобный интерфейс с любым средством, поставляющим информацию о типе, можно задать с помощью следующих операций:

        typeid static_type_info(type) // получить typeid для имени типа
        typeid ptr_type_info(pointer) // получить typeid для указателя
        typeid ref_type_info(reference) // получить typeid для ссылки
        pointer ptr_cast(type,pointer)  // преобразование указателя
        reference ref_cast(type,reference)  // преобразование ссылки 

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

Большинство пользователей, которым вообще нужна динамическая идентификация типа, может ограничиться операциями приведения
ptr_cast() и ref_cast(). Таким образом пользователь отстраняется от дальнейших сложностей, связанных с динамической идентификацией типа. Кроме того, ограниченное использование динамической информации о типе меньше всего чревато ошибками.

Если недостаточно знать, что операция приведения прошла успешно, а нужен истинный тип (например, объектно-ориентированный ввод-вывод), то можно использовать операции динамических запросов о типе:
static_type_info(), ptr_type_info() и ref_type_info(). Эти операции возвращают объект класса typeid. Как было показано в примере с set и slist_set, объекты класса typeid можно сравнивать. Для большинства задач этих сведений о классе typeid достаточно. Но для задач, которым нужна более полная информация о типе, в классе typeid есть функция get_type_info():

          class typeid {
              friend class Type_info;
          private:
              const Type_info* id;
          public:
              typeid(const Type_info* p) : id(p) { }
              const Type_info* get_type_info() const { return id; }
              int operator==(typeid i) const ;
          }; 

Функция get_type_info() возвращает указатель на неменяющийся (const) объект класса Type_info из typeid. Существенно, что объект не меняется: это должно гарантировать, что динамическая информация о типе отражает статические типы исходной программы. Плохо, если при выполнении программы некоторый тип может изменяться.

С помощью указателя на объект класса Type_info пользователь получает доступ к информации о типе из typeid и, теперь его программа начинает зависеть от конкретной системы динамических запросов о типе и от структуры динамической информации о нем. Но эти средства не входят в стандарт языка, а задать их с помощью хорошо продуманных макроопределений непросто.

13.5.2 Класс Type_info

В классе Type_info есть минимальный объем информации для реализации операции ptr_cast(); его можно определить следующим образом:

          class Type_info {
              const char* n;       // имя
              const Type_info** b; // список базовых классов
          public:
              Type_info(const char* name, const Type_info* base[]);

              const char* name() const;
              Base_iterator bases(int direct=0) const;
              int same(const Type_info* p) const;
              int has_base(const Type_info*, int direct=0) const;
              int can_cast(const Type_info* p) const;

              static const Type_info info_obj;
              virtual typeid get_info() const;
              static typeid info();
          }; 

Две последние функции должны быть определены в каждом производном от Type_info классе.

Пользователь не должен заботиться о структуре объекта Type_info, и она приведена здесь только для полноты изложения. Строка, содержащая имя типа, введена для того, чтобы дать возможность поиска информации в таблицах имен, например, в таблице отладчика. С помощью нее а также информации из объекта Type_info можно выдавать более осмысленные диагностические сообщения. Кроме того, если возникнет потребность иметь несколько объектов типа Type_info, то имя может служить уникальным ключом этих объектов.

          const char* Type_info::name() const
          {
            return n;
          }

          int Type_info::same(const Type_info* p) const
          {
            return this==p || strcmp(n,p->n)==0;
          }

          int Type_info::can_cast(const Type_info* p) const
          {
            return same(p) || p->has_base(this);
          }

Доступ к информации о базовых классах обеспечивается функциями bases() и has_base(). Функция bases() возвращает итератор, который порождает указатели на базовые классы объектов Type_info, а с помощью функции has_base() можно определить является ли заданный класс базовым для другого класса. Эти функции имеют необязательный параметр direct, который показывает, следует ли рассматривать все базовые классы (direct=0), или только прямые базовые классы (direct=1). Наконец, как описано ниже, с помощью функций get_info() и info() можно получить динамическую информацию о типе для самого класса Type_info.

Здесь средство динамических запросов о типе сознательно реализуется с помощью совсем простых классов. Так можно избежать привязки к определенной библиотеке. Реализация в расчете на конкретную библиотеку может быть иной. Можно, как всегда, посоветовать пользователям избегать излишней зависимости от деталей реализации.

Функция has_base() ищет базовые классы с помощью имеющегося в Type_info списка базовых классов. Хранить информацию о том, является ли базовый класс частным или виртуальным, не нужно, поскольку все ошибки, связанные с ограничениями доступа или неоднозначностью, будут выявлены при трансляции.

        class base_iterator {
          short i;
          short alloc;
          const Type_info* b;
        public:
          const Type_info* operator() ();
          void reset() { i = 0; }

          base_iterator(const Type_info* bb, int direct=0);
          ~base_iterator() { if (alloc) delete[] (Type_info*)b; }
       }; 

В следующем примере используется необязательный параметр для указания, следует ли рассматривать все базовые классы (direct==0) или только прямые базовые классы (direct==1).

      base_iterator::base_iterator(const Type_info* bb, int direct)
      {
        i = 0;

        if (direct) { // использование списка прямых базовых классов
           b = bb;
           alloc = 0;
           return;
        }

        // создание списка прямых базовых классов:

        // int n = число базовых
        b = new const Type_info*[n+1];
        // занести базовые классы в b

        alloc = 1;
        return;
      }

      const Type_info* base_iterator::operator() ()
      {
        const Type_info* p = &b[i];
        if (p) i++;
        return p;
      }

Теперь можно  задать операции запросов о типе с помощью макроопределений:

      #define static_type_info(T)  T::info()

      #define ptr_type_info(p)   ((p)->get_info())
      #define ref_type_info(r)   ((r).get_info())

      #define ptr_cast(T,p) \
         (T::info()->can_cast((p)->get_info()) ? (T*)(p) : 0)
      #define ref_cast(T,r) \
         (T::info()->can_cast((r).get_info()) \
             ? 0 : throw Bad_cast(T::info()->name()), (T&)(r))

Предполагается, что тип особой ситуации Bad_cast (Ошибка_приведения)
описан так:

      class Bad_cast {
        const char* tn;
        // ...
      public:
        Bad_cast(const char* p) : tn(p) { }
        const char* cast_to() { return tn; }
        //  ...
      }; 

В разделе $$4.7 было сказано, что появление макроопределений служит сигналом возникших проблем. Здесь проблема в том, что только транслятор имеет непосредственный доступ к литеральным типам, а макроопределения скрывают специфику реализации. По сути для хранения информации для динамических запросов о типах предназначена таблица виртуальных функций. Если реализация непосредственно поддерживает динамическую идентификацию типа, то рассматриваемые операции можно реализовать более естественно, эффективно и элегантно. В частности, очень просто реализовать функцию ptr_cast(), которая преобразует указатель на виртуальный базовый класс в указатель на его производные классы.

13.5.3 Как создать систему динамических запросов о типе

Здесь показано, как можно прямо реализовать динамические запросы о типе, когда в трансляторе таких возможностей нет. Это достаточно утомительная задача и можно пропустить этот раздел, так как в нем есть только детали конкретного решения.

Классы set и slist_set из $$13.3 следует изменить так, чтобы с ними могли работать операции запросов о типе. Прежде всего, в базовый класс set нужно ввести функции-члены, которые используют операции запросов о типе:

       class set {
         public:
           static const Type_info info_obj;
           virtual typeid get_info() const;
           static typeid info();

           // ...
      }; 

При выполнении программы единственным представителем объекта типа
set является set::info_obj, который определяется так:

      const Type_info set::info_obj("set",0); 

С учетом этого определения функции тривиальны:

     typeid set::get_info() const { return &info_obj; }
     typeid set::info() { return &info_obj; }
     typeid slist_set::get_info() const { return &info_obj; }
     typeid slist_set::info() { return &info_obj; }

Виртуальная функция get_info() будет предоставлять операции ref_type_info() и ptr_type_info(), а статическая функция info() - операцию static_type_info().

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

Нужно несколько изменить класс slist_set:

       class slist_set : public set, private slist {
          // ...
       public:
          static const Type_info info_obj;
          virtual typeid get_info() const;
          static typeid info();

          // ...
       };

       static const Type_info* slist_set_b[]
          = { &set::info_obj, &slist::info_obj, 0 };
       const Type_info slist_set::info_obj("slist_set",slist_set_b);

       typeid slist_set::get_info() const { return &info_obj; }
       typeid slist_set::info() { return &info_obj; }

13.5.4 Расширенная динамическая информация о типе

В классе Type_info содержится только минимум информации, необходимой для идентификации типа и безопасных операций приведения. Но поскольку в самом классе Type_info есть функции-члены info() и get_info(), можно построить производные от него классы, чтобы в динамике определять, какие объекты Type_info возвращают эти функции. Таким образом, не меняя класса Type_info, пользователь может получать больше информации о типе с помощью объектов, возвращаемых функциями dynamic_type() и static_type(). Во многих случаях дополнительная информация должна содержать таблицу членов объекта:

           struct Member_info {
             char* name;
             Type_info* tp;
             int offset;
           };

           class Map_info : public Type_info {
              Member_info** mi;
           public:
              static const Type_info info_obj;
              virtual typeid get_info() const;
              static typeid info();

              // функции доступа
           }; 

Класс Type_info вполне подходит для стандартной библиотеки. Это базовый класс с минимумом необходимой информации, из которого можно получать производные классы, предоставляющие больше информации. Эти производные классы могут определять или сами пользователи, или какие-то служебные программы, работающие с текстом на С++, или сами трансляторы языка.

13.5.5 Правильное и неправильное использование динамической информации о типе

Динамическая информация о типе может использоваться во многих ситуациях, в том числе для: объектного ввода-вывода, объектно-ориентированных баз данных,  отладки. В тоже время велика вероятность ошибочного использования такой информации. Известно,что в языке Симула использование таких средств, как правило, приводит к ошибкам. Поэтому эти средства не были включены в С++. Слишком велик соблазн воспользоваться динамической информацией о типе, тогда как правильнее вызвать виртуальную функцию. Рассмотрим в качестве примера класс Shape из $$1.2.5. Функцию rotate можно было задать так:

        void rotate(const Shape& s)
            // неправильное использование динамической
            // информации о типе

        {
          if (ref_type_info(s)==static_type_info(Circle)) {
             // для этой фигуры ничего не надо
          }
          else if (ref_type_info(s)==static_type_info(Triangle)) {
             // вращение треугольника
          }
          else if (ref_type_info(s)==static_type_info(Square)) {
             // вращение квадрата
          }
          // ...
        }

Если для переключателя по типу поля мы используем динамическую информацию о типе, то тем самым нарушаем в программе принцип модульности и отрицаем сами цели объектно-ориентированного программирования. К тому же это решение чревато ошибками: если в качестве параметра функции будет передан объект производного от Circle класса, то она сработает неверно (действительно, вращать круг (Circle)
нет смысла, но для объекта, представляющего производный класс, это может потребоваться). Опыт показывает, что программистам, воспитанным на таких языках как С или Паскаль, трудно избежать этой ловушки. Стиль программирования этих языков требует меньше предусмотрительности, а при создании библиотеки такой стиль можно просто считать небрежностью.

Может возникнуть вопрос, почему в интерфейс с системой динамической информации о типе включена условная операция приведения ptr_cast(), а не операция is_base(), которая непосредственно определяется с помощью операции has_base() из класса Type_info. Рассмотрим такой пример:

            void f(dialog_box& db)
            {
              if (is_base(&db,dbox_w_str)) { // является ли db базовым
                                             // для  dbox_w-str?
                 dbox_w_str* dbws = (dbox_w_str*) &db;
                 // ...
              }

              // ...
            }

Решение с помощью ptr_cast ($$13.5) более короткое, к тому же здесь явная и безусловная операция приведения отделена от проверки в операторе
if, значит появляется возможность ошибки, неэффективности и даже неверного результата. Неверный результат может возникнуть в тех редких случаях, когда система динамической идентификации типа распознает, что один тип является производным от другого, но транслятору этот факт неизвестен, например:

            class D;
            class B;

            void g(B* pb)
            {
              if (is_base(pb,D)) {
                 D* pb = (D*)pb;

                 // ...
              }

              // ...
            }

Если транслятору пока неизвестно следующее описание класса D:

            class D : public A, public B {
               // ...
            }; 

то возникает ошибка, т.к. правильное приведение указателя pb к D* требует изменения значения указателя. Решение с операцией ptr_cast() не сталкивается с этой трудностью, поскольку эта операция применима только при условии, что в области видимости находятся описания обеих ее параметров. Приведенный пример показывает, что операция приведения для неописанных классов по сути своей ненадежна, но запрещение ее существенно ухудшает совместимость с языком С.

13.6 Обширный интерфейс

Когда обсуждались абстрактные типы ($$13.3) и узловые классы ($$13.4), было подчеркнуто, что все функции базового класса реализуются в самом базовом или в производном классе. Но существует и другой способ построения классов. Рассмотрим, например, списки, массивы, ассоциативные массивы, деревья и т.д. Естественно желание для всех этих типов, часто называемых контейнерами, создать обобщающий их класс, который можно использовать в качестве интерфейса с любым из перечисленных типов. Очевидно, что пользователь не должен знать детали, касающиеся конкретного контейнера. Но задача определения интерфейса для обобщенного контейнера нетривиальна. Предположим, что такой контейнер будет определен как абстрактный тип, тогда какие операции он должен предоставлять? Можно предоставить только те операции, которые есть в каждом контейнере, т.е. пересечение множеств операций, но такой интерфейс будет слишком узким. На самом деле, во многих, имеющих смысл случаях такое пересечение пусто. В качестве альтернативного решения можно предоставить объединение всех множеств операций и предусмотреть динамическую ошибку, когда в этом интерфейсе к объекту применяется "несуществующая" операция. Объединение интерфейсов классов, представляющих  множество понятий, называется обширным интерфейсом. Опишем "общий" контейнер объектов типа T:

          class container {
          public:
            struct Bad_operation { // класс особых ситуаций
                const char* p;
                Bad_operation(const char* pp) : p(pp) { }
            };

            virtual void put(const T*)
               { throw Bad_operation("container::put"); }
            virtual T* get()
               { throw Bad_operation("container::get"); }

            virtual T*& operator[](int)
               { throw Bad_operation("container::[](int)"); }
            virtual T*& operator[](const char*)
               { throw Bad_operation("container::[](char*)"); }
            // ...
          }; 

Все-таки существует мало реализаций, где удачно представлены как индексирование, так и операции типа списочных, и, возможно, не стоит совмещать их в одном классе.

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

Можно следующим образом описать контейнер, реализованный как простой список с односторонней связью:

     class slist_container : public container, private slist {
     public:
       void put(const T*);
       T* get();

       T*& operator[](int)
           { throw Bad_operation("slist::[](int)"); }
       T*& operator[](const* char)
           { throw Bad_operation("slist::[](char*)"); }
       // ...
     }; 

Чтобы упростить обработку динамических ошибок для списка введены операции индексирования. Можно было не вводить эти нереализованные для списка операции и ограничиться менее полной информацией, которую предоставляют особые ситуации, запущенные в классе container:

      class vector_container : public container, private vector {
      public:
         T*& operator[](int);
         T*& operator[](const char*);
         // ...
      }; Если быть осторожным, то все работает нормально:

      void f()
      {
        slist_container sc;
        vector_container vc;
        // ...
      }

      void user(container& c1, container& c2)
      {
        T* p1 = c1.get();
        T* p2 = c2[3];
        // нельзя использовать c2.get() или c1[3]
        // ...
      }

Все же для избежания ошибок при выполнении программы часто приходится использовать динамическую информацию о типе ($$13.5) или особые ситуации ($$9). Приведем пример:

       void user2(container& c1, container& c2)
       /*
          обнаружение ошибки просто, восстановление - трудная задача
       */
       {
         try {
             T* p1 = c1.get();
             T* p2 = c2[3];
             // ...
          }
          catch(container::Bad_operation& bad) {
            // Приехали!
            // А что теперь делать?
          }
        }

или другой пример:

        void user3(container& c1, container& c2)
        /*
          обнаружение ошибки непросто,
          а восстановление по прежнему трудная задача
        */
        {
          slist* sl = ptr_cast(slist_container,&c1);
          vector* v = ptr_cast(vector_container, &c2);

          if (sl && v) {
             T* p1 = c1.get();
             T* p2 = c2[3];
             // ...
          }
          else {
             // Приехали!
             // А что теперь делать?
          }
        }

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

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

13.7 Каркас области приложения

Мы перечислили виды классов, из которых можно создать библиотеки, нацеленные на проектирование и повторное использование прикладных программ. Они предоставляют определенные "строительные блоки" и объясняют как из них строить. Разработчик прикладного обеспечения создает каркас, в который должны вписаться универсальные строительные блоки. Задача проектирования прикладных программ может иметь иное, более обязывающее решение: написать программу, которая сама будет создавать общий каркас области приложения. Разработчик прикладного обеспечения в качестве строительных блоков будет встраивать в этот каркас прикладные программы. Классы, которые образуют каркас области приложения, имеют настолько обширный интерфейс, что их трудно назвать типами в обычном смысле слова. Они приближаются к тому пределу, когда становятся чисто прикладными классами, но при этом в них фактически есть только описания, а все действия задаются функциями, написанными прикладными программистами.

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

         class filter {
         public:
           class Retry {
           public:
             virtual const char* message() { return 0; }
           };

         virtual void start() { }
         virtual int retry() { return 2; }
         virtual int read() = 0;
         virtual void write() { }
         virtual void compute() { }
         virtual int result() = 0;
       };

Нужные для производных классов функции описаны как чистые виртуальные, остальные функции просто пустые. Каркас содержит основной цикл обработки и зачаточные средства обработки ошибок:

       int main_loop(filter* p)
       {
         for (;;) {
             try {
                 p->start();
                 while (p->read()) {
                       p->compute();
                       p->write();
                 }
                 return p->result();
             }
             catch (filter::Retry& m) {
               cout << m.message() << '\n';
               int i = p->retry();
               if (i) return i;
             }
             catch (...) {
               cout << "Fatal filter error\n";
               return 1;
             }
           }
         }

Теперь прикладную программу можно написать так:

         class myfilter : public filter {
            istream& is;
            ostream& os;
            char c;
            int nchar;

         public:
            int read() { is.get(c); return is.good(); }
            void compute() { nchar++; };
            int result()
                { os << nchar
                     << "characters read\n";
                     return 0;
                }

            myfilter(istream& ii, ostream& oo)
              : is(ii), os(oo), nchar(0) { }
         }; и вызывать ее следующим образом:

        int main()
        {
          myfilter f(cin,cout);
          return main_loop(&f);
        }

Настоящий каркас, чтобы рассчитывать на применение в реальных задачах, должен создавать более развитые структуры и предоставлять больше полезных функций, чем в нашем простом примере. Как правило, каркас образует дерево узловых классов. Прикладной программист поставляет только классы, служащие листьями в этом многоуровневом дереве, благодаря чему достигается общность между различными прикладными программами и упрощается повторное использование полезных функций, предоставляемых каркасом. Созданию каркаса могут способствовать библиотеки, в которых определяются некоторые полезные классы, например, такие как scrollbar ($$12.2.5) и dialog_box ($$13.4). После определения своих прикладных классов программист может использовать эти классы.

13.8 Интерфейсные классы

Про один из самых важных видов классов обычно забывают - это "скромные" интерфейсные классы. Такой класс не выполняет какой-то большой работы, ведь иначе, его не называли бы интерфейсным. Задача интерфейсном класса приспособить некоторую полезную функцию к определенному контексту. Достоинство интерфейсных классов в том, что они позволяют совместно использовать полезную функцию, не загоняя ее в жесткие рамки. Действительно, невозможно рассчитывать, что функция сможет сама по себе одинаково хорошо удовлетворить самые разные запросы.

Интерфейсный класс в чистом виде даже не требует генерации кода. Вспомним описание шаблона типа Splist из $$8.3.2:

          template<class T>
          class Splist : private Slist<void*> {
          public:
            void insert(T* p) { Slist<void*>::insert(p); }
            void append(T* p) { Slist<void*>::append(p); }
            T* get() { return (T*) Slist<void*>::get(); }
          }; 

Класс Splist преобразует список ненадежных обобщенных указателей типа void* в более удобное семейство надежных классов, представляющих списки. Чтобы применение интерфейсных классов не было слишком накладно, нужно использовать функции-подстановки. В примерах, подобных приведенному, где задача функций-подстановок только подогнать тип, накладные расходы в памяти и скорости выполнения программы не возникают.

Естественно, можно считать интерфейсным абстрактный базовый класс, который представляет абстрактный тип, реализуемый конкретными типами ($$13.3), также как и управляющие классы из раздела 13.9. Но здесь мы рассматриваем классы, у которых нет иных назначений - только задача адаптации интерфейса.

Рассмотрим задачу слияния двух иерархий классов с помощью множественного наследования. Как быть в случае коллизии имен, т.е. ситуации, когда в двух классах используются виртуальные функции с одним именем, производящие совершенно разные операции? Пусть есть видеоигра под названием "Дикий запад", в которой диалог с пользователем организуется с помощью окна общего вида (класс
Window):

          class Window {
             // ...
             virtual void draw();
          };

          class Cowboy {
             // ...
             virtual void draw();
         };

         class CowboyWindow : public Cowboy, public Window {
            // ...
         }; 

В этой игре класс CowboyWindow представляет движение ковбоя на экране и управляет взаимодействием игрока с ковбоем. Очевидно, появится много полезных функций, определенных в классе Window и
Cowboy, поэтому предпочтительнее использовать множественное наследование, чем описывать Window или Cowboy как члены. Хотелось бы передавать этим функциям в качестве параметра объект типа CowboyWindow, не требуя от программиста указания каких-то спецификаций объекта. Здесь как раз и возникает вопрос, какую функции выбрать для CowboyWindow: Cowboy::draw() или Window::draw().

В классе CowboyWindow может быть только одна функция с именем draw(), но поскольку полезная функция работает с объектами Cowboy или Window и ничего не знает о CowboyWindow, в классе CowboyWindow
должны подавляться (переопределяться) и функция Cowboy::draw(), и функция Window_draw(). Подавлять обе функции с помощью одной - raw() неправильно, поскольку, хотя используется одно имя, все же все функции draw() различны и не могут переопределяться одной.

Наконец, желательно, чтобы в классе CowboyWindow наследуемые функции Cowboy::draw() и Window::draw() имели различные однозначно заданные имена.

Для решения этой задачи нужно ввести дополнительные классы для Cowboy и Window. Вводится два новых имени для функций draw() и гарантируется, что их вызов в классах Cowboy и Window приведет к вызову функций с новыми именами:

         class CCowboy : public Cowboy {
            virtual int cow_draw(int) = 0;
            void draw() { cow_draw(i); } // переопределение Cowboy::draw
         };

         class WWindow : public Window {
            virtual int win_draw() = 0;
            void draw() { win_draw(); } // переопределение Window::draw
         }; 

Теперь с помощью интерфейсных классов CCowboy и WWindow можно определить класс CowboyWindow и сделать требуемые переопределения функций cow_draw() и win_draw:

         class CowboyWindow : public CCowboy, public WWindow {
           // ...
           void cow_draw();
           void win_draw();
         }; 

Отметим, что в действительности трудность возникла лишь потому, что у обеих функций draw()  одинаковый тип параметров. Если бы типы параметров различались, то обычные правила разрешения неоднозначности при перегрузке гарантировали бы, что трудностей не возникнет, несмотря на наличие различных функций с одним именем.

Для каждого случая использования интерфейсного класса можно предложить такое расширение языка, чтобы требуемая адаптация проходила более эффективно или задавалась более элегантным способом. Но такие случаи являются достаточно редкими, и нет смысла чрезмерно перегружать язык, предоставляя специальные средства для каждого отдельного случая. В частности, случай коллизии имен при слиянии иерархий классов довольно редки, особенно если сравнивать с тем, насколько часто программист создает классы. Такие случаи могут возникать при слиянии иерархий классов из разных областей (как в нашем примере: игры и операционные системы). Слияние таких разнородных структур классов всегда непростая задача, и разрешение коллизии имен является в ней далеко не самой трудной частью. Здесь возникают проблемы из-за разных стратегий обработки ошибок, инициализации, управления памятью. Пример, связанный с коллизией имен, был приведен потому, что предложенное решение: введение интерфейсных классов с функциями-переходниками, - имеет много других применений. Например, с их помощью можно менять не только имена, но и типы параметров и возвращаемых значений, вставлять определенные динамические проверки и т.д.

Функции-переходники CCowboy::draw() и WWindow_draw являются виртуальными, и простая оптимизация с помощью подстановки невозможна. Однако, есть возможность, что транслятор распознает такие функции и удалит их из цепочки вызовов.

Интерфейсные функции служат для приспособления интерфейса к запросам пользователя. Благодаря им в интерфейсе собираются операции, разбросанные по всей программе. Обратимся к классу vector из $$1.4. Для таких векторов, как и для массивов, индекс отсчитывается от нуля. Если пользователь хочет работать с диапазоном индексов, отличным от диапазона 0..size-1, нужно сделать соответствующие приспособления, например, такие:

          void f()
          {
            vector v(10);  // диапазон [0:9]

            // как будто v в диапазоне [1:10]:

            for (int i = 1; i<=10; i++) {
               v[i-1] = ... // не забыть пересчитать индекс

            }
            // ...
          }

Лучшее решение дает класс vec c произвольными границами индекса:

          class vec : public vector {
            int lb;
          public:
            vec(int low, int high)
               : vector(high-low+1) { lb=low; }

            int& operator[](int i)
               { return vector::operator[](i-lb); }

            int low() { return lb; }
            int high() { return lb+size() - 1; }
          }; 

Класс vec можно использовать без дополнительных операций, необходимых в первом примере:

          void g()
          {
            vec v(1,10);  // диапазон [1:10]

            for (int i = 1; i<=10; i++) {
                v[i] = ...

            }
            // ...
          }

Очевидно, вариант с классом vec нагляднее и безопаснее.

Интерфейсные классы имеют и другие важные области применения, например, интерфейс между программами на С++ и программами на другом языке ($$12.1.4) или интерфейс с особыми библиотеками С++.

13.9 Управляющие классы

Концепция абстрактного класса дает эффективное средство для разделения интерфейса и его реализации. Мы применяли эту концепцию и получали постоянную связь между интерфейсом, заданным абстрактным типом, и реализацией, представленной конкретным типом. Так, невозможно переключить абстрактный итератор с одного класса-источника на другой, например, если исчерпано множество (класс set), невозможно перейти на потоки.

Далее, пока мы работаем с объектами абстрактного типа с помощью указателей или ссылок, теряются все преимущества виртуальных функций. Программа пользователя начинает зависеть от конкретных классов реализации. Действительно, не зная размера объекта, даже при абстрактном типе нельзя разместить объект в стеке, передать как параметр по значению или разместить как статический. Если работа с объектами организована через указатели или ссылки, то задача распределения памяти перекладывается на пользователя ($$13.10).

Существует и другое ограничение, связанное с использованием абстрактных типов. Объект такого класса всегда имеет определенный размер, но классы, отражающие реальное понятие, могут требовать память разных размеров.

Есть распространенный прием преодоления этих трудностей, а именно, разбить отдельный объект на две части: управляющую, которая определяет интерфейс объекта, и содержательную, в которой находятся все или большая часть атрибутов объекта. Связь между двумя частями реализуется с помощью указателя в управляющей части на содержательную часть. Обычно в управляющей части кроме указателя есть и другие данные, но их немного. Суть в том, что состав управляющей части не меняется при изменении содержательной части, и она настолько мала, что можно свободно работать с самими объектами, а не с указателями или ссылками на них.

Простым примером управляющего класса может служить класс string из $$7.6. В нем содержится интерфейс, контроль доступа и управление памятью для содержательной части. В этом примере управляющая и содержательная части представлены конкретными типами, но чаще содержательная часть представляется абстрактным классом.

Теперь вернемся к абстрактному типу set из $$13.3. Как можно определить управляющий класс для этого типа, и какие это даст плюсы и минусы? Для данного класса set можно определить управляющий класс просто перегрузкой операции ->:

         class set_handle {
            set* rep;
         public:
            set* operator->() { return rep; }

            set_handler(set* pp) : rep(pp) { }
         }; 

Это не слишком влияет на работу с множествами, просто передаются объекты типа set_handle вместо объектов типа set& или set*, например:

         void my(set_handle s)
         {
           for (T* p = s->first(); p; p = s->next())
           {
              // ...
           }
           // ...
         }

         void your(set_handle s)
         {
           for (T* p = s->first(); p; p = s->next())
           {
             // ...
           }
           // ...
         }

         void user()
         {
           set_handle sl(new slist_set);
           set_handle v(new vector_set v(100));

           my(sl);
           your(v);

           my(v);
           your(sl);
         }

Если классы set и set_handle разрабатывались совместно,легко реализовать подсчет числа создаваемых множеств:

         class set {
         friend class set_handle;
         protected:
           int handle_count;
         public:
           virtual void insert(T*) = 0;
           virtual void remove(T*) = 0;

           virtual int is_member(T*) = 0;

           virtual T* first() = 0;
           virtual T* next() = 0;

           set() : handle_count(0) { }
         }; 

Чтобы подсчитать число объектов данного типа set, в управляющем классе нужно увеличивать или уменьшать значение счетчика
set_handle:

         class set_handle {
           set* rep;
         public:
           set* operator->() { return rep; }

         set_handle(set* pp)
            : rep(pp) { pp->handle_count++; }
         set_handle(const set_handle& r)
            : rep(r.rep) { rep->handle_count++; }

         set_handle& operator=(const set_handle& r)
         {
            rep->handle_count++;
            if (--rep->handle_count == 0) delete rep;
            rep = r.rep;
            return *this;
          }

          ~set_handle()
             { if (--rep->handle_count == 0) delete rep; }
        }; 

Если все обращения к классу set обязательно идут через set_handle, пользователь может не беспокоиться о распределении памяти под объекты типа set.

На практике иногда приходится извлекать указатель на содержательную часть из управляющего класса и пользоваться непосредственно им. Можно, например, передать такой указатель функции, которая ничего не знает об управляющем классе. Если функция не уничтожает объект, на который она получила указатель, и если она не сохраняет указатель для дальнейшего использования после возврата, никаких ошибок быть не должно. Может оказаться полезным переключение управляющего класса на другую содержательную часть:

          class set_handle {
            set* rep;
          public:
            // ...

          set* get_rep() { return rep; }

          void bind(set* pp)
          {
            pp->handle_count++;
            if (--rep->handle_count == 0) delete rep;
            rep = pp;
          }
       }; 

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

Естественно задавать управляющий класс как шаблон типа:

        template<class T> class handle {
           T* rep;
        public:
           T* operator->() { return rep; }
           // ...
        }; 

Но при таком подходе требуется взаимодействие между управляющим и "управляемым" классами. Если управляющий и управляемые классы разрабатываются совместно, например, в процессе создания библиотеки, то это может быть допустимо. Однако, существуют и другие решения ($$13.10).

За счет перегрузки операции -> управляющий класс получает возможность контроля и выполнения каких-то операций при каждом обращении к объекту. Например, можно вести подсчет частоты использования объектов через управляющий класс:

        template<class T>
           class Xhandle {
             T* rep;
             int count;
           public:
             T* operator->() { count++; return rep; }

             // ...
           }; 

Нужна более сложная техника, если требуется выполнять операции как перед, так и после обращения к объекту. Например, может потребоваться множество с блокировкой при выполнении операций добавления к множеству и удаления из него. Здесь, по сути, в управляющем классе приходится дублировать интерфейс с объектами содержательной части:

           class set_controller {
             set* rep;
             // ...
           public:

             lock();
             unlock();

             virtual void insert(T* p)
               { lock(); rep->insert(p); unlock(); }
             virtual void remove(T* p)
               { lock(); rep->remove(p); unlock(); }

             virtual int is_member(T* p)
               { return rep->is_member(p); }

             virtual T* first() { return rep->first(); }
             virtual T* next() { return rep->next(); }

             // ...
           }; 

Писать функции-переходники для всего интерфейса утомительно (а значит могут появляться ошибки), но не трудно и это не ухудшает характеристик  программы.

Заметим, что не все функции из set следует блокировать. Как показывает опыт автора, типичный случай, когда операции до и после обращения к объекту надо выполнять не для всех, а только для некоторых функций-членов. Блокировка всех операций, как это делается в мониторах некоторых операционных систем, является избыточной и может существенно ухудшить параллельный режим выполнения.

Переопределив все функции интерфейса в управляющем классе, мы получили по сравнению с приемом перегрузки операции ->, то преимущество, что теперь можно строить производные от set_controller классы. К сожалению, мы можем потерять и некоторые достоинства управляющего класса, если к производным классам будут добавляться члены, представляющие данные. Можно сказать, что программный объем, который разделяется между управляемыми классами уменьшается по мере роста программного объема управляющего класса.

13.10 Управление памятью

При проектировании библиотеки или просто программы с большим временем счета один из ключевых вопросов связан с управлением памятью. В общем случае создатель библиотеки не знает, в каком окружении она будет работать. Будет ли там ресурс памяти настолько критичен, что ее нехватка станет серьезной проблемой, или же серьезной помехой станут накладные расходы, связанные с управлением памятью? Один из  основных вопросов управления памятью можно сформулировать так: если функция f() передает или возвращает указатель на объект, то кто должен уничтожать этот объект?  Необходимо ответить и на связанный с ним вопрос: в какой момент объект может быть уничтожен? Ответы на эти вопросы особенно важны для создателей и пользователей таких контейнеров, как списки, массивы и ассоциативные массивы. С точки зрения создателя библиотеки идеальными будут ответы: "Система" и "В тот момент, когда объект больше никто не использует". Когда система уничтожает объект, обычно говорят, что она занимается сборкой мусора, а та часть системы, которая определяет, что объект больше никем не используется, и уничтожает его, называется сборщиком мусора.

К сожалению, использование сборщика мусора может повлечь за собой накладные расходы на время счета и память, прерывания полезных функций, определенную аппаратную поддержку, трудности связывания частей программы на разных языках или просто усложнение системы. Многие пользователи не могут позволить себе этого.Ь Ь Говорят, что программисты на Лиспе знают, насколько важно управление памятью, и поэтому не могут отдать его пользователю. Программисты на С тоже знают, насколько важно управление памятью, и поэтому не могут оставить его системе. Поэтому в большинстве программ на С++ не приходится рассчитывать на сборщик мусора и нужно предложить свою стратегию размещения объектов в свободной памяти, не обращаясь к системе. Но реализации С++ со сборщиком мусора все-таки существуют.

Рассмотрим самую простую схему управления памятью для программ на С++. Для этого заменим operator new() на тривиальную функцию размещения, а operator delete() - на пустую функцию:

        inline size_t align(size_t s)
        /*
           Даже в простой функции размещения нужно
           выравнивание памяти, чтобы на объект
           можно было настроить указатель
           произвольного типа
        */
        {
          union Word { void* p; long double d; long l; }

          int x = s + sizeof(Word) - 1;
          x -= x%sizeof(Word);
          return x;
        }

        static void* freep; // настроим start на свободную память

        void* operator  new(size_t s) // простая линейная функция размещения
        {
          void* p = freep;
          s = align(s);
          freep += s;
          return p;
        }

        void operator delete(void*) { }  // пусто 

Если память бесконечна, то наше решение дает сборщик мусора без всяких сложностей и накладных расходов. Такой подход не применим для библиотек, когда заранее неизвестно, каким образом будет использоваться память, и когда программа, пользующаяся библиотекой, будет иметь большое время счета. Такой способ выделения памяти идеально подходит для программ, которым требуется ограниченный объем памяти или объем, пропорциональный размеру входного потока данных.

13.10.1 Сборщик мусора

Сборку мусора можно рассматривать как моделирование бесконечной памяти на памяти ограниченного размера. Помня об этом, можно ответить на типичный вопрос: должен ли сборщик мусора вызывать деструктор для тех объектов, память которых он использует? Правильный ответ - нет, поскольку, если размещенный в свободной памяти объект не был удален, то он не будет и уничтожен. Исходя из этого, операцию
delete можно рассматривать как запрос на вызов деструктора (и еще это - сообщение системе, что память объекта можно использовать). Но как быть, если действительно требуется уничтожить размещенный в свободной памяти объект, который не был удален? Заметим, что для статических и автоматических объектов такой вопрос не встает, - деструкторы для них неявно вызываются всегда. Далее, уничтожение объекта "во время сборки мусора" по сути является операцией с непредсказуемым результатом. Она может совершиться в любое время между последним использованием объекта и "концом программы"Ь, а значит, в каком состоянии будет программа в этот момент неизвестно. Ь Здесь использованы кавычки, потому что трудно точно определить, что такое конец программы. (прим. перев.) Трудно правильно запрограммировать такие операции и они не так полезны, как кажется.

Задачу уничтожения объектов, если время этой операции точно не задано, можно решить с помощью программы обслуживания заявок на уничтожение. Назовем ее сервером заявок. Если объект необходимо уничтожить в конце программы, то надо записать в глобальный ассоциативный массив его адрес и указатель на функцию "очистки". Если объект удален явной операцией, заявка аннулируется. При уничтожении самого сервера (в конце программы) вызываются функции очистки для всех оставшихся заявок. Это решение подходит и для сборки мусора, поскольку мы рассматриваем ее как моделирование бесконечной памяти. Для сборщика мусора нужно выбрать одно из двух решений: либо удалять объект, когда единственной оставшейся ссылкой на него будет ссылка, находящаяся в массиве самого сервера, либо (стандартное решение) не удалять объект до конца программы, поскольку все-таки ссылка на него есть.

Сервер заявок можно реализовать как ассоциативный массив ($$8.8):

         class Register {
             Map<void*, void (*) (void*)> m;
         public:
             insert(void* po, void(*pf)()) { m[po]=pf; }
             remove(void* po) { m.remove(po); }
         };

         Register cleanup_register; 

Класс, постоянно обращающийся к серверу, может выглядеть так:

         class X {
           // ...
           static void cleanup(void*);
         public:


          X()
          {
            cleanup_register.insert(this,&cleanup);
            // ...
          }


          ~X() { cleanup(this); }

           // ...
         };

         void X::cleanup(void* pv)
         {
           X* px = (X*)pv;
           cleanup_register.remove(pv);
           // очистка
         }

 Чтобы в классе Register не иметь дела с типами, мы использовали статическую функцию-член с указателем типа void*.

13.10.2 Контейнеры и удаление

Допустим, что у нас нет бесконечной памяти и сборщика мусора. На какие средства управления памятью может рассчитывать создатель контейнера, например, класса Vector? Для случая таких простых элементов, как int, очевидно, надо просто копировать их в контейнер. Столь же очевидно, что для других типов, таких, как абстрактный класс Shape, в контейнере следует хранить указатель. Создатель библиотеки должен предусмотреть оба варианта. Приведем набросок очевидного решения:

           template<class T> Vector {
              T* p;
              int sz;
           public:
              Vector(int s) { p = new T[sz=s]; }
              // ...
           }; 

Если пользователь не будет заносить в контейнер вместо указателей на объекты сами объекты типа Shape, то это решение подходит для обоих вариантов.

           Vector<Shape*> vsp(200);  // нормально
           Vector<Shape> vs(200);    // ошибка при трансляции 

К счастью, транслятор отслеживает попытку создать массив объектов абстрактного базового класса Shape.

Однако, если используются указатели, создатель библиотеки и пользователь должны договориться, кто будет удалять хранимые в контейнере объекты. Рассмотрим пример:

           void f()
                // противоречивое использование средств
                // управления памятью
           {
             Vector<Shape*> v(10);
             Circle* cp = new Circle;
             v[0] = cp;
             v[1] = new Triangle;
             Square s;
             v[2] = &s;
             delete cp; // не удаляет объекты, на которые настроены
                        // указатели, находящиеся в контейнере
            }

Если использовать реализацию класса Vector из $$1.4.3, объект Triangle в этом примере навсегда останется в подвешенном состоянии (на него нет указателей), если только нет сборщика мусора. Главное в управлении памятью это - это корректность. Рассмотрим такой пример:

            void g()
            // корректное использование средств управления памятью
            {
              Vector<Shape*> v(10);
              Circle* cp = new Circle;
              v[0] = cp;
              v[1] = new Triangle;
              Square s;
              v[2] = &s;
              delete cp;
              delete v[1];
            }

Рассмотрим теперь такой векторный класс,который следит за удалением занесенных в него указателей:

           template<class T> MVector {
             T* p;
             int sz;
           public:
             MVector(int s);
             ~MVector();
             // ...
           };

           template<class T> MVector<T>::MVector(int s)
           {
             // проверка s
             p = new T[sz=s];
             for (int i = 0; i<s; i++) p[i] = 0;
           }

           template<class T> MVector<T>::~MVector()
           {
             for (int i = 0; i<s; i++) delete p[i];
             delete p;
           }

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

           void h()
           // корректное использование средств управления памятью
          {
             MVector<Shape*> v(10);
             Circle* cp = new circle();
             v[0] = cp;
             v[1] = new Triangle;
             Square s;
             v[2] = &s;
             v[2] = 0;  // предотвращает удаление s

             // все оставшиеся указатели
             // автоматически удаляются при выходе
           }

Естественно, такое решение годится только для контейнеров, в которых не содержатся копии объектов, а для класса Map ($$8.8), например, оно не годится. Здесь приведен простой вариант деструктора для MVector, но содержится ошибка, поскольку один и тот же указатель, дважды занесенный в контейнер, будет удаляться тоже два раза.

Построение и уничтожение таких контейнеров, которые следят за удалением содержащихся в них объектах, довольно дорогостоящая операция. Копирование же этих контейнеров следует запретить или, по крайней мере, сильно ограничить (действительно, кто будет отвечать за удаление контейнер или его копия?):

          template<class T> MVector {
             // ...
          private:
             MVector(const MVector&); //предотвращает копирование
             MVector& operator=(const MVector&); //то же самое
             // ...
          }; 

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

Часто бывает полезно уменьшить число указателей, за которыми должен следить пользователь. Действительно, намного проще следить за 100 объектами первого уровня, которые, в свою очередь, управляют
1000 объектов нулевого уровня, чем непосредственно работать с 1100 объектами. Собственно, приведенные в этом разделе приемы, как и другие приемы, используемые для управления памятью, сводятся к стандартизации и универсализации за счет применения  конструкторов и деструкторов. Это позволяет свести задачу управления памятью для практически невообразимого числа объектов, скажем 100 000, до вполне управляемого числа, скажем 100.

Можно ли  таким образом определить класс контейнера, чтобы программист, создающий объект типа контейнера, мог выбрать стратегию управления памятью из нескольких возможных, хотя определен контейнер только одного типа? Если это возможно, то будет ли оправдано? На второй вопрос ответ положительный, поскольку большинство функций в системе вообще не должны заботиться о распределении памяти. Существование же нескольких разных типов для каждого контейнерного класса является для пользователя ненужным усложнением. В библиотеке должен быть или один вид контейнеров (Vector или MVector), или же оба, но представленные как варианты одного типа, например:

           template<class T> PVector {
              T** p;
              int sz;
              int managed;
           public:
              PVector(int s, int managed = 0 );
              ~PVector();
              // ...
           };

           template<class T> PVector<T>::PVector(int s, int m)
           {
             // проверка s
             p = new T*[sz=s];
             if (managed = m)
                for (int i = 0; i<s; i++) p[i] = 0;
           }

           template<class T> PVector<T>::~PVector()
           {
             if (managed) {
                for (int i = 0; i<s; i++) delete p[i];
             }
             delete p;
           }

Примером класса, который может предложить библиотека для облегчения управления памятью, является управляющий класс из $$13.9. Раз в управляющем классе ведется подсчет ссылок на него, можно спокойно передавать объект этого класса, не думая о том, кто будет удалять доступные через него объекты. Это сделает сам объект управляющего класса. Но такой подход требует, чтобы в управляемых объектах было поле для подсчета числа использований. Введя дополнительный объект, можно просто снять это жесткое требование:

           template<class T>
           class Handle {
              T* rep;
              int* pcount;
           public:
              T* operator->() { return rep; }

              Handle(const T* pp)
                : rep(pp), pcount(new int) { (*pcount) = 0; }
              Handle(const Handle& r)
                : rep(r.rep), pcount(r.count) { (*pcount)++; }

              void bind(const Handle& r)
              {
                if (rep == r.rep) return;
                if (--(*pcount) == 0) { delete rep; delete pcount; }
                rep = r.rep;
                pcount = r.pcount;
                (*pcount)++;
              }

              Handle& operator=(const Handle& r)
              {
                bind(r);
                return *this;
              }

              ~Handle()
              {
                if (--(*pcount) == 0) { delete rep; delete pcount; }
              }
            };

13.10.3 Функции размещения и освобождения

Во всех приведенных примерах память рассматривалась как нечто данное. Однако, обычная функция общего назначения для распределения свободной памяти оказывается до удивления менее эффективной, чем функция размещения специального назначения. Вырожденным случаем таких функций можно считать приведенный пример с размещением в "бесконечной" памяти и с пустой функцией освобождения. В библиотеке могут быть более содержательные функции размещения, и бывает, что с их помощью удается удвоить скорость выполнения программы. Но прежде, чем пытаться с их помощью оптимизировать программу, запустите для нее профилировщик, чтобы выявить накладные расходы, связанные с выделением памяти.

В разделах $$5.5.6 и $$6.7 было показано как с помощью определения функций X::operator new() и X::operator delete() можно использовать функцию размещения для объектов класса X. Здесь есть определенная трудность. Для двух классов X и Y функции размещения могут быть настолько сходными, что желательно иметь одну такую функцию. Иными словами, желательно иметь в библиотеке такой класс, который предоставляет функции размещения и освобождения, пригодные для размещения объектов данного класса. Если такой класс есть, то функции размещения и освобождения для данного класса получаются за счет привязки к нему общих функций размещения и освобождения:

           class X {
              static Pool my_pool;
              // ...
           public:
              // ...
             void* operator new(size_t) { return my_pool.alloc(); }
             void operator delete(void* p) { my_pool.free(p); }
           };

           Pool X::my_pool(sizeof(X)); 

С помощью класса Pool память распределяется блоками одного размера. В приведенном примере объект my_pool отводит память блоками размером sizeof(X).

Составляется описание класса X и используется Pool с учетом оптимизации скорости программы и компактности представления. Обратите внимание, что размер выделяемых блоков памяти является для класса "встроенным", поэтому задающий размер параметр функции X::operator new() не используется. Используется вариант функции X::operator delete() без параметра. Если класс Y является производным класса X, и
sizeof(Y)>sizeof(X), то для класса Y должны быть свои функции размещения и освобождения. Наследование функций класса X приведет к катастрофе. К счастью, задать такие функции для Y очень просто.

Класс Pool предоставляет связанный список элементов требуемого размера. Элементы выделяются из блока памяти фиксированного размера и по мере надобности запрашиваются новые блоки памяти. Элементы группируются большими блоками, чтобы минимизировать число обращений за памятью к функции размещения общего назначения. До тех пор пока не будет уничтожен сам объект PooL, память никогда не возвращается функции размещения общего назначения.

Приведем описание класса Pool:

         class Pool {

            struct Link { Link* next; }

            const unsigned esize;
            Link* head;

            Pool(Pool&);            // защита от копирования
            void operator= (Pool&); // защита от копирования
            void grow();
          public:
            Pool(unsigned n);
            ~Pool();

            void* alloc();
            void free(void* b);
          };

          inline void* Pool::alloc()
          {
            if (head==0) grow();
            Link* p = head;
            head = p->next;
            return p;
          }

          inline void Pool::free(void* b)
          {
            Link* p = (Link*) b;
            p->next = head;
            head = p;
          }

Приведенные описания логично поместить в заголовочный файл Pool.h. Следующие определения могут находиться в любом месте программе и завершают наш пример. Объект Pool должен инициализироваться конструктором:

          Pool::Pool(unsigned sz)
            : esize(sz)
          {
            head = 0;
          }

Функция Pool::grow() будет связывать все элементы в список квантов свободной памяти head, образуя из них новый блок. Определения остальных функций-членов оставлены в качестве упражнений 5 и 6 в $$13.11.

          void Pool::grow()
          {
            const int overhead = 12;
            const int chunk_size = 8*1024-overhead;
            const int nelem = (chunk_size-esize)/esize;

            char* start = new char[chunk_size];
            char* last = &start[(nelem-1)*esize];

            for (char* p = start; p<last; p+=esize)
                ((Link*)p)->next = ((Link*)p)+1;
            ((Link*)last)->next = 0;
            head = (Link*)start;
          }

13.11 Упражнения

1. (*3) Завершите определения функций-членов класса Type_info.
2. (*3) Предложите такую структуру объекта Type_info, чтобы функция
   Type_info::get_info() стала лишней, и перепишите с учетом этого функции-члены Type_info.
3. (*2.5) Насколько наглядно вы сможете записать примеры с Dialog_box, не используя макроопределения (а также расширения языка)? Насколько наглядно вам удастся записать их, используя расширения языка?
4. (*4) Исследуйте две широко распространенные библиотеки. Классифицируйте все библиотечные классы, разбив их на: конкретные типы, абстрактные типы, узловые классы, управляющие классы и интерфейсные классы. Используются ли абстрактные узловые классы и конкретные узловые классы? Можно ли предложить более подходящее разбиение классов этих библиотек? Используется ли обширный интерфейс? Какие имеются средства  динамической информации о типе  (если они есть)? Какова стратегия управления памятью?

5. (*3) Определите шаблонный вариант класса Pool из $$13.10.3. Пусть размер выделяемого элемента памяти будет параметром шаблона типа, а не конструктора.
6. (*2.5) Усовершенствуйте шаблон типа Pool из предыдущего упражнения так, чтобы некоторые элементы размещались во время работы конструктора. Сформулируйте в чем будет проблема переносимости, если использовать Pool с типом элементов char, покажите как ее устранить.
7. (*3) Если ваша версия С++ прямо не поддерживает динамические запросы о типе, обратитесь к своей основной библиотеке. Реализован ли там механизм динамических запросов о типе? Если это так, задайте операции из $$13.5 как надстройку над этим механизмом.
8. (*2.5) Определите такой строковый класс, в котором нет никакого динамического контроля, и второй производный от него строковый класс, который только проводит динамический контроль и обращается к первому. Укажите плюсы и минусы такого решения по сравнению с решением,в котором делается выборочный динамический контроль, сравните с подходом, использующим инварианты, как было предложено в $$12.2.7.1. Насколько можно совмещать эти подходы?
9. (*4) Определите класс Storable как абстрактный базовый класс с виртуальными функциями writeout() и readin(). Для простоты допустим, что для задания нужного адресного пространства достаточно строки символов. С помощью класса Storable реализуйте обмен объектами с диском. Проверьте его на объектах нескольких классов по своему усмотрению.
10.(*4) Определите базовый класс Persistent с операциями save()
   и nosave(), который будет проверять, что деструктор создал объект в определенной памяти. Какие еще полезные операции можно предложить? Проверьте класс Persistent на нескольких классах по своему выбору.
   Является ли класс Persistent узловым классом, конкретным или абстрактным типом? Аргументируйте ответ.
11.(*3) Составьте только описание класса stack, который реализует стек с помощью операций create() (создать стек), delete()
   (уничтожить стек), push() (записать в стек) и pop() (читать из стека). Используйте только статические члены. Для привязки и обозначения стеков определите класс id. Гарантируйте, что пользователь сможет копировать объекты stack::id, но не сможет работать с ними иным способом. Сравните это определение стека с классом stack из $$8.2.
12.(*3) Составьте описание класса stack, который является абстрактным типом ($$13.3). Предложите две различные реализации для интерфейса, заданного stack. Напишите небольшую программу, работающую с этими классами. Сравните это решение с классами, определяющими стек, из предыдущего упражнения и из $$8.2.
13.(*3) Составьте такое описание класса stack, для которого можно в динамике менять реализацию. Подсказка: "Всякую задачу можно решить, введя еще одну косвенность".
14.(*3.5) Определите класс Oper, содержащий идентификатор (некоторого подходящего типа) и операцию (некоторый указатель на функцию).

Определите класс cat_object, содержащий список объектов Oper и объект типа void*. Задайте в классе cat_object операции:
   add_oper(), которая добавляет объект к списку; remove_oper(id), которая удаляет из списка объект Oper c идентификатором id;
   operator() (id,arg), которая вызывает функцию из объекта Oper c
   идентификатором id. Реализуйте с помощью класса cat_object
   стек объектов Oper. Напишите небольшую программу, работающую с этими классами.
15.(*3) Определите шаблон типа Object, служащий базовым классом для cat_object. С помощью Object реализуйте стек для объектов класса String. Напишите небольшую программу, использующую этот шаблон типа.
16.(*3) Определите вариант класса Object под именем Class, в котором объекты с одинаковым идентификатором имеют общий список операций.

Напишите небольшую программу, использующую этот шаблон типа.
17.(*3) Определите шаблон типа Stack, который задает традиционный и надежный интерфейс со стеком, реализуемым объектом шаблона типа Object. Сравните это определение стека с классами, задающими стек, из предыдущих упражнений. Напишите небольшую программу, использующую этот шаблон типа.