C ++ - 从抽象对象创建非抽象对象

时间:2016-04-03 18:05:05

标签: c++ inheritance abstract-class pure-virtual

我有这个基类

class Object {
 ...
 public:
  virtual void move() = 0;
  virtual void move(string) = 0;
  virtual void powerOn() = 0;
  virtual void powerOff() = 0;
  virtual void speak() = 0; 
};

这将是不同类的基类

class Electronics : public Object {
 ...
 public:
  virtual void powerOn();
  virtual void powerOff();
};

void Electronics::powerOn() { ... }
void Electronics::powerOff() { ... }

class Phone : public Electronics {
 ...
 public:
};

现在,如果我想创建一个对象Phone,它使用teh powerOn()和powerOff()方法。我不需要其他三种方法。

Object *obj = new Phone;

但这可能会给我一个错误说

undefined reference to move()
undefined reference to move(string)
undefined reference to speak()

我的问题是,如何避免此错误。我不需要这些电话功能,但它要求我对它们做些什么。我怎么能克服这个错误?

由于

2 个答案:

答案 0 :(得分:0)

您可以在ElectronicsObject中提供这些虚拟方法的空实现(使方法非抽象)。或者,如果两者都需要这样,则需要在Phone中重新实现它们。但是,你不能在Phone中“隐藏”它们,除非你将它们从基座上移除。

答案 1 :(得分:0)

如上所述,您可以在Electronics类中创建它们的空实现,换句话说,覆盖此类中的方法,并简单地让它具有空体。 (参见此处示例:http://ideone.com/jM2hX7

#include <iostream>
using namespace std;

class Object {
 public:
  virtual void move() = 0;
  virtual void move(string) = 0;
  virtual void powerOn() = 0;
  virtual void powerOff() = 0;
  virtual void speak() = 0; 
};

class Electronics : public Object {
 public:
  virtual void move() override {}
  virtual void move(string) override {}
  virtual void powerOn() override {cout << "powerOn" << endl;}
  virtual void powerOff() override {cout << "powerOff" << endl;}
  virtual void speak() override {} 
};

class Phone : public Electronics {
  virtual void powerOn() override {cout << "phone:powerOn" << endl;}
  virtual void powerOff() override {cout << "phone:powerOff" << endl;}
};

int main() {
    Object* phone = new Phone;

    phone->move();
    phone->powerOn();
    phone->powerOff();
    phone->speak();     

    delete phone;
    return 0;
}

输出:

phone:powerOn
phone:powerOff

更重要的是,虽然您可能想重新考虑您的课堂设计,但是在您的班级中是否真的有必要使用纯powerOnpowerOffspeak等虚拟方法:Object。对象听起来很普通,而这些功能听起来更具体。理想情况下,Object只应包含对从中继承的所有类有意义的函数。

这些函数在Electronics类中可能更有意义,即使这样,看起来有点过于笼统。

如果确实需要在Object课程中包含这些对象,那么我会亲自将其重命名为更多说法。