Delegation pattern avec Ruby part 1
Babacar est un jeune Développeur/Entrepreneur qui vient de lancer une solution e-commerce qui est entrain de connaitre un succès. Mais actuellement, il gère tout en même temps : le design de l’application, la création des maquettes pour la communication, le développement de l’application mobile, et le backend qu’il fait en ruby.
Il s’occupe aussi des démarches commerciales et de la comptabilité (enregistrement quotidien des opérations, préparations des déclarations fiscales, traitement des factures … )
Au fur des mois, Babacar est débordé dans tous les sens, il décide de prendre un designer en freelance pour travailler sur le parcours et la partie UI/UX de l’application . Il recrute Alioune un développeur Fullstack et Ousmane un comptable.
Il confie à Alioune le développement de l’API backend. À Ousmane, la comptabilité et il lui charge aussi une partie des démarches commerciales.
Il vient de les charger de missions dont il avait la charge.
Vous en conviendriez avec moi que là, il a fait de la DELEGATION
Il a transféré une charge, fonction ou mission à quelqu’un d’autre.
En programmation, c’est exactement ce qu’on va faire avec le design pattern Delegation.
Transférer la charge ou la responsabilité à quelqu’un d’autre.
En somme, on a une classe chargée de faire un certain nombre de choses mais pour ne pas la surcharger, on décide de déléguer certaines de ses responsabilités à d’autres classes.
Le Problème
Dans la solution e-commerce de Babacar, on dit qu’un produit est caractérisé par son nom, son sku et son prix. Ce qui fait qu’on a la classe suivante qui caractérise un produit.
En échangeant avec les clients, il se rend compte que ses clients peuvent avoir plusieurs variations ou variants d’un même produit. Et que les variations peuvent avoir des prix différents. Il s’est rendu compte aussi que quand on parle de produit, il y a un variant considéré comme master qui doit être crée à la base.
Il demande à Alioune de faire la mise à jour.
NB: Un variant représente toujours le même produit mais se présente différemment. Par exemple pour un produit T-shirt. Le t-shirt bleu avec la taille XL est une variation de même que le produits vert de taille L.
Quand les clients essayent de récupérer le prix d’un produit, il tombe sur l’erreur suivante : undefined method price
On ne peut plus faire directement product.price pour récupérer le prix d’un produit.
Mais quand même les clients veulent toujours pouvoir accéder au prix à partir du produit mais ce sera le prix du variant master qui sera affiché.
Les Solutions
Alioune fournit la solution suivante : Il définit dans la classe Produit la méthode ci-dessous. Mais, on lui informe qu’on doit pouvoir accéder à d’autres propriétés comme le sku et ultérieurement les options types, la taille, le poids, la hauteur … et ce ne sera pas très élégant de rajouter à chaque fois une nouvelle méthode.
Pour corriger cela, Babacar donne une piste à Alioune en lui demandant de faire en sorte que quand on appelle price dans le produit, que ce soit la méthode du variant master qui est appelée. Et il faut que cela soit généralisé à tous les autres méthodes tant qu’elles existent chez le variant master.
Et pour cela, Alioune sait que sur Ruby, on a une fonction qui permet d’avoir ce mécanisme avec une méthode appelée method_missing. Il implémente ainsi la foncti
on suivante :
Il se retrouve ainsi avec le code suivant
It Works !
Même si on n’a pas de méthode price ou sku dans la classe produit, on parvient quand même à appeler la méthode sur le master pour retourne le prix.
Quand on appelle la méthode sur le produit, si l’objet ne trouve pas la méthode définie, il fait appelle à la fonction method_missing où nous on se charge de récupérer le master et de regarder si le master a cette fonction définie avant de l’appeler.
