Warum sollte die Redewendung „PIMPL“ verwendet werden? [duplicate]

Hintergrund:

Die PIMPL-Idiom (Pointer to IMPLementation) ist eine Technik zum Verbergen der Implementierung, bei der eine öffentliche Klasse eine Struktur oder Klasse umschließt, die außerhalb der Bibliothek, zu der die öffentliche Klasse gehört, nicht sichtbar ist.

Dies verbirgt interne Implementierungsdetails und Daten vor dem Benutzer der Bibliothek.

Warum sollten Sie bei der Implementierung dieses Idioms die öffentlichen Methoden in der Pimpl-Klasse und nicht in der öffentlichen Klasse platzieren, da die Methodenimplementierungen der öffentlichen Klassen in die Bibliothek kompiliert würden und der Benutzer nur die Header-Datei hat?

Zur Veranschaulichung setzt dieser Code die Purr() Implementierung auf der impl-Klasse und umschließt sie ebenfalls.

Warum nicht Purr direkt in der öffentlichen Klasse implementieren?

// header file:
class Cat {
    private:
        class CatImpl;  // Not defined here
        CatImpl *cat_;  // Handle

    public:
        Cat();            // Constructor
        ~Cat();           // Destructor
        // Other operations...
        Purr();
};


// CPP file:
#include "cat.h"

class Cat::CatImpl {
    Purr();
...     // The actual implementation can be anything
};

Cat::Cat() {
    cat_ = new CatImpl;
}

Cat::~Cat() {
    delete cat_;
}

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

Ich denke, die meisten Leute bezeichnen dies als die Griffkörper Idiom. Siehe das Buch von James Coplien Fortgeschrittene C++-Programmierstile und Redewendungen. Es ist auch als bekannt Grinsekatze durch Lewis Carolls Charakter, der verblasst, bis nur noch das Grinsen übrig bleibt.

Der Beispielcode sollte auf zwei Gruppen von Quelldateien verteilt werden. Nur dann Kat.h ist die Datei, die mit dem Produkt geliefert wird.

CatImpl.h ist enthalten von Kat.cpp und CatImpl.cpp enthält die Implementierung für CatImpl::Purr(). Dies ist für die Öffentlichkeit, die Ihr Produkt verwendet, nicht sichtbar.

Grundsätzlich geht es darum, so viel wie möglich von der Implementierung vor neugierigen Blicken zu verbergen.

Dies ist am nützlichsten, wenn Sie ein kommerzielles Produkt haben, das als eine Reihe von Bibliotheken geliefert wird, auf die über eine API zugegriffen wird, mit der der Code des Kunden kompiliert und verknüpft wird.

Wir haben dies mit der Neufassung von getan IONAs Orbix 3.3 Produkt im Jahr 2000.

Wie von anderen erwähnt, entkoppelt die Verwendung seiner Technik die Implementierung vollständig von der Schnittstelle des Objekts. Dann müssen Sie nicht alles neu kompilieren, was verwendet wird Katze wenn Sie nur die Implementierung von ändern möchten Schnurren().

Diese Technik wird in einer Methodik namens verwendet Vertragsgestaltung.

• Weil du willst Purr() in der Lage zu sein, private Mitglieder von zu verwenden CatImpl. Cat::Purr() wäre ein solcher Zugriff nicht gestattet ohne a friend Erklärung.
• Denn dann mischt man die Verantwortlichkeiten nicht: Eine Klasse setzt um, eine Klasse leitet weiter.

Für das, was es wert ist, trennt es die Implementierung von der Schnittstelle. Dies ist normalerweise bei kleinen Projekten nicht sehr wichtig. In großen Projekten und Bibliotheken kann es jedoch verwendet werden, um die Build-Zeiten erheblich zu verkürzen.

Bedenken Sie, dass die Umsetzung von Cat kann viele Header enthalten, kann Template-Metaprogrammierung beinhalten, deren Kompilierung Zeit in Anspruch nimmt. Warum sollte ein Benutzer, der nur die verwenden möchte Cat muss das alles beinhalten? Daher werden alle notwendigen Dateien mit dem Pimpl-Idiom versteckt (daher die Vorwärtsdeklaration von CatImpl), und die Verwendung der Schnittstelle zwingt den Benutzer nicht, sie einzuschließen.

