c++ 沉思录---代理类

一、问题

  如何设计一容器能包含彼此不同而又相互关联的类的对象(处于完整的继承层次的类)?因为一般的数组容器都只能包含一种类型的对象。  

  假设有一个表示不同类型的交通工具的类的派生层次:

class Vehicle
{
public:
    virtual double weight () const = 0;
    virtual void start() = 0;
    //.....
};

class RoadVehicle : public Vehicle
{
public:
    /* data */
};

class AutoVehivle : public Vehicle
{
public:
    /* data */
};

class Aircraft : public Vehicle
{
public:
    /* data */
};

 现在我们需要一个容器,这里使用数组表示,能够包含所有上述类的对象,Vehicle parkint_lot[100]; 这样肯定不对

错误原因:1. Vehicle 是个抽象基类(含有纯虚函数),不能实例化对象

      2. 假设Vehicle能够实例化也不对,Parking_lot[num_vehicles++] = 派生类对象,这样的操作,会将派生类对象转化为一个Vehicle类的对象,会丢失所有Vehicle类中没有的成员。最后的结果是Parking_lot是Vehicle的集合。

二、解决方案1(传统的解决方法)

通过在数组中存储基类的指针,因为基类的指针转换为派生类的指针是容易且安全的。

Vehicle*  Parking_lot[100];

然后输入类似:

    Automonbile x =

1: Parking_lot[num_vehicles++] = &x;

存在问题:如果x是局部变量,一旦变量x销毁了,Parking_lot 就不知道指向什么东西了。

2:  Parking_lot[num_vehicles++] =  new Automobile(x);

存在问题:为了解决1中问题,改用存储对象副本的指针。这种方法会带来一定的内存管理负担,其实我觉得还行,没那么严重,在需求没那么严格的情况下这种方法还是可以使用的。

 但是,这种只有当我们确定知道要放入parking_lot对象的静态类型后,才启作用!!!

 注意:用基类的指针或引用引用一个派生类对象时,由于派生类对象也是基类的对象,所以这样也是安全的但是只能引用基类中所拥有的成员,不能引用在派生类中定义的成员,否则编译器会报错。

三、解决方案2(代理类)

代理类:定义一个行为和Vehicle对象相似,而又潜在的表示为所有继承自Vehicle类的对象的东西,我们把这种类的对象称之为代理。

在Vehicle类中添加虚复制函数

virtual Vehicle* copy() const = 0;

  派生类中实现:  

  Vehicle*  派生类名称::copy() const{

    return new 派生类名称(*this);

  }

class VehicleSurrogate
{
public:
    VehicleSurrogate();
    ~VehicleSurrogate();
    VehicleSurrogate(const Vehicle& v){
        vp(v.copy());
    }

    VehicleSurrogate(const VehicleSurrogate&);
    VehicleSurrogate& operator = (const VehicleSurrogate&);
private:
    Vehicle* vp;
};

代理类的成员变量为Vehivle 类型的指针,参数为const Vehicle& 类型的构造函数,可以为任意继承自Vehicle的类的对象创建代理。

使用方法:

VehicleSurrogate paking_lot[100];

Automobile x;

Paking_lot[num_vehicles++] = x;   等价于 paking_lot[num_vehicles++] = VehicleSurrogate(x);

时间: 2024-10-17 15:10:29

c++ 沉思录---代理类的相关文章

《C++沉思录》——类设计核查表、代理类、句柄类

<C++沉思录>集中反映C++的关键思想和编程技术,讲述如何编程,讲述为什么要这么编程,讲述程序设计的原则和方法,讲述如何思考C++编程. 一.类设计核查表 1.你的类需要一个构造函数吗? 2.你的数据成员都是私有的合理吗? 3.你的类需要一个无参的构造函数吗? 是否需要生成类对象的数组! 4.你的每一个构造函数都初始化所有的数据成员了吗? 虽然这种说法未必总是正确,但是要积极思考! 5.你的类需要析构函数吗? 6.你的类需要一个虚析构函数吗? 7.你的类需要一个拷贝构造函数吗? 8.你的类需

【C++沉思录】代理类

1.考虑下面的场景:设计一个容器,包含一组类型不同但相互关联的对象(比如:Animal,Dog,Cat),对象具备多态行为.2.容器一般只能包含一种类型的对象,使用vector<Animal> 会造成对象切割,不具备多态行为.3.经典的解决办法是:vector<Animal*>, 但是这会增加内存管理的负担.考虑下面的情况: Dog d; vec[i] = &d; // 局部对象d销毁, vec[i] 指向垃圾 vec[i] = vec[j]; // 指向同一个对象, 在v

