Un objet proxy est un objet qui prend un autre objet en paramètre et le sauvegarde dans un de ses attributs. Quand on appelle les méthodes du proxy, le proxy appelle la même méthode de l’objet qu’il a en attribut, et retourne le résultat. Quand on set/get/delete un attribut du proxy, il fait la même chose sur l’autre objet.
Voilà une implémentation très basique d’un objet proxy en Python :
class Proxy(object): def __init__(self, obj): # L'objet passé en paramètre est # sauvegardé dans un attribut. # On le fait en utilisant # object.__setattr__, qui est le # __setattr__ du parent, et non directement # en faisant self._obj = obj # afin d'éviter une boucle infinie car # nous écrasons __setattr__ plus bas. object.__setattr__(self, "_obj", obj) # On écrase les méthodes magiques __getattribute__ # (qui est appelée quand on faire self.nom_attribut), # __delattr__ (qui est appelée quand on fait # del self.nom_attribut) et __setattr__ (qui est # appelée quand on fait self.nom_attribut = truc) def __getattribute__(self, name): return getattr(object.__getattribute__(self, "_obj"), name) def __delattr__(self, name): delattr(object.__getattribute__(self, "_obj"), name) def __setattr__(self, name, value): setattr(object.__getattribute__(self, "_obj"), name, value) |
Ca s’utilise comme ceci :
class UnObjetOrdinnaire(object): attribut = 'VALEUR !' def methode(self, param): return param * 2 objet_ordinnaire = UnObjetOrdinnaire() # on passe l'objet ordinnaire au proxy objet_proxy = Proxy(objet_ordinnaire) # Accéder à des méthodes et attribut # du proxy accède à ceux de l'objet # derrière le proxy print(objet_proxy.attribut) ## VALEUR ! print(objet_proxy.methode(3)) ## 6 # Modifier l'objet proxy modifie # l'objet derrière le proxy objet_proxy.attribut = 'une autre valeur' print(objet_ordinnaire.attribut) ## une autre valeur |
Pour un exemple vraiment à l’épreuve des balles, il faut prendre en compte tout un tas de cas particuliers, ce qui fait qu’il est bien plus rentable d’utiliser une lib solide pour ça.
Attention, un objet proxy peut très bien avoir des méthodes qui n’appellent pas celles de l’objet derrière. On même avoir des méthodes qui appellent des méthodes qui n’ont pas le même nom, ou plusieurs méthodes… Ce que vous voyez en exemple est un proxy très basique.
Pourquoi voudrait-on obtenir ce résultat ?
Plusieurs design patterns font appel à des objets proxy. Par exemple, le design pattern “adapter” consiste à créer un objet proxy qui accepte plusieurs types d’objets en paramètres afin de présenter toujours la même interface.
Imaginez que vous ayez plusieurs objets qui servent à s’authentifier :
class Login(object): _is_logged = False def is_logged(self): return self._is_logged def login(self, email, password): self._is_logged = True class LoginWithUsername(object): _is_logged = False def is_logged(self): return self._is_logged def login(self, username, password): self._is_logged = True class SignIn(object): _is_logged = False def is_logged(self): return self._is_logged def signin(self, email, password): self._is_logged = True class LoginWithKey(object): _is_logged = False key = "jfjkdlmqfjdmqsjdk" def is_logged(self): return self._is_logged def login(self, username): self._is_logged = True |
Et vous avez un algo de parsing, qui attend un objet d’authentification. Si vous mettez le code qui permet de choisir la bonne API dans l’algo de parsing, vous liez l’algo (qui n’a rien à voir avec l’authentification) à toutes ces implémentations.
Une des manières de faire, est d’utiliser un adaptateur, dont voici une esquisse :
class AuthAdapter(object): def __init__(self, obj): object.__setattr__(self, "_obj", obj) def __getattribute__(self, name): try: # Si l'attribut existe sur le proxy, on l'utilise return object.__getattribute__(self, name) except AttributeError: # Sinon on tente le coup sur l'objet derrière le proxy return getattr(object.__getattribute__(self, "_obj"), name) def login(self, id_=None, secret=None): # Le login est différent pour chaque classe, # donc on s'arrange avec. try: self._obj.login(id_, secret) except AttributeError: self._obj.signin(id_, secret) except TypeError: self._obj.login(id_) |
En gros, si on essaye d’appeler login(), il va lisser les contours et nous donner toujours la même interface, même si derrière l’objet peut marcher complètement différement. En revanche, si on appelle n’importe quel autre attribut ou méthode (par exemple is_logged, mais il pourrait y en avoir des dizaines d’autres dans la vrai vie vivante), ça tape directement dans l’objet derrière le proxy.
Donc si j’applique l’adaptateur systématiquement, quelle que soit la classe derrière, le comportement est toujours le même : j’appelle login(un id, un secret), et il se logge.
all_auth = (Login, LoginWithUsername, SignIn, LoginWithKey) for auth in all_auth: # 'auth' est une des 4 classes de login. On l'instancie et # on met l'instance derrière le proxy auth = AuthAdapter(auth()) print("Testing '%s'" % auth.__class__.__name__) print("Is logged : %s" % auth.is_logged()) # Le login se passe toujours de la même manière, quelle que soit la classe auth.login('id', 'secret') print("Is logged after logging : %s" % auth.is_logged()) |
Comme d’habitude, ceci est un exemple naval. Il est bateau quoi. Mais cela vous démontre le principe.
Le design pattern façade ressemble à l’adapter, en fait c’est une spécialisation de l’adapter. Il s’agit juste d’exposer une interface plus simple, de l’objet derrière le proxy.
Un proxy peut aussi servir à hacker une lib. Par exemple, la lib attend un objet d’une ancienne version d’une autre lib dont l’auteur a déprécié un attribut. Avec un proxy, vous pouvez toujours faire semblant que l’attribut est toujours là : enrobez l’objet dans un proxy qui possède cet attribut, tout le reste de l’API sera la même.
Un proxy peut également être utile si vous voulez effectuer des actions quand l’objet est manipulé.
import logging class ProxyLogger(object): def __init__(self, obj): object.__setattr__(self, "_obj", obj) def __getattribute__(self, name): obj = object.__getattribute__(self, "_obj") # On lance un warning à chaque accès à un attribut de l'objet # derrière le proxy logging.warning("%s.%s has been called" % (obj.__class__.__name__, name)) return getattr(obj, name) |
Maintenant, supposons que vous avez un objet d’une lib externe (que vous ne pouvez donc pas modifier) sur lequel vous avez besoin d’infos :
class ObjetExterne(object): def ahahah(self): pass o = ProxyLogger(ObjetExterne()) o.ahahah() ## WARNING:root:ObjetExterne.ahahah has been called |
Vous pouvez refiler le proxy à n’importe quel objet de sa lib d’origine, si le proxy est bien fait, elle ne vera pas la différence.
On finit sur une note culture, puisque le pattern decorator utilise souvent aussi un proxy. Cette fois d’une fonction sur un autre objet (en générale une autre fonction). Mais le principe est le même. Donc quand vous voyez @un_decorateur, il est peut être en train d’appliquer un proxy à la fonction.
D’ailleurs on dit souvent que le proxy décore l’objet qui est derrière.
La première chose qui me vient à l’esprit c’est de faire un proxy cache également afin de d’éviter des appels gourmands de l’objet sous-jacent.