Почему следует использовать идиому «PIMPL»?

Размещение вызова impl-> Purr внутри файла cpp означает, что в будущем вы можете делать что-то совершенно другое без изменения файла заголовка. Возможно, в следующем году они обнаружат вспомогательный метод, который они могли бы вызвать вместо этого, и поэтому они смогут изменить код, чтобы вызывать его напрямую, а не использовать impl-> Purr вообще. (Да, они могли бы добиться того же, обновив фактический метод impl :: Purr, но в этом случае вы застряли с дополнительным вызовом функции, который ничего не дает, кроме вызова следующей функции по очереди)

Это также означает, что заголовок имеет только определения и не имеет какой-либо реализации, которая обеспечивает более четкое разделение, что составляет всю суть идиомы.

Я думаю, что большинство людей называют это идиомой «Ручка тела». См. Книгу Джеймса Коплиена «Расширенные стили и идиомы программирования на C++» (Ссылка на Amazon). Он также известен как Чеширский кот из-за персонажа Льюиса Кэролла, который исчезает, пока не остается только ухмылка.

Код примера следует распределить по двум наборам исходных файлов. Тогда только Cat.h - это файл, который поставляется с продуктом.

CatImpl.h включен в Cat.cpp, а CatImpl.cpp содержит реализацию CatImpl :: Purr (). Это не будет видно широкой публике, использующей ваш продукт.

В основном идея состоит в том, чтобы максимально скрыть реализацию от посторонних глаз. Это наиболее полезно, когда у вас есть коммерческий продукт, который поставляется в виде серии библиотек, доступ к которым осуществляется через API, с которым скомпилирован и связан код клиента.

Мы сделали это, переписав продукт IONAs Orbix 3.3 в 2000 году.

Как упоминалось другими, использование его техники полностью отделяет реализацию от интерфейса объекта. Тогда вам не придется перекомпилировать все, что использует Cat, если вы просто хотите изменить реализацию Purr ().

Этот метод используется в методологии под названием дизайн по контракту.

Как правило, единственной ссылкой на класс Pimpl в заголовке класса Owner (в данном случае Cat) будет предварительное объявление, как вы это сделали здесь, потому что это может значительно уменьшить зависимости.

Например, если ваш класс Pimpl имеет ComplicatedClass в качестве члена (а не только указатель или ссылку на него), вам нужно будет полностью определить ComplicatedClass перед его использованием. На практике это означает включение ComplicatedClass.h (который также косвенно будет включать все, от чего зависит ComplicatedClass). Это может привести к тому, что при заполнении одного заголовка потребуется много-много всего, что плохо для управления вашими зависимостями (и временем компиляции).

Когда вы используете pimpl idion, вам нужно только # включить то, что используется в общедоступном интерфейсе вашего типа Owner (которым здесь будет Cat). Это облегчает жизнь людям, использующим вашу библиотеку, и означает, что вам не нужно беспокоиться о людях, зависящих от какой-то внутренней части вашей библиотеки - либо по ошибке, либо потому, что они хотят сделать что-то, что вы не разрешаете, поэтому они #define закрытый публичный перед включением ваших файлов.

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

• Потому что вы хотите, чтобы Purr() мог использовать закрытые члены CatImpl. Cat::Purr() не будет разрешен такой доступ без декларации friend.
• Потому что тогда вы не смешиваете обязанности: один класс реализует, другой - вперед.

Если ваш класс использует идиому pimpl, вы можете избежать изменения файла заголовка в общедоступном классе.

Это позволяет добавлять / удалять методы в класс pimpl без изменения файла заголовка внешнего класса. Вы также можете добавить / удалить #includes в pimpl.

Когда вы изменяете файл заголовка внешнего класса, вам необходимо перекомпилировать все, что # включает его (и если какой-либо из них является заголовочными файлами, вам нужно перекомпилировать все, что # включает их, и так далее)

Не знаю, стоит ли упоминать об этой разнице, но ...

Можно ли иметь реализацию в собственном пространстве имен и иметь общедоступное пространство имен оболочки / библиотеки для кода, который видит пользователь:

