Как идиома pimpl уменьшает количество зависимостей?

Основное преимущество заключается в том, что клиенты интерфейса не обязаны включать заголовки для всех внутренних зависимостей вашего класса. Таким образом, любые изменения в этих заголовках не приводят к перекомпиляции большей части вашего проекта. Плюс общий идеализм по поводу реализации-скрытия.

Кроме того, вам не обязательно помещать свой класс реализации в собственный заголовок. Просто сделайте его структурой внутри одного cpp и сделайте так, чтобы ваш внешний класс напрямую ссылался на его элементы данных.

Изменить: пример

SomeClass.h

struct SomeClassImpl;

class SomeClass {
    SomeClassImpl * pImpl;
public:
    SomeClass();
    ~SomeClass();
    int DoSomething();
};

SomeClass.cpp

#include "SomeClass.h"
#include "OtherClass.h"
#include <vector>

struct SomeClassImpl {
    int foo;
    std::vector<OtherClass> otherClassVec;   //users of SomeClass don't need to know anything about OtherClass, or include its header.
};

SomeClass::SomeClass() { pImpl = new SomeClassImpl; }
SomeClass::~SomeClass() { delete pImpl; }

int SomeClass::DoSomething() {
    pImpl->otherClassVec.push_back(0);
    return pImpl->otherClassVec.size();
}

Было несколько ответов... но до сих пор нет правильной реализации. Я несколько опечален тем, что примеры неверны, поскольку люди, вероятно, будут их использовать...

Идиома «Pimpl» является сокращением от «Указатель на реализацию» и также упоминается как «Брандмауэр компиляции». А теперь давайте погрузимся.

<сильный>1. Когда необходимо включение?

Когда вы используете класс, вам нужно его полное определение, только если:

• вам нужен его размер (атрибут вашего класса)
• вам нужно получить доступ к одному из его методов

Если вы только ссылаетесь на него или имеете указатель на него, то, поскольку размер ссылки или указателя не зависит от типа, на который ссылается/указывается, вам нужно только объявить идентификатор (форвардное объявление).

Пример:

#include "a.h"
#include "b.h"
#include "c.h"
#include "d.h"
#include "e.h"
#include "f.h"

struct Foo
{
  Foo();

  A a;
  B* b;
  C& c;
  static D d;
  friend class E;
  void bar(F f);
};

В приведенном выше примере, который включает «удобство», его можно удалить, не влияя на правильность? Самое удивительное: все, кроме "a.h".

<сильный>2. Внедрение Pimpl

Поэтому идея Pimpl состоит в том, чтобы использовать указатель на класс реализации, чтобы не было необходимости включать какой-либо заголовок:

• тем самым изолируя клиента от зависимостей
• тем самым предотвращая волновой эффект компиляции

Дополнительное преимущество: сохраняется ABI библиотеки.

Для простоты использования идиому Pimpl можно использовать со стилем управления «умный указатель»:

// From Ben Voigt's remark
// information at:
// http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Checked_delete
template<class T> 
inline void checked_delete(T * x)
{
    typedef char type_must_be_complete[ sizeof(T)? 1: -1 ];
    (void) sizeof(type_must_be_complete);
    delete x;
}


template <typename T>
class pimpl
{
public:
  pimpl(): m(new T()) {}
  pimpl(T* t): m(t) { assert(t && "Null Pointer Unauthorized"); }

  pimpl(pimpl const& rhs): m(new T(*rhs.m)) {}

  pimpl& operator=(pimpl const& rhs)
  {
    std::auto_ptr<T> tmp(new T(*rhs.m)); // copy may throw: Strong Guarantee
    checked_delete(m);
    m = tmp.release();
    return *this;
  }

  ~pimpl() { checked_delete(m); }

  void swap(pimpl& rhs) { std::swap(m, rhs.m); }

  T* operator->() { return m; }
  T const* operator->() const { return m; }

  T& operator*() { return *m; }
  T const& operator*() const { return *m; }

  T* get() { return m; }
  T const* get() const { return m; }

private:
  T* m;
};

template <typename T> class pimpl<T*> {};
template <typename T> class pimpl<T&> {};

template <typename T>
void swap(pimpl<T>& lhs, pimpl<T>& rhs) { lhs.swap(rhs); }

Что в нем есть такого, чего не было в других?

• Он просто подчиняется правилу трех: определение конструктора копирования, оператора присваивания копирования и деструктора.
• Он реализует Strong Guarantee: если во время присваивания копия выдает исключение, объект остается неизменным. Обратите внимание, что деструктор T не должен бросать... но это очень распространенное требование;)

Опираясь на это, теперь мы можем довольно легко определить классы Pimpl:

class Foo
{
public:

private:
  struct Impl;
  pimpl<Impl> mImpl;
}; // class Foo

Примечание: компилятор не может сгенерировать здесь корректный конструктор, скопировать оператор присваивания или деструктор, поскольку для этого потребуется доступ к Impl определению. Поэтому, несмотря на хелпер pimpl, вам нужно будет определить эти 4 вручную. Однако благодаря хелперу pimpl компиляция завершится ошибкой, а не затянет вас в страну неопределенного поведения.

<сильный>3. Идем дальше

Следует отметить, что наличие virtual функций часто рассматривается как деталь реализации. Одно из преимуществ Pimpl заключается в том, что у нас есть правильная структура для использования возможностей шаблона стратегии.

Для этого необходимо изменить «копию» pimpl:

