Главная страница
Навигация по странице:

  • 17.4.1. Конструктор базового класса

  • 17.4.2. Конструктор производного класса

  • Query BinaryQuery AndQuery OrQuery Рис. 17.2. Альтернативная иерархия классов

  • Язык программирования C++. Вводный курс. С для начинающих


    Скачать 5.41 Mb.
    НазваниеС для начинающих
    Дата24.08.2022
    Размер5.41 Mb.
    Формат файлаpdf
    Имя файлаЯзык программирования C++. Вводный курс.pdf
    ТипДокументы
    #652350
    страница81 из 93
    1   ...   77   78   79   80   81   82   83   84   ...   93
    867
    У объекта NameQuery есть доступ к защищенным членам только одного объекта Query – подобъекта самого себя. Прямое обращение к ним из производного класса осуществляется через неявный указатель this (см. раздел 13.4). Первая реакция на ошибку компиляции – переписать функцию compare() с использованием открытой функции-члена location()
    :
    }
    Однако проблема заключается в неправильном проектировании. Поскольку _loc – это член базового класса Query, то место compare() среди членов базового, а не производного класса. Во многих случаях подобные проблемы могут быть решены путем переноса некоторой операции в тот класс, где находится недоступный член, как в приведенном примере.
    Этот вид ограничения доступа не распространяется на доступ изнутри класса к другим объектам того же класса:
    }
    Производный класс может напрямую обращаться к защищенным членам базового в других объектах того же класса, что и он сам, равно как и к защищенным и закрытым членам других объектов своего класса.
    Рассмотрим инициализацию указателя на базовый Query адресом объекта производного
    NameQuery
    :
    Query *pb = new NameQuery( "sprite" );
    При вызове виртуальной функции, определенной в базовом классе Query, например: pb->eval(); // вызывается NameQuery::eval() bool
    NameQuery:: compare( const Query *pquery )
    {
    // правильно: защищенный член подобъекта Query int myMatches = _loc.size();
    // правильно: используется открытый метод доступа int itsMatches = pquery->locations()->size(); return myMatches == itsMatches; bool
    NameQuery:: compare( const NameQuery *pname )
    { int myMatches = _loc.size(); // правильно int itsMatches = name->_loc.size(); // тоже правильно return myMatches == itsMatches;

    С++ для начинающих
    868
    вызывается функция из NameQuery. За исключением вызова виртуальной функции, объявленной в Query и переопределенной в NameQuery, другого способа напрямую добраться до членов класса NameQuery через указатель pb не существует:
    (a) если в Query и NameQuery объявлены некоторые невиртуальные функции- члены с одинаковым именем, то через pb всегда вызывается экземпляр из Query;
    (b) если в Query и NameQuery объявлены одноименные члены, то через pb обращение происходит к члену класса Query;
    (c) если в NameQuery имеется виртуальная функция, отсутствующая в Query, скажем suffix(), то попытка вызвать ее через pb приводит к ошибке компиляции: pb->suffix();

    Обращение к члену или невиртуальной функции-члену класса NameQuery через pb тоже вызывает ошибку компиляции: pb->_name;
    Квалификация имени члена в этом случае не помогает: pb->NameQuery::_name;
    В C++ с помощью указателя на базовый класс можно работать только с данными и функциями-членами, включая виртуальные, которые объявлены (или унаследованы) в самом этом классе, независимо от того, какой фактический объект адресуется указателем.
    Объявление функции-члена виртуальной откладывает решение вопроса о том, какой экземпляр функции вызвать, до выяснения (во время выполнения программы) фактического типа объекта, адресуемого pb.
    Такой подход может показаться недостаточно гибким, но у него есть два весомых преимущества:

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

    механизм виртуализации можно оптимизировать. Часто вызов такой функции оказывается не дороже, чем косвенный вызов функции по указателю (детально этот вопрос рассмотрен в [LIPPMAN96a]).
    В базовом классе Query определен статический член _text_file: static vector *_text_file;
    // ошибка: suffix() - не член класса Query
    // ошибка: _name - не член класса Query
    // ошибка: у класса Query нет базового класса NameQuery

    С++ для начинающих
    869
    Создается ли при порождении класса NameQuery второй экземпляр _text_file, уникальный именно для него? Нет. Все объекты производного класса ссылаются на тот же самый, единственный разделяемый статический член. Сколько бы ни было производных классов, существует лишь один экземпляр _text_file. Можно обратиться к нему через объект производного класса с помощью синтаксиса доступа: nameQueryObject._text_file; // правильно
    Наконец, если производный класс хочет получить доступ к закрытым членам своего базового класса напрямую, то он должен быть объявлен другом базового:
    };
    Теперь объект NameQuery может обращаться не только к закрытым членам своего подобъекта, соответствующего базовому классу, но и к закрытым и защищенным членам любых объектов Query.
    А если мы произведем от NameQuery класс StringQuery? Он будет поддерживать сокращенную форму запроса AndQuery, и вместо beautiful && fiery && bird можно будет написать:
    "beautiful fiery bird"
    Унаследует ли StringQuery от класса NameQuery дружественные отношения с Query?
    Нет. Отношение дружественности не наследуется. Производный класс не становится другом класса, который объявил своим другом один из базовых. Если производному классу требуется стать другом одного или более классов, то эти классы должны предоставить ему соответствующие права явно. Например, у класса StringQuery нет никаких специальных прав доступа по отношению к Query. Если расширенный доступ необходим, то Query должен разрешить его явно.
    Упражнение 17.6
    Даны следующие определения базового и производных классов: class Query { friend class NameQuery; public:
    // ...

    С++ для начинающих
    870
    };
    Исправьте ошибки в каждом из следующих фрагментов кода:
    (b) void Derived::foobar() { _bar = 1024; }
    { return _foo_bar == pb->_foo_bar; }
    17.4.
    Конструирование базового и производного классов
    Напомним, что объект производного класса состоит из одного или более подобъектов, соответствующих базовым классам, и части, относящейся к самому производному.
    Например, NameQuery состоит из подобъекта Query и объекта-члена string. Для иллюстрации поведения конструктора производного класса введем еще один член встроенного типа:
    };
    Если _present установлен в false, то слово _name в тексте отсутствует. class Base { public: foo( int );
    // ... protected: int _bar; double _foo_bar;
    }; class Derived : public Base { public: foo( string ); bool bar( Base *pb ); void foobar();
    // ... protected: string _bar;
    Derived d; d.foo( 1024 );
    (c) bool Derived::bar( Base *pb ) class NameQuery : public Query { public:
    // ... protected: bool _present; string _name;

    С++ для начинающих
    871
    Рассмотрим случай, когда в NameQuery конструктор не определен. Тогда при определении объекта этого класса
    NameQuery nq; по очереди вызывается конструктор по умолчанию Query, а затем конструктор по умолчанию класса string (ассоциированный с объектом _name). Член _present остается неинициализированным, что потенциально может служить источником ошибок. Чтобы инициализировать его, можно так определить конструктор по умолчанию для класса
    NameQuery
    : inline NameQuery::NameQuery() { _present = false; }
    Теперь при определении nq вызываются три конструктора по умолчанию: для базового класса Query, для класса string при инициализации члена _name и для класса
    NameQuery
    А как передать аргумент конструктору базового класса Query? Ответить на этот вопрос можно, рассуждая по аналогии.
    Для передачи одного или более аргументов конструктору объекта-члена мы используем список инициализации членов (здесь можно также задать начальные значения членам, не являющимся объектами классов; подробности см. в разделе 14.5):
    {}
    Для передачи одного или более аргументов конструктору базового класса также разрешается использовать список инициализации членов. В следующем примере мы передаем конструктору string аргумент name, а конструктору базового класса Query – объект, адресованный указателем ploc:
    {}
    Хотя Query помещен в список инициализации вторым, его конструктор всегда вызывается раньше конструктора для _name. Порядок их вызова следующий:
    Конструктор базового класса. Если базовых классов несколько, то конструкторы вызываются в порядке их следования в списке базовых классов, а не в порядке появления в списке инициализации. (О множественном наследовании в этой связи мы поговорим в главе 18.)
    Конструктор объекта-члена. Если в классе есть несколько таких членов, то конструкторы вызываются в порядке их объявления в классе, а не в порядке появления в списке инициализации (подробнее см. раздел 14.5). inline NameQuery::
    NameQuery( const string &name )
    : _name( name ), _present( false ) inline NameQuery::
    NameQuery( const string &name, vector *ploc )
    : _name( name ), Query( *ploc ), _present( true )

    С++ для начинающих
    872
    Конструктор производного класса.
    Конструктор производного класса должен стремиться передать значение члена базового класса подходящему конструктору того же класса, а не присваивать его напрямую. В противном случае реализации двух классов становятся сильно связанными и тогда изменить или расширить реализацию базового будет затруднительно. (Ответственность разработчика базового класса ограничивается предоставлением подходящего множества конструкторов.)
    В оставшейся части этого раздела мы последовательно изучим конструктор базового класса и конструкторы четырех производных от него, а после этого рассмотрим альтернативный дизайн иерархии классов Query, чтобы познакомиться с иерархиями глубиной больше двух. В конце раздела речь пойдет о деструкторах классов.
    17.4.1.
    Конструктор базового класса
    В нашем базовом классе объявлено два нестатических члена: _solution и _loc:
    };
    Конструктор Query по умолчанию должен явно инициализировать только член
    _solution
    . Для инициализации _loc автоматически вызывается конструктор класса vector
    . Вот реализация нашего конструктора: inline Query::Query(): _solution( 0 ) {}
    В Query нам понадобится еще один конструктор, принимающий ссылку на вектор позиций:
    {}
    Он вызывается только из конструктора NameQuery, когда объект этого класса используется для представления указанного в запросе слова. В таком случае передается предварительно подготовленный для него вектор позиций. Остальные три производных класса вычисляют свои векторы позиций в соответствующей функции-члене eval(). (В следующем подразделе мы покажем, как это делается. Реализации функций-членов eval()
    приведены в разделе 17.5.)
    Какой уровень доступа обеспечить для конструкторов? Мы не хотим объявлять их открытыми, так как предполагается, что Query будет существовать в программе только в class Query { public:
    // ... protected: set *_solution; vector _loc;
    // ... inline
    Query::
    Query( const vector< locaton > &loc )
    : _solution( 0 ), _loc( loc )

    С++ для начинающих
    873
    виде подобъекта в составе объектов производных от него классов. Поэтому мы объявим конструктор не открытым, а защищенным:
    };
    Ко второму конструктору класса Query предъявляются еще более жесткие требования: он не только должен конструировать Query в виде подобъекта производного класса, но этот производный класс должен к тому же быть NameQuery. Можно объявить конструктор закрытым, а NameQuery сделать другом класса Query. (В предыдущем разделе мы говорили, что производный класс может получить доступ только к открытым и защищенным членам базового. Поэтому любая попытка вызвать второй конструктор из классов AndQuery, OrQuery или NotQuery приведет к ошибке компиляции.)
    };
    (Необходимость второго конструктора спорна; вероятно, правильнее заполнить _loc в функции eval() класса NameQuery. Однако принятый подход в большей степени отвечает нашей цели проиллюстрировать использование конструктора базового класса.)
    17.4.2.
    Конструктор производного класса
    В классе NameQuery также определены два конструктора. Они объявлены открытыми, поскольку ожидается, что в приложении будут создаваться объекты этого класса:
    }; class Query { public:
    // ... protected:
    Query();
    // ... class Query { public:
    // ... protected:
    Query();
    // ... private: explicit Query( const vector& ); class NameQuery : public Query { public: explicit NameQuery( const string& );
    NameQuery( const string&, const vector* );
    // ... protected:
    // ...

    С++ для начинающих
    874
    Конструктор с одним параметром принимает в качестве аргумента строку. Она передается конструктору объекта типа string, который вызывается для инициализации члена _name. Конструктор по умолчанию базового класса Query вызывается неявно:
    {}
    Конструктор с двумя параметрами также принимает строку в качестве одного из них.
    Второй его параметр – это указатель на вектор позиций. Он передается закрытому конструктору базового класса Query. (Обратите внимание, что _present нам больше не нужен, и мы исключили его из числа членов NameQuery.)
    {}
    Конструкторы можно использовать так: else pname = new NameQuery( title );
    В каждом из классов NotQuery, OrQuery и AndQuery определено по одному конструктору, каждый из которых вызывает конструктор базового класса неявно:
    {} inline
    NameQuery::
    NameQuery( const string &name )
    // Query::Query() вызывается неявно
    : _name( name ) inline
    NameQuery::
    NameQuery( const string &name, vector *ploc )
    : _name( name ), Query( *ploc ) string title( "Alice" );
    NameQuery *pname;
    // проверим, встречается ли "Alice" в отображении слов
    // если да, получить ассоциированный с ним вектор позиций if ( vector *ploc = retrieve_location( title )) pname = new NameQuery( title, ploc ); inline NotQuery::
    NotQuery( Query *op = 0 ) : _op( op ) {} inline OrQuery::
    OrQuery( Query *lop = 0, Query *rop = 0 )
    : _lop( lop ), _rop( rop )
    {} inline AndQuery::
    AndQuery( Query *lop = 0, Query *rop = 0 )
    : _lop( lop ), _rop( rop )

    С++ для начинающих
    875
    (В разделе 17.7 мы построим объекты каждого из производных классов для представления различных запросов пользователя.)
    17.4.3.
    Альтернативная иерархия классов
    Хотя наша иерархия классов Query представляется вполне приемлемой, она вовсе не является единственно возможной. Например, AndQuery и OrQuery связаны с бинарной операцией, поэтому они в какой-то степени дублируют друг друга. Можно вынести все данные и функции-члены, общие для них, в абстрактный базовый класс BinaryQuery.
    Поддерево новой иерархии Query изображено на рисунке 17.2:
    Query
    BinaryQuery
    AndQuery OrQuery
    Рис. 17.2. Альтернативная иерархия классов
    Класс BinaryQuery – это тоже абстрактный базовый класс, следовательно, его фактические объекты в приложении не появляются. Разумной реализации eval() для него предложить нельзя, поэтому чисто виртуальная функция, объявленная в Query, в классе BinaryQuery останется чисто виртуальной. (Подробнее о таких функциях мы поговорим в разделе 17.5.)
    Две функции-члена для доступа – lop() и rop(), общие для обоих классов, переносятся выше, в BinaryQuery, и определяются как нестатические встроенные. Аналогично два члена _lop и _rop, объявленные в обоих классах, также переносятся в BinaryQuery и становятся нестатическими и защищенными. Открытые конструкторы обоих производных классов объединяются в один защищенный конструктор BinaryQuery:
    }; class BinaryQuery : public Query { public: const Query *lop() { return _lop; } const Query *rop() { return _rop; } protected:
    BinaryQuery( Query *lop, Query *rop )
    : _lop( lop ), _rop( rop )
    {}
    Query *_lop;
    Query *_rop;

    С++ для начинающих
    876
    Складывается впечатление, что теперь оба производных класса должны предоставить лишь подходящие реализации eval():
    };
    Однако в том виде, в котором мы их определили, эти классы неполны. При компиляции самих определений ошибок не возникает, но если мы попытаемся определить фактический объект: new NameQuery( "proust " )); то компилятор выдаст сообщение об ошибке: в классе AndQuery нет конструктора, готового принять два аргумента.
    Мы предположили, что AndQuery и OrQuery наследуют конструктор BinaryQuery точно так же, как они наследуют функции-члены lop() и rop(). Однако производный класс не наследует конструкторов базового. (Это могло бы привести к ошибкам, связанным с неинициализированными членами производного класса. Представьте, что будет, если в
    AndQuery добавить пару членов, не являющихся объектами классов: унаследованный конструктор базового класса для инициализации объекта производного AndQuery применять уже нельзя. Однако программист может этого не осознавать. Ошибка проявится не при конструировании объекта AndQuery, а позже, при его использовании.
    Кстати говоря, перегруженные операторы new и delete наследуются, что иногда приводит к аналогичным проблемам.)
    Каждый производный класс должен предоставлять собственный набор конструкторов. В случае классов AndQuery и OrQuery единственная цель конструкторов – обеспечить интерфейс для передачи двух своих операндов конструктору BinaryQuery. Так выглядит исправленная реализация:
    // увы! эти определения классов некорректны class OrQuery : public BinaryQuery { public: virtual void eval();
    }; class AndQuery : public BinaryQuery { public: virtual void eval();
    // ошибка: отсутствует конструктор класса AndQuery
    AndQuery proust( new NameQuery( "marcel" ),

    С++ для начинающих
    877
    };
    Если мы еще раз взглянем на рис. 17.2, то увидим, что BinaryQuery – непосредственный базовый класс для AndQuery и OrQuery, а Query –для BinaryQuery. Таким образом,
    Query не является непосредственным базовым классом для AndQuery и OrQuery.
    Конструктору производного класса разрешается напрямую вызывать только конструктор своего непосредственного предшественника в иерархии (виртуальное наследование является исключением из этого правила, да и из многих других тоже: см. раздел 18.5).
    Например, попытка включить конструктор Query в список инициализации членов объекта AndQuery приведет к ошибке.
    При определении объектов классов AndQuery и OrQuery теперь вызываются три конструктора: для базового Query, для непосредственного базового класса BinaryQuery и для производного AndQuery или OrQuery. (Порядок вызова конструкторов базовых классов отражает обход дерева иерархии наследования в глубину.) Дополнительный уровень иерархии, связанный с BinaryQuery, практически не влияет на производительность, поскольку мы определили его конструкторы как встроенные.
    Так как модифицированная иерархия сохраняет открытый интерфейс исходного проекта, то все эти изменения не сказываются на коде, который был написан в расчете на старую иерархию. Хотя модифицировать пользовательский код не нужно, перекомпилировать его все же придется, что может отвратить некоторых пользователей от перехода на новую версию.
    1   ...   77   78   79   80   81   82   83   84   ...   93


    написать администратору сайта