"Esterno" in questo contesto significa "osservabile per gli utenti". Gli utenti possono essere umani nel caso di un'applicazione o altri programmi nel caso di un'API pubblica.
Quindi, se sposti il metodo M dalla classe A alla classe B, ed entrambe le classi si trovano all'interno di un'applicazione e nessun utente può osservare alcun cambiamento nel comportamento dell'app dovuto alla modifica, puoi giustamente chiamarlo refactoring.
Se, OTOH, qualche altro sottosistema / componente di livello superiore modifica il suo comportamento o si interrompe a causa della modifica, ciò è effettivamente (di solito) osservabile dagli utenti (o almeno dai registri di controllo degli amministratori di sistema). O se le tue classi facevano parte di un'API pubblica, potrebbe esserci un codice di terze parti là fuori che dipende dal fatto che M sia parte della classe A, non B. Quindi nessuno di questi casi è refactoring in senso stretto.
c'è la tendenza a chiamare qualsiasi rielaborazione del codice come refactoring che, credo, non è corretto.
In effetti, è una conseguenza triste ma attesa che il refactoring diventi di moda. Gli sviluppatori hanno lavorato alla rielaborazione del codice in modo ad hoc per anni ed è sicuramente più facile imparare una nuova parola d'ordine che analizzare e cambiare abitudini radicate.
Quindi qual è la parola giusta per rielaborazioni che cambiano il comportamento esterno?
Lo chiamerei riprogettazione .
Aggiornare
Molte risposte interessanti sull'interfaccia, ma spostare il refactoring del metodo non cambierebbe l'interfaccia?
Di cosa? Le classi specifiche, sì. Ma queste classi sono direttamente visibili al mondo esterno in qualche modo? In caso contrario, poiché si trovano all'interno del programma e non fanno parte dell'interfaccia esterna (API / GUI) del programma , nessuna modifica apportata è osservabile da parti esterne (a meno che la modifica non rompa qualcosa, ovviamente).
Sento che al di là di questo c'è una domanda più profonda: esiste una classe specifica come entità indipendente da sola? Nella maggior parte dei casi, la risposta è no : la classe esiste solo come parte di un componente più grande, un ecosistema di classi e oggetti, senza il quale non può essere istanziato e / o è inutilizzabile. Questo ecosistema non include solo le sue dipendenze (dirette / indirette), ma anche altre classi / oggetti che dipendono da esso. Questo perché senza queste classi di livello superiore, la responsabilità associata alla nostra classe potrebbe essere insignificante / inutile per gli utenti del sistema.
Ad esempio nel nostro progetto che si occupa di noleggio auto, esiste un Chargeclasse. Questa classe non è di alcuna utilità per gli utenti del sistema da sola, perché gli agenti di stazione di noleggio e i clienti non possono fare molto con un addebito individuale: si occupano dei contratti di contratto di noleggio nel loro insieme (che comprendono un sacco di diversi tipi di addebiti) . Gli utenti sono per lo più interessati alla somma totale di questi addebiti, che dovranno pagare alla fine; l'agente è interessato alle diverse opzioni di contratto, alla durata del noleggio, al gruppo di veicoli, al pacchetto assicurativo, agli articoli extra ecc. ecc. selezionati, che (tramite sofisticate regole commerciali) regolano quali spese sono presenti e come viene calcolato il pagamento finale di questi. E i rappresentanti dei paesi / analisti aziendali si preoccupano delle regole aziendali specifiche, delle loro sinergie ed effetti (sul reddito dell'azienda, ecc.).
Recentemente ho refactored questa classe, rinominando la maggior parte dei suoi campi e metodi (per seguire la convenzione standard di denominazione Java, che è stata totalmente trascurata dai nostri predecessori). Pianifico anche ulteriori rifatturazioni da sostituire Stringe charcampi con più appropriati enume booleantipi. Tutto ciò cambierà sicuramente l'interfaccia della classe, ma (se svolgo correttamente il mio lavoro) nessuno di questi sarà visibile agli utenti della nostra app. Nessuno di loro si preoccupa di come sono rappresentate le singole accuse, anche se sicuramente conoscono il concetto di accusa. Avrei potuto selezionare ad esempio un centinaio di altre classi che non rappresentavano alcun concetto di dominio, quindi essendo anche concettualmente invisibile agli utenti finali, ma ho pensato che fosse più interessante scegliere un esempio in cui vi sia almeno una certa visibilità a livello di concetto. Questo dimostra bene che le interfacce di classe sono solo rappresentazioni di concetti di dominio (nella migliore delle ipotesi), non la cosa reale *. La rappresentazione può essere modificata senza influire sul concetto. E gli utenti hanno solo e comprendono il concetto; è nostro compito fare la mappatura tra concetto e rappresentazione.
* E si può facilmente aggiungere che il modello di dominio, che la nostra classe rappresenta, è esso stesso solo una rappresentazione approssimativa di alcune "cose reali" ...