"Externe" dans ce contexte signifie "observable par les utilisateurs". Les utilisateurs peuvent être humains dans le cas d'une application, ou d'autres programmes dans le cas d'une API publique.
Donc, si vous déplacez la méthode M de la classe A à la classe B, et que les deux classes sont au cœur d'une application, et qu'aucun utilisateur ne peut observer de changement dans le comportement de l'application en raison du changement, vous pouvez à juste titre l'appeler refactoring.
Si, OTOH, un autre sous-système / composant de niveau supérieur change de comportement ou se casse en raison du changement, cela est en effet (généralement) observable par les utilisateurs (ou au moins par les administrateurs système qui vérifient les journaux). Ou si vos classes faisaient partie d'une API publique, il peut y avoir du code tiers qui dépend du fait que M fasse partie de la classe A, pas B. Donc, aucun de ces cas n'est refactoring au sens strict.
il y a une tendance à appeler toute refonte de code comme une refactorisation qui est, je suppose, incorrecte.
En effet, c'est une conséquence triste mais attendue du refactoring devenu à la mode. Les développeurs ont fait un remaniement de code de manière ad hoc depuis des lustres, et il est certainement plus facile d'apprendre un nouveau mot à la mode que d'analyser et de changer des habitudes enracinées.
Alors, quel est le bon mot pour des retouches qui changent le comportement externe?
J'appellerais cela une refonte .
Mise à jour
Beaucoup de réponses intéressantes sur l'interface, mais le fait de ne pas déplacer la refactorisation de méthode ne changerait-il pas l'interface?
De quoi? Les classes spécifiques, oui. Mais ces classes sont-elles directement visibles du monde extérieur d'une manière ou d'une autre? Sinon - car ils sont à l'intérieur de votre programme, et ne font pas partie de l'interface externe (API / GUI) du programme - aucune modification apportée n'est observable par des parties externes (à moins que la modification ne casse quelque chose, bien sûr).
Je pense qu'il y a une question plus profonde au-delà de cela: une classe spécifique existe-t-elle en tant qu'entité indépendante par elle-même? Dans la plupart des cas, la réponse est non : la classe n'existe que dans le cadre d'un composant plus large, un écosystème de classes et d'objets, sans lequel elle ne peut pas être instanciée et / ou est inutilisable. Cet écosystème n'inclut pas seulement ses dépendances (directes / indirectes), mais aussi d'autres classes / objets qui en dépendent. En effet, sans ces classes de niveau supérieur, la responsabilité associée à notre classe peut être vide de sens / inutile pour les utilisateurs du système.
Par exemple, dans notre projet qui traite de la location de voitures, il y a un Chargeclasse. Cette classe n'a aucune utilité pour les utilisateurs du système en elle-même, car les agents de location et les clients ne peuvent pas faire grand-chose avec une charge individuelle: ils traitent les contrats de location dans leur ensemble (qui incluent un tas de différents types de charges) . Les utilisateurs sont surtout intéressés par la somme totale de ces frais, qu'ils doivent payer au final; l'agent est intéressé par les différentes options du contrat, la durée de la location, le groupe de véhicules, le package d'assurance, les articles supplémentaires, etc. etc. sélectionnés, qui (via des règles commerciales sophistiquées) régissent les frais présents et la manière dont le paiement final est calculé hors de ceux-ci. Et les représentants des pays / analystes commerciaux se soucient des règles commerciales spécifiques, de leur synergie et de leurs effets (sur les revenus de l'entreprise, etc.).
Récemment, j'ai refactorisé cette classe, renommant la plupart de ses champs et méthodes (pour suivre la convention de nommage Java standard, qui était totalement négligée par nos prédécesseurs). Je prévois aussi refactoring plus pour remplacer Stringet charchamps avec plus appropriés enumet booleantypes. Tout cela va certainement changer l'interface de la classe, mais (si je fais correctement mon travail), rien ne sera visible aux utilisateurs de notre application. Aucun d'entre eux ne se soucie de la façon dont les charges individuelles sont représentées, même s'ils connaissent sûrement le concept de charge. J'aurais pu sélectionner comme exemple une centaine d'autres classes ne représentant aucun concept de domaine, donc étant même conceptuellement invisible pour les utilisateurs finaux, mais j'ai pensé qu'il était plus intéressant de choisir un exemple où il y a au moins une certaine visibilité au niveau du concept. Cela montre bien que les interfaces de classe ne sont que des représentations de concepts de domaine (au mieux), pas la vraie chose *. La représentation peut être modifiée sans affecter le concept. Et les utilisateurs ont et comprennent seulement le concept; c'est notre tâche de faire la correspondance entre concept et représentation.
* Et on peut facilement ajouter que le modèle de domaine, que notre classe représente, n'est lui-même qu'une représentation approximative de quelque "chose réelle" ...