-Bonjour à tous.
Dans cette vidéo, on va s'intéresser aux refactorings
et à leur application à plusieurs niveaux dans un environnement Pharo.
Les refactorings ont été introduits dans Smalltalk en 1995
et vous permettent de gérer les méthodes,
classes et liens entre eux sans avoir à réécrire de code.
Tout d'abord, pour regarder les refactorings sur les classes,
on va s'intéresser à notre Counter
qu'on a chargé depuis le redo de la semaine 2.
Vous pouvez voir que les tests sont toujours verts.
Si on fait clic droit sur notre classe,
on va avoir, déjà, le Rename,
qui est un des refactorings les plus utiles,
qui a sa catégorie à part.
On va aussi avoir d'autres refactorings,
par exemple pour ajouter, insérer une sous-classe,
changer la classe de package, etc.
On va simplement le renommer "Counter2", "OK".
Vous pouvez voir qu'ici, il n'y a eu aucun incident.
Les tests sont redevenus gris, il y a eu des changements.
Dans les tests, on peut voir que, maintenant,
toutes les occurrences de "Counter" ont été changées en "Counter2".
On les réexécute, les tests marchent toujours.
C'est un des niveaux de refactoring.
Maintenant, on va s'intéresser aux niveaux de refactoring
sur les méthodes.
Par exemple, on va aller vers "increment",
et, si on fait clic droit dessus,
on peut voir qu'on a toujours notre Rename,
mais on a beaucoup plus d'autres refactorings.
"Push up", "Push down", ça vous permet de déplacer
votre méthode dans la hiérarchie de classe.
Vous pouvez ajouter un argument, déplacer la méthode du côté classe,
la changer de package, l'enlever, etc.
Nous, ce qu'on va faire, c'est la renommer.
Si on renomme notre méthode "increment" en "increment2"
et qu'on clique sur "Rename", on va avoir un warning qui s'ouvre,
parce qu'on va modifier neuf implémenteurs.
Là, on n'a qu'un implémenteur d'increments, il y a un souci.
Je vous rappelle que le raccourci pour aller voir les implémenteurs,
c'est Cmd+M.
Il y a neuf implémenteurs d'increments,
et il y en a dans des packages, des classes
qui ne nous intéressent pas et qu'on n'a pas envie de changer.
Donc, pour limiter les actions
qu'on va avoir sur notre petit package,
on va créer une scope.
Soit on fait clic droit, "Set up scope"
avec seulement ce package,
soit on peut cliquer sur le bouton "Scoped View".
Maintenant, quand on fait clic droit, "Rename",
on change notre "increment" en "increment2",
on clique sur "Rename".
Cette fenêtre s'ouvre et nous présente tous les changements
que ce refactoring va induire.
Donc, on va avoir la création de la méthode "increment2"
dans la classe "Counter2",
on va avoir un changement dans le test,
qui va passer de "increment" à "increment2",
et la méthode "increment" de base va être supprimée.
C'est exactement ce qu'on veut.
Donc, on va cliquer sur "Apply".
Notre méthode "increment2" a été changée ici.
On voit qu'elle a été changée ici. On peut relancer le test.
On a maintenant deux appels à "increment2".
C'est extrêmement pratique.
Un autre niveau de refactoring, c'est sur les protocoles.
Donc, on peut aussi renommer, en rajouter un,
et vous pouvez catégoriser toutes les méthodes
qui n'ont pas été catégorisées
ou enlever les protocoles qui ne catégorisent aucune méthode.
Ça peut arriver si vous avez tagué les méthodes
et que vous les avez supprimées sans supprimer le protocole associé.
Un dernier niveau de refactoring qui est intéressant
et qu'on va regarder dans ce test-là,
c'est qu'on peut sélectionner, surligner
une partie du corps de la méthode,
faire clic droit, aller dans "Source code",
et là, vous pouvez voir qu'on va avoir aussi des refactorings,
"Rename", "Add argument", etc.
Un refactoring qui peut être intéressant, c'est "Extract Method",
qui va prendre ce petit bout de code.
On clique sur "Extract Method", on l'appelle "startingAt5".
"Rename".
Vous pouvez voir que la méthode a été créée.
Là, ce n'est pas utile,
on va créer une méthode dans notre classe de test.
Ce n'est pas recommandé.
Mais vous pouvez voir que cette méthode-là
va maintenant faire ce qu'on avait surligné tout à l'heure,
et elle a été remplacée par "self"et le nom de la méthode
dans ce bout de code source.
Voilà, vous avez vu quatre niveaux de refactorings
qui sont extrêmement intéressants.
Je vous encourage à apprendre à les utiliser
et à ne pas hésiter à vous en servir, car ça va accélérer...
Au lieu de devoir supprimer puis réécrire votre méthode,
vous n'avez qu'à la renommer,
vous pouvez la déplacer du côté classe, la changer de package, de classe.
C'est vraiment quelque chose que je vous encourage à utiliser.