Die Technik wurde 1989 als “F-gebundene Quantifizierung” formalisiert. [2] Der Name “CRTP” wurde 1995 unabhängig von Jim Coplien geprägt[3], der ihn in einigen der frühesten C++-Vorlagencodes sowie in Codebeispielen beobachtet hatte, die Timothy Budd in seiner Multiparadigmensprache Leda erstellthatte. [4] Es wird manchmal als “Upside-Down Inheritance”[5][6] bezeichnet, da es die Erweiterung von Klassenhierarchien durch Ersetzen verschiedener Basisklassen ermöglicht. Ein Problem bei statischem Polymorphismus besteht darin, dass abgeleitete Klassen ohne Verwendung einer allgemeinen Basisklasse wie AbstractShape aus dem obigen Beispiel nicht homogen gespeichert werden können, d. h. verschiedene Typen, die von derselben Basisklasse abgeleitet wurden, in demselben Container. Beispielsweise funktioniert ein Container, der als std::vector`Shape*> definiert ist, nicht, da Shape keine Klasse ist, sondern eine Vorlage, die eine Spezialisierung benötigt. Ein Container, der als std::vector`Shape*> definiert ist, kann nur Kreise speichern, nicht Quadrate. Dies liegt daran, dass jede der von der CRTP-Basisklasse Shape abgeleiteten Klassen ein eindeutiger Typ ist. Eine häufige Lösung für dieses Problem besteht darin, von einer freigegebenen Basisklasse mit einem virtuellen Destruktor zu erben, wie dem obigen AbstractShape-Beispiel, das die Erstellung eines std::vector-AbstractShape*> ermöglicht. In der objektorientierten Programmierung ist die Vorlagenmethode eines der Verhaltensmuster, die von Gamma et al.[1] im Buch Design Patterns identifiziert werden. Die Vorlagenmethode ist eine Methode in einer übergeordneten Klasse, in der Regel eine abstrakte Superklasse, und definiert das Skelett einer Operation in Form einer Reihe von übergeordneten Schritten. Diese Schritte werden selbst durch zusätzliche Hilfsmethoden in derselben Klasse wie die Vorlagenmethode implementiert.

Dieses Muster ist ein Beispiel für die Umkehrung der Kontrolle, da der Code auf hoher Ebene nicht mehr bestimmt, welche Algorithmen ausgeführt werden sollen. Stattdessen wird zur Laufzeit ein Algorithmus auf niedrigerer Ebene ausgewählt. Wenn das benannte Parameterobjektmuster auf eine Objekthierarchie angewendet wird, können die Dinge schief gehen. Angenommen, wir haben eine solche Basisklasse: Jedes Mal, wenn ein Objekt der Klasse X erstellt wird, wird der Konstruktor von counter aufgerufen, der sowohl die erstellte als auch die lebendige Anzahl erhöht. Jedes Mal, wenn ein Objekt der Klasse X zerstört wird, wird die lebendige Anzahl verringert. Es ist wichtig zu beachten, dass Gegen und Gegen zwei separate Klassen sind, und deshalb werden sie getrennte Zählungen von X und Y behalten.