// pimpl.h
template <typename T>
pimpl<T>::pimpl(pimpl<T> const& rhs): m(rhs.m->clone()) {}

template <typename T>
pimpl<T>& pimpl<T>::operator=(pimpl<T> const& rhs)
{
  std::auto_ptr<T> tmp(rhs.m->clone()); // copy may throw: Strong Guarantee
  checked_delete(m);
  m = tmp.release();
  return *this;
}

И тогда мы можем определить наш Foo вот так

// foo.h
#include "pimpl.h"

namespace detail { class FooBase; }

class Foo
{
public:
  enum Mode {
    Easy,
    Normal,
    Hard,
    God
  };

  Foo(Mode mode);

  // Others

private:
  pimpl<detail::FooBase> mImpl;
};

// Foo.cpp
#include "foo.h"

#include "detail/fooEasy.h"
#include "detail/fooNormal.h"
#include "detail/fooHard.h"
#include "detail/fooGod.h"

Foo::Foo(Mode m): mImpl(FooFactory::Get(m)) {}

Обратите внимание, что ABI Foo совершенно не касается различных изменений, которые могут произойти:

• в Foo нет виртуального метода
• размер mImpl равен размеру простого указателя, на что бы он ни указывал

Поэтому вашему клиенту не нужно беспокоиться о конкретном патче, который добавит либо метод, либо атрибут, и вам не нужно беспокоиться о расположении памяти и т. Д. ... это просто естественно работает.

При использовании идиомы PIMPL, если изменяются детали внутренней реализации класса IMPL, клиенты не должны перестраиваться. Любое изменение интерфейса класса IMPL (и, следовательно, файла заголовка), очевидно, потребует изменения класса PIMPL.

Кстати, в показанном коде существует сильная связь между IMPL и PIMPL. Таким образом, любое изменение в реализации класса IMPL также вызовет необходимость перестроения.

Подумайте о чем-то более реалистичном, и преимущества станут более заметными. В большинстве случаев, когда я использовал это для брандмауэра компилятора и сокрытия реализации, я определял класс реализации в той же единице компиляции, в которой находится видимый класс. В вашем примере у меня не было бы Impl.h или Impl.cpp, а Pimpl.cpp выглядело бы примерно так :

#include <iostream>
#include <boost/thread.hpp>

class Impl {
public:
  Impl(): data(0) {}
  void setData(int d) {
    boost::lock_guard l(lock);
    data = d;
  }
  int getData() {
    boost::lock_guard l(lock);
    return data;
  }
  void doSomething() {
    int d = getData();
    std::cout << getData() << std::endl;
  }
private:
  int data;
  boost::mutex lock;
};

Pimpl::Pimpl(): pimpl(new Impl) {
}

void Pimpl::doSomething() {
  pimpl->doSomething();
}

Теперь никому не нужно знать о нашей зависимости от boost. Это становится более мощным, когда смешивается с политиками. Такие детали, как политики многопоточности (например, одиночная или многопоточная) могут быть скрыты с помощью различных реализаций Impl за кулисами. Также обратите внимание, что в Impl есть ряд дополнительных методов, которые не представлены. Это также делает этот метод хорошим для наслоения вашей реализации.

В вашем примере вы можете изменить реализацию data без перекомпиляции клиентов. Этого не было бы без посредника PImpl. Точно так же вы можете изменить подпись или имя Imlp::DoSomething (до определенного предела), и клиенты не должны будут об этом знать.

В общем, все, что можно объявить private (по умолчанию) или protected в Impl, можно изменить без перекомпиляции клиентов.

В заголовках классов не Pimpl файл .hpp определяет общедоступные и частные компоненты вашего класса в одном большом сегменте.

Частные тесно связаны с вашей реализацией, так что это означает, что ваш файл .hpp действительно может многое рассказать о вашей внутренней реализации.

Рассмотрим что-то вроде библиотеки потоков, которую вы выбрали для частного использования внутри класса. Без использования Pimpl классы и типы потоков могут встречаться как частные члены или параметры в частных методах. Хорошо, библиотека потоков может быть плохим примером, но вы поняли: частные части определения вашего класса должны быть скрыты от тех, кто включает ваш заголовок.

Вот тут-то и появляется Pimpl. Поскольку заголовок общедоступного класса больше не определяет «приватные части», а вместо этого имеет указатель на реализацию, ваш приватный мир остается скрытым от логики, которая «#include» является вашим общедоступным классом. заголовок.

Когда вы меняете свои приватные методы (реализация), вы меняете вещи, скрытые под Pimpl, и поэтому клиентам вашего класса не нужно перекомпилировать, потому что с их точки зрения ничего не изменилось: они больше не видят частные члены реализации.

http://www.gotw.ca/gotw/028.htm

Не все классы выигрывают от p-impl. Ваш пример имеет только примитивные типы во внутреннем состоянии, что объясняет, почему нет очевидной выгоды.

Если какой-либо из членов имеет сложные типы, объявленные в другом заголовке, вы можете видеть, что p-impl перемещает включение этого заголовка из общедоступного заголовка вашего класса в файл реализации, поскольку вы формируете необработанный указатель на неполный тип (но не встроенное поле или смарт-указатель). Вы могли бы просто использовать необработанные указатели на все ваши переменные-члены по отдельности, но использование одного указателя на все состояние упрощает управление памятью и улучшает локальность данных (ну, если все эти типы используют p-impl по очереди, локальности не так много).