Monkey-Patch
Cet article est une ébauche concernant l’informatique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
Un Monkey-Patch (aussi écrit Monkey Patch, MonkeyPatch) traduit par modification-singe consiste en la modification ou l'extension sans toucher au code source original. Cela est possible dans les langages de programmation dynamiques. Cela peut être appliqué à la modification des logiciels de base d'un système si ce système autorise la gestion de paquets.
La notion se nomme aussi :
- Guerilla patch ;
- Extension des classes précédemment déclarées ;
- Réouverture des classes ;
- Hijacking.
Étymologie[modifier | modifier le code]
Il s'agissait à l'origine de modification dynamique et furtive de code au moment de son exécution, cela sans sécurité, par des bouts de code extérieurs. Dans certaines applications (comme Zope 2), ces bouts de code interagissent les uns avec les autres avec pour conséquence de créer une compétition à qui modifiera réellement le code. Dans le contexte originel donc, plusieurs bouts de codes entraient en compétition pour la modification du code original, d'où la notion de guérilla et l'utilisation du terme Guerilla Patch.
Mais le côté dangereux de la modification dynamique et le fait que ces codes constituent une menace pour un système, a entraîné l'utilisation fautive du terme Gorilla Patch, du fait de la similarité de consonance entre guerilla (guérilla) et gorilla (gorille) et de la connotation de gorille avec menace.
Les tenants des aspects positifs possibles de la modification dynamique de code, afin de diminuer la connotation de menace, ont commencé à utiliser le terme Monkey-Patch (singe au lieu de gorille) qui est resté le seul en usage.
Applications[modifier | modifier le code]
La modification-singe est utilisée pour :
- Remplacer des méthodes, attributs ou fonctions au moment de l'exécution, notamment pour les tests ;
- Modifier ou étendre le comportement ou l'apparence d'un produit pour une tierce personne, sans maintenir sa propre copie du code source ;
- Appliquer un patch, au moment de l'exécution, à un objet en mémoire, sans l'appliquer au code source sur disque ;
- Corriger un comportement ou un trou de sécurité existant dans le code source original (c'est le cas de la distribution de corrections par ajout dans la plate-forme Ruby on Rails).
Pièges[modifier | modifier le code]
L'utilisation de la modification-singe comporte les problèmes suivants :
- Si le produit ou le paquet modifié est remplacé par une nouvelle version, celle-ci détruira sans doute le patch ;
- Si deux modules essaient de faire une modification-singe sur une même méthode, seule la dernière gagnera la compétition et l'autre n'aura aucun effet ;
- Si la modification-singe crée une différence entre le code source original et celui qui s'exécute, la résolution de conflits et de bogues devient très difficile, en particulier lorsque l'on n'est pas l'auteur du patch ;
- L'utilisation de modifications-singe peut conduire à des problèmes de mise à jour car les modifications faites sur le code peuvent se fonder sur des postulats à l'origine exacts mais peu à peu invalidés par l'évolution du code.