Ich entwickle eine Bibliothek für die nichtlineare Optimierung (lesen Sie “viel böse Mathematik”), die in Vorlagen implementiert ist, sodass sich der größte Teil des Codes in Headern befindet. Es dauert ungefähr fünf Minuten, um zu kompilieren (auf einer anständigen Multi-Core-CPU) und nur die Header in einem ansonsten leeren Bereich zu analysieren .cpp dauert etwa eine Minute. Jeder, der die Bibliothek verwendet, muss also jedes Mal ein paar Minuten warten, wenn er seinen Code kompiliert, was die Entwicklung ziemlich macht langweilig. Indem man jedoch die Implementierung und die Header verbirgt, bindet man nur eine einfache Schnittstellendatei ein, die sofort kompiliert wird.

Es hat nicht unbedingt etwas damit zu tun, die Implementierung vor dem Kopieren durch andere Unternehmen zu schützen – was wahrscheinlich sowieso nicht passieren würde, es sei denn, das Innenleben Ihres Algorithmus kann aus den Definitionen der Elementvariablen erraten werden (falls ja wahrscheinlich nicht sehr kompliziert und überhaupt nicht schützenswert).

Wenn Ihre Klasse das PIMPL-Idiom verwendet, können Sie vermeiden, die Header-Datei in der öffentlichen Klasse zu ändern.

Dadurch können Sie der PIMPL-Klasse Methoden hinzufügen/entfernen, ohne die Header-Datei der externen Klasse zu ändern. Sie können auch #includes zur PIMPL hinzufügen/entfernen.

Wenn Sie die Header-Datei der externen Klasse ändern, müssen Sie alles neu kompilieren, was sie enthält (und wenn es sich um Header-Dateien handelt, müssen Sie alles neu kompilieren, was sie enthält, und so weiter).

Normalerweise ist der einzige Verweis auf eine PIMPL-Klasse im Header für die Eigentümer Klasse (Katze in diesem Fall) wäre eine Forward-Deklaration, wie Sie es hier getan haben, da dies die Abhängigkeiten stark reduzieren kann.

Zum Beispiel, wenn Ihre PIMPL-Klasse hat Komplizierte Klasse als Mitglied (und nicht nur einen Zeiger oder Verweis darauf) müssten Sie dann haben Komplizierte Klasse vor seiner Verwendung vollständig definiert. In der Praxis bedeutet dies, die Datei “ComplicatedClass.h” einzuschließen (die indirekt auch alles enthalten wird Komplizierte Klasse kommt drauf an). Dies kann dazu führen, dass eine einzelne Header-Füllung viele, viele Dinge mit sich bringt, was schlecht für die Verwaltung Ihrer Abhängigkeiten (und Ihrer Kompilierungszeiten) ist.

Wenn Sie das PIMPL-Idiom verwenden, müssen Sie nur die Dinge #einschließen, die in der öffentlichen Schnittstelle Ihrer verwendet werden Eigentümer Typ (was wäre Katze Hier). Das macht die Dinge für Leute, die Ihre Bibliothek benutzen, besser und bedeutet, dass Sie sich keine Sorgen machen müssen, dass Leute von einem internen Teil Ihrer Bibliothek abhängig sind – entweder aus Versehen oder weil sie etwas tun wollen, das Sie nicht zulassen, also # Definieren Sie private public, bevor Sie Ihre Dateien einschließen.

Wenn es sich um eine einfache Klasse handelt, gibt es normalerweise keinen Grund, ein PIMPL zu verwenden, aber in Zeiten, in denen die Typen ziemlich groß sind, kann es eine große Hilfe sein (insbesondere um lange Build-Zeiten zu vermeiden).

Nun, ich würde es nicht verwenden. Ich habe eine bessere Alternative:

Datei foo.h

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

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

Datei foo.cpp

namespace {
    class FooImpl: virtual public Foo {

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

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

Hat dieses Muster einen Namen?

Als jemand, der auch Python- und Java-Programmierer ist, gefällt mir das viel mehr als das PIMPL-Idiom.

Wenn Sie den Aufruf von impl->Purr in die .cpp-Datei einfügen, können Sie in Zukunft etwas völlig anderes tun, ohne die Header-Datei ändern zu müssen.

Vielleicht entdecken sie nächstes Jahr eine Hilfsmethode, die sie stattdessen hätten aufrufen können, und so können sie den Code ändern, um diese direkt aufzurufen und überhaupt nicht impl->Purr zu verwenden. (Ja, sie könnten dasselbe erreichen, indem sie auch die eigentliche impl::Purr-Methode aktualisieren, aber in diesem Fall bleiben Sie mit einem zusätzlichen Funktionsaufruf hängen, der nichts anderes bewirkt, als die nächste Funktion der Reihe nach aufzurufen.)

Es bedeutet auch, dass der Header nur Definitionen und keine Implementierung hat, was für eine sauberere Trennung sorgt, was der springende Punkt der Redewendung ist.