Я бачу багато вихідного коду, який використовує ідіому PImpl в C ++. Я припускаю, що його мета - приховати приватні дані / тип / реалізацію, щоб вона могла зняти залежність, а потім зменшити час компіляції та заголовка включити питання.
Але інтерфейс / чисто абстрактні класи в C ++ також мають цю можливість, вони також можуть використовуватися для приховування даних / типу / реалізації. І щоб абонент просто бачив інтерфейс під час створення об’єкта, ми можемо оголосити заводський метод у заголовку інтерфейсу.
Порівняння:
Вартість :
Вартість способу інтерфейсу нижча, тому що вам навіть не потрібно повторювати реалізацію функції загальнодоступної обгортки
void Bar::doWork() { return m_impl->doWork(); }
, просто потрібно визначити підпис в інтерфейсі.Добре зрозумів :
Технологію інтерфейсу краще розуміти кожен розробник C ++.
Продуктивність :
Продуктивність інтерфейсу не гірша за ідіому PImpl, як додатковий доступ до пам'яті. Я припускаю, що продуктивність однакова.
Далі йде псевдокод, щоб проілюструвати моє запитання:
// 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;
};
Ця ж мета може бути реалізована за допомогою інтерфейсу:
// 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();
Тож у чому сенс PImpl?
Impl
класі не порушитьABI
, але додавання публічної функції в інтерфейсі порушитьсяABI
.