Refactoring
Le refactoring c’est l’amélioration du code en conservant les fonctionnalitées déjà présente, on simplifie et on s’assure que le code sera facile a modifier dans le future.
Code smells
Le terme “code smells” signifie qu’il y a possiblement un problème dans le code. Avec de l’expérience, un bon programmeur est capable de détecter les “code smells” et d’appliquer certaines solutions pour y remédier.
Code smells communs:
- Duplication
- Longue méthode
- Méthode qui prend beaucoup de paramètres
- Couplage fort
- Feature Envy
- Longue Classe
- violation de Tell don’t ask
Quelques exemples
Considérer le code suivant
Liquid error: No such file or directory - posix_spawnp
La classe RapportDeCommande est assez simple, le code n’est pas si mal et tout fonctionne normalement. Mais il y a plusieurs “code smells”.
La méthode totalDesVentesDansLIntervalDeTemps est le plus évident. Elle est beaucoup trop longue, elle fait trop de travail.
La méthode ne devrait pas avoir la responsabilité de produire l’arraylist commandesDansLIntervalDeTemps. On va créer une méthode privée pour s’en occuper.
Liquid error: No such file or directory - posix_spawnp
Notre code est maintenant beaucoup plus facile à lire et à comprendre. On peu aussi facilement réutiliser commandesDansLIntervalDeTemps.
Tell don’t ask
Notre nouvelle méthode n’est pas parfaite, vous aurez remarqué que la méthode interroge une commande et prend une décision selon la date.
Ceci est une violation du concept orienté-objet Tell don’t ask. Selon ce concept, il est préférable d’envoyer un message à un objet et de le laisser faire le travail (Tell), plutôt que de questionner un objet sur son état et de prendre une décision a sa place (Ask).
La programmation orienté-objet est basé sur l’union d’objets et de donnés.
On devrait demander à l’objet commande “Est-ce que tu es dans cet interval” plutôt que “Quelle valeur a ton attribut date”?
Le code est donc réécrit comme ceci:
Liquid error: No such file or directory - posix_spawnp
Liquid error: No such file or directory - posix_spawnp
Data Clumps
Vous remarquez que nous utilisons date_debut et date_fin à plusieurs endroits et qu’ils sont toujours utilisés en paire. Il y a un nom pour ce code smell: Data Clumps. Quand 2 ou plusieurs données sont toujours utilisé ensemble, elles devraient probablement être regroupé dans une classe.
On va donc créer une nouvelle classe Interval.
Liquid error: No such file or directory - posix_spawnp
Et on va utiliser des objets de cette classe plutôt que date_debut et date_fin.
Un grand nombre de programmeurs débutants et intermédiaires n’osent pas assez créer des petites classes.
Créer plusieurs petites classes qui n’ont qu’une responsabilité. Est pourtant un moyen efficace de produire du code de qualité.
Savoir si la commande est dans un intervalle n’est pas une bonne responsabilité pour la classe commande, cette responsabilité serait mieux dans la classe intervalle. En plus, on pourrait vouloir réutiliser intervalle avec d’autres objets.
Liquid error: No such file or directory - posix_spawnp
Liquid error: No such file or directory - posix_spawnp
Beaucoup mieux, il reste encore un petit problème dans notre méthode totalDesVentesDansLIntervalDeTemps. On peut imaginer vouloir calculer la somme d’un ensemble de commande dans un différent contexte.
On va donc extraire une méthode totalDesVentes qui prend un ensemble (Array) de commandes en paramètre.
Voici notre résultat final :
Liquid error: No such file or directory - posix_spawnp
Référence:
Articles:
- Menu Refactor de Netbeans
- C2 wiki - Code Smell
- Coding Horror - Code Smells
- The Single Responsibility Principle
- The Pragmatic Programmer Blog - Tell don’t ask.
- Martin Fowler - Data Clumps
Livres:
- Refactoring: Improving the Design of Existing Code
- Working Effectively with Legacy Code
- Clean Code: A Handbook of Agile Software Craftsmanship
Vidéo: * Therapeutic Refactoring