Widzę dużo kodu źródłowego używającego idiomu PImpl w C ++. Zakładam, że jego celem jest ukrycie prywatnych danych / typu / implementacji, aby mógł on usunąć zależność, a następnie skrócić czas kompilacji i problem z nagłówkiem.
Ale klasy interfejsu / czysto abstrakcyjne w C ++ również mają tę możliwość, można ich również użyć do ukrycia danych / typu / implementacji. Aby wywołujący mógł widzieć interfejs podczas tworzenia obiektu, możemy zadeklarować metodę fabryczną w nagłówku interfejsu.
Porównanie jest następujące:
Koszt :
Koszt sposobu interfejsu jest niższy, ponieważ nie trzeba nawet powtarzać publicznej implementacji funkcji opakowania
void Bar::doWork() { return m_impl->doWork(); }, wystarczy zdefiniować podpis w interfejsie.Dobrze zrozumiany :
Technologia interfejsu jest lepiej rozumiana przez każdego programistę C ++.
Wydajność :
Wydajność interfejsu nie gorsza niż idiom PImpl, zarówno dodatkowy dostęp do pamięci. Zakładam, że wydajność jest taka sama.
Poniżej znajduje się pseudokod ilustrujący moje pytanie:
// Forward declaration can help you avoid include BarImpl header, and those included in BarImpl header.
class BarImpl;
class Bar
{
public:
// public functions
void doWork();
private:
// You don't need to compile Bar.cpp after changing the implementation in BarImpl.cpp
BarImpl* m_impl;
};
Ten sam cel można zrealizować za pomocą interfejsu:
// Bar.h
class IBar
{
public:
virtual ~IBar(){}
// public functions
virtual void doWork() = 0;
};
// to only expose the interface instead of class name to caller
IBar* createObject();
Jaki jest sens PImpl?
Implklasie nie spowoduje przerwaniaABI, ale dodanie funkcji publicznej w interfejsie ulegnie awariiABI.