Реализация чистого виртуального интерфейса в файле cpp

Является ли хорошей практикой поместить реализацию чистого виртуального интерфейса в cpp и полностью пропустить заголовочный файл?

A.h
struct A
{
virtual void func() = 0;
};
B.cpp
class B : public A
{
virtual void func() override {
...
}
}

2

Решение

Кто-то должен использование класс Bи они должны получить экземпляры B откуда-то, даже если они только обращаются к ним через A*, Таким образом, вы могли бы иметь, например:

хиджры

struct A
{
virtual void func() = 0;
virtual ~A() {}
};

B.h

#include "A.h"A *Bfactory();

B.cpp

#include "B.h"struct B : public A { ... };
A *Bfactory() { return new B(); }

С другой стороны, это довольно «слабая» фабричная функция, потому что она только когда-либо возвращает экземпляры B, Возможно, где-то будет другая фабричная функция, которая создает различные производные классы A по своим параметрам. Эта функция должна включать A.h, B.h, C.h и т.д., но если он всегда использует Bfactory создать экземпляры B тогда ему не нужно определение класса B, Так что в этом случае вполне возможно, что определение класса существует только в B.cpp,

Кстати, я вернул сырой указатель с завода. В реальной жизни вы можете предпочесть вернуть unique_ptr или другой умный указатель. Если вы сделаете это, то на самом деле можно избежать необходимости виртуального деструктора в A, Но я сомневаюсь, что это очень часто стоит.

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]