Как настроить класс, представляющий интерфейс? Это просто абстрактный базовый класс?
Как настроить класс, представляющий интерфейс? Это просто абстрактный базовый класс?
Ответы:
Чтобы расширить ответ с помощью bradtgmurray , вы можете сделать одно исключение из списка чисто виртуальных методов вашего интерфейса, добавив виртуальный деструктор. Это позволяет передавать владение указателем другой стороне, не раскрывая конкретный производный класс. Деструктор не должен ничего делать, потому что в интерфейсе нет конкретных членов. Может показаться противоречивым определение функции как виртуальной, так и встроенной, но, поверьте мне, это не так.
class IDemo
{
public:
virtual ~IDemo() {}
virtual void OverrideMe() = 0;
};
class Parent
{
public:
virtual ~Parent();
};
class Child : public Parent, public IDemo
{
public:
virtual void OverrideMe()
{
//do stuff
}
};
Вам не нужно включать тело для виртуального деструктора - оказывается, у некоторых компиляторов возникают проблемы с оптимизацией пустого деструктора, и вам лучше использовать значение по умолчанию.
=0
) деструктор с телом. Преимущество здесь в том, что теоретически компилятор может увидеть, что vtable не имеет допустимых членов, и вообще отказаться от него. В случае виртуального деструктора с телом указанный деструктор может быть вызван (виртуально), например, в середине конструкции с помощью this
указателя (когда сконструированный объект все еще имеет Parent
тип), и поэтому компилятор должен предоставить действительную vtable. Поэтому, если вы не вызываете виртуальные деструкторы напрямую this
во время создания :), вы можете сэкономить на размере кода.
override
ключевое слово для проверки аргументов во время компиляции и проверки типа возвращаемого значения. Например, в декларации о детяхvirtual void OverrideMe() override;
Сделайте класс с чисто виртуальными методами. Используйте интерфейс, создав другой класс, который переопределяет эти виртуальные методы.
Чисто виртуальный метод - это метод класса, который определяется как виртуальный и присваивается 0.
class IDemo
{
public:
virtual ~IDemo() {}
virtual void OverrideMe() = 0;
};
class Child : public IDemo
{
public:
virtual void OverrideMe()
{
//do stuff
}
};
override
в C ++ 11
Причина, по которой у вас есть специальная категория типов интерфейса в дополнение к абстрактным базовым классам в C # / Java, заключается в том, что C # / Java не поддерживает множественное наследование.
C ++ поддерживает множественное наследование, поэтому специальный тип не требуется. Абстрактный базовый класс без неабстрактных (чисто виртуальных) методов функционально эквивалентен интерфейсу C # / Java.
Thread
экземпляром. Многократное наследование может быть как плохим дизайном, так и композицией. Все зависит от случая.
В C ++ нет понятия «интерфейс» как такового. AFAIK, интерфейсы были впервые введены в Java, чтобы обойти отсутствие множественного наследования. Эта концепция оказалась весьма полезной, и тот же эффект может быть достигнут в C ++ с помощью абстрактного базового класса.
Абстрактный базовый класс - это класс, в котором хотя бы одна функция-член (метод в языке Java) является чисто виртуальной функцией, объявленной с использованием следующего синтаксиса:
class A
{
virtual void foo() = 0;
};
Абстрактный базовый класс не может быть создан, т. Е. Вы не можете объявить объект класса A. Вы можете получить классы только из A, но любой производный класс, который не обеспечивает реализацию foo()
, также будет абстрактным. Чтобы перестать быть абстрактным, производный класс должен предоставлять реализации для всех чисто виртуальных функций, которые он наследует.
Обратите внимание, что абстрактный базовый класс может быть не просто интерфейсом, поскольку он может содержать члены-данные и функции-члены, которые не являются чисто виртуальными. Эквивалентом интерфейса был бы абстрактный базовый класс без каких-либо данных только с чисто виртуальными функциями.
И, как отметил Марк Рэнсом, абстрактный базовый класс должен обеспечивать виртуальный деструктор, как и любой базовый класс.
Насколько я мог проверить, очень важно добавить виртуальный деструктор. Я использую объекты, созданные new
и уничтоженные delete
.
Если вы не добавите виртуальный деструктор в интерфейс, то деструктор унаследованного класса не вызывается.
class IBase {
public:
virtual ~IBase() {}; // destructor, use it to call destructor of the inherit classes
virtual void Describe() = 0; // pure virtual method
};
class Tester : public IBase {
public:
Tester(std::string name);
virtual ~Tester();
virtual void Describe();
private:
std::string privatename;
};
Tester::Tester(std::string name) {
std::cout << "Tester constructor" << std::endl;
this->privatename = name;
}
Tester::~Tester() {
std::cout << "Tester destructor" << std::endl;
}
void Tester::Describe() {
std::cout << "I'm Tester [" << this->privatename << "]" << std::endl;
}
void descriptor(IBase * obj) {
obj->Describe();
}
int main(int argc, char** argv) {
std::cout << std::endl << "Tester Testing..." << std::endl;
Tester * obj1 = new Tester("Declared with Tester");
descriptor(obj1);
delete obj1;
std::cout << std::endl << "IBase Testing..." << std::endl;
IBase * obj2 = new Tester("Declared with IBase");
descriptor(obj2);
delete obj2;
// this is a bad usage of the object since it is created with "new" but there are no "delete"
std::cout << std::endl << "Tester not defined..." << std::endl;
descriptor(new Tester("Not defined"));
return 0;
}
Если вы запустите предыдущий код без virtual ~IBase() {};
, вы увидите, что деструктор Tester::~Tester()
никогда не вызывается.
Мой ответ в основном такой же, как и у других, но я думаю, что есть еще две важные вещи:
Объявите виртуальный деструктор в вашем интерфейсе или создайте защищенный не виртуальный, чтобы избежать неопределенного поведения, если кто-то пытается удалить объект типа IDemo
.
Используйте виртуальное наследование, чтобы избежать проблем с множественным наследованием. (При использовании интерфейсов чаще встречается множественное наследование.)
И, как и другие ответы:
Используйте интерфейс, создав другой класс, который переопределяет эти виртуальные методы.
class IDemo
{
public:
virtual void OverrideMe() = 0;
virtual ~IDemo() {}
}
Или
class IDemo
{
public:
virtual void OverrideMe() = 0;
protected:
~IDemo() {}
}
А также
class Child : virtual public IDemo
{
public:
virtual void OverrideMe()
{
//do stuff
}
}
В C ++ 11 вы можете легко избежать наследования:
struct Interface {
explicit Interface(SomeType& other)
: foo([=](){ return other.my_foo(); }),
bar([=](){ return other.my_bar(); }), /*...*/ {}
explicit Interface(SomeOtherType& other)
: foo([=](){ return other.some_foo(); }),
bar([=](){ return other.some_bar(); }), /*...*/ {}
// you can add more types here...
// or use a generic constructor:
template<class T>
explicit Interface(T& other)
: foo([=](){ return other.foo(); }),
bar([=](){ return other.bar(); }), /*...*/ {}
const std::function<void(std::string)> foo;
const std::function<void(std::string)> bar;
// ...
};
В этом случае интерфейс имеет ссылочную семантику, т.е. вы должны убедиться, что объект переживает интерфейс (также возможно создание интерфейсов с семантикой значения).
Эти типы интерфейсов имеют свои плюсы и минусы:
Наконец, наследование является корнем зла в разработке сложных программ. В семантике значений Sean Parent и основанном на понятиях полиморфизме (настоятельно рекомендуется, там объясняются лучшие версии этой методики) изучается следующий случай:
Скажем, у меня есть приложение, в котором я работаю с моими формами полиморфно, используя MyShape
интерфейс:
struct MyShape { virtual void my_draw() = 0; };
struct Circle : MyShape { void my_draw() { /* ... */ } };
// more shapes: e.g. triangle
В вашем приложении вы делаете то же самое с различными формами, используя YourShape
интерфейс:
struct YourShape { virtual void your_draw() = 0; };
struct Square : YourShape { void your_draw() { /* ... */ } };
/// some more shapes here...
Теперь скажите, что вы хотите использовать некоторые формы, которые я разработал в вашем приложении. Концептуально наши фигуры имеют одинаковый интерфейс, но чтобы мои фигуры работали в вашем приложении, вам необходимо расширить мои фигуры следующим образом:
struct Circle : MyShape, YourShape {
void my_draw() { /*stays the same*/ };
void your_draw() { my_draw(); }
};
Во-первых, изменение моих форм может оказаться невозможным вообще. Более того, множественное наследование ведет к коду спагетти (представьте, что третий проект, использующий TheirShape
интерфейс ... что произойдет, если они также вызовут свою функцию рисования my_draw
?).
Обновление: есть пара новых ссылок о полиморфизме, не основанном на наследовании:
Circle
класс - плохой дизайн. Вы должны использовать Adapter
шаблон в таких случаях. Извините, если это будет звучать немного резко, но попробуйте использовать некоторую реальную библиотеку, как Qt
прежде, чем выносить суждения о наследовании. Наследование делает жизнь намного проще.
Adapter
шаблона? Мне интересно увидеть его преимущества.
Square
его там еще нет? Предвидение? Вот почему это оторвано от реальности. И на самом деле, если вы решите положиться на библиотеку «MyShape», вы можете использовать ее интерфейс с самого начала. В примере фигур есть много глупостей (одна из которых состоит в том, что у вас есть две Circle
структуры), но адаптер будет выглядеть примерно так -> ideone.com/UogjWk
Все хорошие ответы выше. Еще одна вещь, которую вы должны иметь в виду - у вас также может быть чистый виртуальный деструктор. Разница лишь в том, что вам все еще нужно это реализовать.
Смущенный?
--- header file ----
class foo {
public:
foo() {;}
virtual ~foo() = 0;
virtual bool overrideMe() {return false;}
};
---- source ----
foo::~foo()
{
}
Основная причина, по которой вы хотите это сделать, заключается в том, что вы хотите предоставить методы интерфейса, как я, но сделать переопределение их необязательным.
Чтобы сделать класс интерфейсным классом, необходим чисто виртуальный метод, но все ваши виртуальные методы имеют реализации по умолчанию, поэтому единственный метод, который остается сделать чисто виртуальным, - это деструктор.
Переопределение деструктора в производном классе не представляет особой проблемы - я всегда переопределяю деструктор, виртуальный или нет, в своих производных классах.
Если вы используете компилятор Microsoft C ++, вы можете сделать следующее:
struct __declspec(novtable) IFoo
{
virtual void Bar() = 0;
};
class Child : public IFoo
{
public:
virtual void Bar() override { /* Do Something */ }
}
Мне нравится этот подход, потому что он приводит к гораздо меньшему коду интерфейса, а размер сгенерированного кода может быть значительно меньше. Использование novtable удаляет все ссылки на указатель vtable в этом классе, поэтому вы никогда не сможете создать его экземпляр напрямую. Смотрите документацию здесь - novtable .
novtable
по стандартуvirtual void Bar() = 0;
= 0;
которое я добавил). Прочтите документацию, если вы ее не понимаете.
= 0;
и предположил, что это был просто нестандартный способ сделать то же самое.
Небольшое дополнение к тому, что там написано:
Во-первых, убедитесь, что ваш деструктор также является чисто виртуальным
Во-вторых, вы можете захотеть наследовать виртуально (а не нормально), когда вы реализуете, просто для хороших мер.
Вы также можете рассмотреть классы контрактов, реализованные с помощью NVI (Non Virtual Interface Pattern). Например:
struct Contract1 : boost::noncopyable
{
virtual ~Contract1();
void f(Parameters p) {
assert(checkFPreconditions(p)&&"Contract1::f, pre-condition failure");
// + class invariants.
do_f(p);
// Check post-conditions + class invariants.
}
private:
virtual void do_f(Parameters p) = 0;
};
...
class Concrete : public Contract1, public Contract2
{
private:
virtual void do_f(Parameters p); // From contract 1.
virtual void do_g(Parameters p); // From contract 2.
};
Я все еще новичок в разработке C ++. Я начал с Visual Studio (VS).
Тем не менее, никто не упоминал __interface
в VS (.NET) . Я не очень уверен, что это хороший способ объявить интерфейс. Но, похоже, предусматривают дополнительное правоприменение (упомянуто в документах ). Так что вам не нужно явно указывать virtual TYPE Method() = 0;
, так как он будет автоматически преобразован.
__interface IMyInterface {
HRESULT CommitX();
HRESULT get_X(BSTR* pbstrName);
};
Однако я им не пользуюсь, потому что беспокоюсь о совместимости кроссплатформенной компиляции, поскольку она доступна только в .NET.
Если у кого-то есть что-нибудь интересное об этом, пожалуйста, поделитесь. :-)
Спасибо.
Несмотря на то, что virtual
это де-факто стандарт для определения интерфейса, давайте не будем забывать о классическом C-подобном шаблоне, который поставляется с конструктором в C ++:
struct IButton
{
void (*click)(); // might be std::function(void()) if you prefer
IButton( void (*click_)() )
: click(click_)
{
}
};
// call as:
// (button.*click)();
Преимущество этого заключается в том, что вы можете перепривязывать события во время выполнения без необходимости повторного конструирования вашего класса (поскольку C ++ не имеет синтаксиса для изменения полиморфных типов, это обходной путь для классов хамелеонов).
Советы:
click
вашего потомка.protected
члена и иметь public
ссылку и / или получатель.if
s и состояния в вашем коде, это может быть быстрее, чем switch()
es или if
s (изменение ожидается примерно через 3-4 if
с, но всегда измеряйте в первую очередь.std::function<>
более указателей на функции, вы могли бы быть в состоянии управлять всеми данными объекта внутри IBase
. С этого момента вы можете иметь схему значений для IBase
(например, std::vector<IBase>
будет работать). Обратите внимание, что это может быть медленнее в зависимости от вашего компилятора и кода STL; также, что текущие реализации std::function<>
имеют тенденцию иметь накладные расходы по сравнению с указателями функций или даже виртуальными функциями (это может измениться в будущем).Вот определение abstract class
в стандарте C ++
n4687
13.4.2
Абстрактный класс - это класс, который может использоваться только как базовый класс какого-либо другого класса; никакие объекты абстрактного класса не могут быть созданы, кроме как подобъекты класса, производного от него. Класс является абстрактным, если он имеет хотя бы одну чисто виртуальную функцию.
class Shape
{
public:
// pure virtual function providing interface framework.
virtual int getArea() = 0;
void setWidth(int w)
{
width = w;
}
void setHeight(int h)
{
height = h;
}
protected:
int width;
int height;
};
class Rectangle: public Shape
{
public:
int getArea()
{
return (width * height);
}
};
class Triangle: public Shape
{
public:
int getArea()
{
return (width * height)/2;
}
};
int main(void)
{
Rectangle Rect;
Triangle Tri;
Rect.setWidth(5);
Rect.setHeight(7);
cout << "Rectangle area: " << Rect.getArea() << endl;
Tri.setWidth(5);
Tri.setHeight(7);
cout << "Triangle area: " << Tri.getArea() << endl;
return 0;
}
Результат: Площадь прямоугольника: 35 Площадь треугольника: 17
Мы видели, как абстрактный класс определял интерфейс в терминах getArea (), и два других класса реализовали одну и ту же функцию, но с другим алгоритмом для вычисления области, специфичной для фигуры.