psykoko : le principe s'approche assez du
Delegation Pattern ou du
Proxy Pattern.
Une classe encapsulante, c'est une classe qui "encapsule", c'est à dire qui en cache une autre aux yeux des autres classes du projet. L'idée étant de l'isoler, d'être sûr qu'elle n'interagit qu'avec la classe encapsulante. Ceci permet dès lors de ne pas devoir s'inquiéter de son évolution : si la classe isolée est développée par un tiers, elle pourrait être amenée à changer son interface publique. Si elle est encapsulée, il n'y a qu'une classe à réécrire dans ton projet : la classe encapsulante.
Dans mon cas, comme je n'ai aucun contrôle sur le développement de Smarty, ça me permet de savoir que je pourrai mettre à jour sans trop de soucis quand une nouvelle version sortira. Par ailleurs, si je veux changer de moteur de template, je peux le faire facilement, il suffit de changer mes appels de fonctions dans ma classe encapsulante.
Ishiro : je n'hérite pas de la classe Smarty (c'est peu pratique), mais le principe est plus ou moins celui que tu décris. Toutes les méthodes dont j'ai besoin pour manipuler mon template sont implémentées dans la classe encapsulante, que j'appelle Display. Celle-ci contient une instance de Smarty (c'est un lien de type "composition", pour ceux qui font de l'UML). Lorsqu'un autre objet appelle une méthode de Display, celle-ci appelle la ou les méthodes de Smarty nécessaires.