Является ли хорошей практикой поместить реализацию чистого виртуального интерфейса в cpp и полностью пропустить заголовочный файл?
A.h
struct A
{
virtual void func() = 0;
};
B.cpp
class B : public A
{
virtual void func() override {
...
}
}
Кто-то должен использование класс 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
, Но я сомневаюсь, что это очень часто стоит.
Других решений пока нет …