|
Программирование >> Синтаксис инициирования исключений
class FooClass : public Class { public: Foo* make() Foo* f = new Foo; this->SetClass(f); return f; Выглядит получше, поскольку производные от Object классы и не подозревают об этих фокусах но так ли это? Недостаток этого подхода - в том, что он не работает для экземпляров Foo, объявленных в стеке или вложенных в другие классы в виде структур данных. Перед вами одна из ситуаций, в которых приходится принимать трудное решение: то ли ограничить класс только динамическими экземплярами, то ли искать более сложное решение и без того сложной проблемы. Существует еще один вариант - управлять выделением памяти и хранить адеса объекта класса прямо над самим объектом в памяти вместо того, чтобы делать его переменной класса предка. Для этого нам понадобятся приемы управления памятью, описанные в части 4. Внешние структуры данных Как упоминалось выше, вы также можете создать глобальную коллекцию с парами экземпляр/Class. Все не так скверно, как выглядит на первый взгляд, особенно если информация Class нужна только в процессе отладки и будет исключена в рабочем режиме. Если соблюдать осторожность в реализации, решение также распространяется и на такие вложенные объекты, как стековые переменные или экземпляры, хотя для этого вам понадобится соответствующая поддержка со стороны конструктора и деструктора основного класса. Нестандартные пространства памяти Другое решение, рассматриваемое в главах 15 и 16 - физическое разделение объектов по различным пространствам памяти в соответствии с их классом. Оно отличается повышенной сложностью и попросту не работает для вложенных объектов, но зато обладает впечатляющим быстродействием и малым расходом памяти. Представители В книге Advanced C++ Programming Styles and Idioms Джеймс Коплин (James Coplien) выдвинул особую разновидность объекта класса, который он назвал представителем (exemplar). Представитель - это объект класса, который является экземпляром представляемого им класса. Понятно? У меня от таких высказываний голова идет кругом. class Exemplar {}; Символический класс class Foo { private: Foo(); И все остальные конструкторы, кроме одного public: Foo(Exemplar); Конструктор представителя Foo* make(); Производящие функции представителя extern Foo* foo; Сам представитель Подробности несущественны. Важно то, что один экземпляр (на который ссылается переменная foo) выполняет функции объекта класса для класса Foo. В реализациях производящих функций необходимо убедиться, что this совпадает с представителем, поскольку производящая функция не должна вызываться для всех остальных экземпляров класса. С представителями можно делать все то же самое, что и с объектами класса. При этом необходимо учитывать следующее: Для представителей не нужно создавать отдельный класс Class. С представителями не приходится объявлять друзей (обычно объект класса должен быть другом того класса, который он представляет). Настоящие объекты классов заметно упрощают моделирование иерархий классов. Настоящие объекты классов упрощают создание гомоморфного интерфейса для описанных выше сведений о классах. С объектами классов отличия между тем, что относится к объектам класса/представителям, и тем, что относится к реальным экземплярам, становятся более отчетливыми. В общем и целом, объекты классов оказываются более гибкими при незначительно усложнении реализации по сравнению с экземплярами. Невидимые указатели Нетривиальное использование С++ напоминает один известный эпизод из фильма Сумеречная зона . Героиня попадает в автомобильную аварию. Она безуспешно ждет, пока кто-нибудь проедет по дороге, и в конце концов решает отправиться за помощью. Но куда бы она ни шла, как бы внимательно ни следила за направлением, она всегда возвращалась к обломкам машины. Так и с указателями: куда бы вы ни шли, вы все равно вернетесь к обломкам. Хм пожалуй, мне следовало подыскать более оптимистичное сравнение. В этой главе мы снова возвращаемся к теме указателей, на этот раз - в свете гомоморфных иерархий классов. Рассматриваемые здесь указатели я называю невидимыми (invisible pointers), поскольку в большинстве случаев можно устроить так, чтобы клиент абсолютно ничего не знал о присутствии указателя между ним и целевым объектом. Джеймс Коплин (James Coplien) рассматривает частный случай невидимых указателей и называет его парадигма конверт/письмо ; мы же поговорим о более общем случае. Основные концепции Если гомоморфизм хорошо подходит для других классов, значит, он подойдет и для указателей. Концепция проста: указатель и указываемый объект порождаются от одного и того же чисто абстрактного базового класса. class Foo { public: virtual void do something() = 0; virtual void do something e1se() = 0; class PFoo : public Foo { private: Foo* foo; public: virtual void do something() { foo->do something(); } virtual void do something e1se() { foo->do something e1se(); } class Bar : public Foo { Все для производного класса Вместо перегрузки оператора -> в PFoo используется делегирование. Приведенный фрагмент лишь слегка затрагивает данную тему. На практике приходится учитывать множество деталей, начиная с того, как скрыть указатели и указываемые объекты от клиентов.
|
© 2006 - 2024 pmbk.ru. Генерация страницы: 0.001
При копировании материалов приветствуются ссылки. |