《C++沉思录》:类设计者的核查表——有关class的11问

本文的11个问题提取自<C++沉思录>第四章.所有问题的说明均为自己补充. 1 你的类需要一个构造函数吗? --正确的定义构造函数,把握好构造函数的职能范围 有些类太简单,它们的结构就是它们的接口,所以不需要构造函数. class print{ void print1(){cout<<"1"<<endl;} void print2(){cout<<"2"<<endl;} void print3(){cout

OOD沉思录 --- 面向动作与面向对象 --- 避免泛滥成灾的类

3.7 从设计中取出不需要的类 只有Get/Set方法的类不算是一个必要的类,Get/Set方法也不算是有意义的行为.这种类降级为属性更加合适. 3.8 去除系统外部的类 如果一个类只调用系统领域的方法,而系统没有向该类调用,则可以认为这个类并不属于系统.可能只是系统的使用者,我们没必要去为此建模.     创建此类时应该问一问“这个类在系统内做什么事情?” 3.9 不要把操作变成类. “我需要一个做...事情的类”,如果有这种想法,请先认真斟酌.这个类真的代表了某个关键抽象概念吗? 名字是动词

【C++沉思录】句柄1

1.在[C++沉思录]代理类中,使用了代理类,存在问题: a.代理复制,每次创建一个副本,这个开销有可能很大 b.有些对象不能轻易创建副本,比如文件2.怎么解决这个问题? 使用引用计数句柄,对动态资源封装,句柄包含指针,多个句柄可以指向同一个对象.复制的时候,只是复制句柄的指针.3.使用引用计数句柄,是为了避免不必要的对象复制,因此我们要知道有多少个句柄绑定到当前对象,也就是引用计数, 这样才能确定何时可以释放资源.4.需要注意的是:引用计数不能是句柄的一部分,如果怎么做,当前句柄必须知道指向同

C++沉思录之二——虚函数使用的时机

虚函数使用的时机 为什么虚函数不总是适用? 1. 虚函数有事会带来很大的消耗: 2. 虚函数不总是提供所需的行为: 3. 当我们不考虑继承当前类时,不必使用虚函数. 必须使用虚函数的情况: 1. 当你想删除一个表面上指向基类对象,实际却是指向派生类对象的指针,就需要虚析构函数. C++沉思录之二--虚函数使用的时机,布布扣,bubuko.com

迷你MVVM框架 avalonjs 沉思录 第1节 土耳其开局

#cnblogs_post_body p{ text-indent:2em; margin-top: 1em; } 正如一切传说的开端那样,有一远古巨神开天辟地,然后就是其他半神喧宾夺主.我们对最巨贡献与创建力的远古巨神懵懂不知,却对巫师们的话语津津乐道.这同样也是我们前端的现实. MVVM是来自.NET,另一个遥远的界域.前端,相对于后端,怎么看都是蛮夷之地.JS这个肩负着前端一切交互工作的语言,竟然被视为恶魔,屡屡被屏蔽禁用.些微可用的脚本,变量与函数没有组织地野蛮生长着,直到JAVA的传教

&lt;&lt;C++ 沉思录&gt;&gt; 中文人民邮电出版 勘误

<<C++ 沉思录>> 中文人民邮电出版 勘误 这本中文版里面有各种坑爹的小错误. 比方说变量名的大小写, 同一个变量, 出现了大小写不一致, 等等问题都有. 然后今天感觉遇到了个语法问题. 关于继承权限的问题. 书中第八章的demo里面, 关于class Expr_node. 使用了protected关键字. 但是这里Expr_node是基类, 继承就会出现问题. 具体的代码如下: class Expr_node { friend ostream& operator &l

设计模式沉思录——互动出版网

这篇是计算机类的优质预售推荐>>>><设计模式沉思录> GoF成员.<设计模式>一书作者之一John M. Vlissides为你揭开模式设计的神秘面纱 内容简介 本书在GoF的<设计模式>一书的基础上进行了拓展,运用其中的概念,介绍了一些技巧,帮助读者决定在不同的情况下应该使用哪些模式,以及不应该使用哪些模式.本书不仅对已有的一些模式提出新的见解,还让读者见证开发新模式的整个过程. 本书适合使用设计模式的软件开发人员阅读. 作译者 作者介绍 J