лее важна и чаще достижима для реализаций, чем для интерфейсов. Отметим, что класс определяет три интерфейса: 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 Информация о типе В С++ нет иного стандартного средства получения динамической информации о типе, кроме вызовов виртуальных функцийЬ. Ь Хотя было сделано несколько предложений по расширению С++ в этом направлении. Смоделировать такое средство довольно просто и в большинстве больших библиотек есть возможности динамических запросов о типе. Здесь предлагается решение, обладающее тем полезным свойством, что объем информации о типе можно произвольно расширять. Его можно реализовать с помощью вызовов виртуальных функций, и оно может входить в расширенные реализации С++. Достаточно удобный интерфейс с люб