Problème :
Il existe certains refactoring de code Java dans les applications de longue durée, qui sont dues à des API héritées obsolètes, qui doivent être remplacées par les dernières API / bibliothèques.
nous mettons à niveau le serveur AEM de la version 6.2 vers la version 6.3, les bibliothèques Apache Sling Commons JSON sont obsolètes et nous devrons peut-être remplacer ses références par de nouveaux appels d'API GBS ou org.json.
Ces scénarios impliquent un refactoring de code complet. toucher toutes les couches de classes, pour supprimer les références de l'API obsolète et le remplacer par le nouveau.
Solution :
De tels problèmes peuvent être traités d'une manière plus élégante, avec un nouveau motif de refactorisation de code, comme détaillé ci-dessous
Steps :
- Liste toutes les références API obsolètes à travers les projets.
- Créer un nouvel ensemble de classes API, avec les mêmes noms de classe et les noms de méthodes, mais avec une nouvelle structure de package – la plupart du temps en tant que mon package dans le projet.
- Modifiez toutes les instructions d'importation des classes obsolètes dans le package nouvellement créé dans le package commun.
- Dans la nouvelle bibliothèque créée, écrivez votre référence logique à la nouvelle API. Dans quelques cas, il s'agirait d'un appel direct à la nouvelle bibliothèque, mais dans quelques cas, nous devrons peut-être traiter certaines conversions entre les classes.
Exemple :
- Pour remplacer les références de " ] apache.sling.commons.json.JSONObject "classes.
- Créer un nouveau paquet util.
- Créer des méthodes avec le même nom que dans la bibliothèque obsolète.
- Modifier les instructions Import dans la base de code existante, en supprimant la classe apache sling commons et en important la classe utilitaire nouvellement ajoutée. Ce serait le seul changement dans les classes d'application.
Remove: 
Ajouter: 
Avantages
- Facilité de codage
- Pas de duplication de code dans le projet
- Plus élégant
- Facilité d'examen
- Facilité de test unitaire
- Facilité de débogage / maintenance
- Cette nouvelle API peut être construit en tant que fichier jar commun distinct et importé dans d'autres projets également
Challenge:
En raison de contraintes de temps, il peut être impossible de collecter toute la référence en une seule fois. Cela peut être résolu si nous avons la nouvelle bibliothèque commune ouverte pour l'ajout de nouvelles méthodes, au fur et à mesure que nous rencontrons les anciennes références.
Alternativement, nous pouvons adopter une approche progressive pour refactoriser pour relever ce défi. Dans ce cas, nous créerons de toute façon une nouvelle bibliothèque dans la première phase, et dans la suite, nous ajouterons de nouvelles classes et méthodes si nécessaire et identifiées.