catlib::Cat::Purr(){ cat_->Purr(); }
cat::Cat::Purr(){
   printf("purrrrrr");
}

Таким образом, весь код библиотеки может использовать пространство имен cat, и, поскольку возникает необходимость предоставить класс пользователю, можно создать оболочку в пространстве имен catlib.

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

Я часто задаюсь вопросом, не преувеличены ли «преимущества»; да, вы можете сделать некоторые детали вашей реализации еще более скрытыми, и да, вы можете изменить свою реализацию, не меняя заголовок, но не очевидно, что в действительности это большие преимущества.

То есть неясно, есть ли какая-либо необходимость в том, чтобы ваша реализация была хорошо скрыта который, и, возможно, довольно редко люди действительно меняют только реализацию; как только вам нужно добавить новые методы, скажем, вам все равно нужно изменить заголовок.

Я только что реализовал свой первый урок сутенера за последние пару дней. Я использовал его для устранения проблем, которые у меня были, включая winsock2.h в Borland Builder. Казалось, что это мешает выравниванию структуры, и, поскольку у меня были сокеты в частных данных класса, эти проблемы распространялись на любой файл cpp, который включал заголовок.

Используя pimpl, winsock2.h был включен только в один файл cpp, где я мог закрыть проблему и не беспокоиться о том, что она вернется, чтобы укусить меня.

Чтобы ответить на исходный вопрос, преимущество, которое я обнаружил при перенаправлении вызовов в класс pimpl, заключалось в том, что класс pimpl такой же, как и ваш исходный класс до того, как вы его добавили, плюс ваши реализации не распространяются на 2 классы каким-то странным образом. Гораздо понятнее реализовать публикацию, которая будет просто перенаправлять в класс pimpl.

Как сказал мистер Ноде, один класс, одна ответственность.

Что ж, я бы не стал его использовать. У меня есть альтернатива получше:

foo.h:

class Foo {
public:
    virtual ~Foo() { }
    virtual void someMethod() = 0;

    // This "replaces" the constructor
    static Foo *create();
}

foo.cpp:

namespace {
    class FooImpl: virtual public Foo {

    public:
        void someMethod() { 
            //....
        }     
    };
}

Foo *Foo::create() {
    return new FooImpl;
}

У этого паттерна есть название?

Как программисту также на Python и Java, мне это нравится намного больше, чем идиома pImpl.

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

Учтите, что реализация Cat может включать в себя множество заголовков, может включать метапрограммирование шаблонов, которое требует времени для самостоятельной компиляции. Почему пользователь, который просто хочет использовать Cat, должен включать все это? Следовательно, все необходимые файлы скрыты с использованием идиомы pimpl (отсюда и прямое объявление CatImpl), и использование интерфейса не заставляет пользователя включать их.

Я разрабатываю библиотеку для нелинейной оптимизации (прочтите «много неприятной математики»), которая реализована в шаблонах, поэтому большая часть кода находится в заголовках. Компиляция занимает около пяти минут (на приличном многоядерном процессоре), а простой анализ заголовков в пустом .cpp занимает около минуты. Таким образом, любой, кто использует библиотеку, должен ждать пару минут каждый раз, когда компилирует свой код, что делает разработку довольно скучный. Однако, скрывая реализацию и заголовки, можно просто включить простой интерфейсный файл, который мгновенно компилируется.

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

Мы используем идиому PIMPL для имитации аспектно-ориентированного программирования, в котором аспекты до, после и ошибки вызываются до и после выполнения функции-члена.

struct Omg{
   void purr(){ cout<< "purr\n"; }
};

struct Lol{
  Omg* omg;
  /*...*/
  void purr(){ try{ pre(); omg-> purr(); post(); }catch(...){ error(); } }
};

Мы также используем указатель на базовый класс, чтобы разделять различные аспекты между многими классами.

Недостатком этого подхода является то, что пользователь библиотеки должен учитывать все аспекты, которые будут выполняться, но видит только свой класс. Это требует просмотра документации на предмет каких-либо побочных эффектов.