"Externo" en este contexto significa "observable para los usuarios". Los usuarios pueden ser humanos en el caso de una aplicación u otros programas en el caso de una API pública.
Por lo tanto, si mueve el método M de la clase A a la clase B, y ambas clases están dentro de una aplicación, y ningún usuario puede observar ningún cambio en el comportamiento de la aplicación debido al cambio, entonces puede llamarlo correctamente refactorización.
Si, OTOH, algún otro subsistema / componente de nivel superior cambia su comportamiento o se rompe debido al cambio, eso es (generalmente) observable para los usuarios (o al menos para los registros de verificación de los administradores de sistemas). O si sus clases eran parte de una API pública, puede haber un código de terceros que depende de que M sea parte de la clase A, no B. Entonces, ninguno de estos casos es refactorizado en sentido estricto.
hay una tendencia a llamar a cualquier reproceso de código como refactorización, lo cual, supongo, es incorrecto.
De hecho, es una consecuencia triste pero esperada de la refactorización que se pone de moda. Los desarrolladores han estado haciendo modificaciones de código de manera ad hoc durante años, y ciertamente es más fácil aprender una nueva palabra de moda que analizar y cambiar hábitos arraigados.
Entonces, ¿cuál es la palabra correcta para modificaciones que cambian el comportamiento externo?
Yo lo llamaría rediseño .
Actualizar
Muchas respuestas interesantes sobre la interfaz, pero ¿no cambiaría la refactorización de métodos para cambiar la interfaz?
¿De que? Las clases específicas, sí. Pero, ¿son estas clases directamente visibles para el mundo exterior de alguna manera? Si no, porque están dentro de su programa y no son parte de la interfaz externa (API / GUI) del programa , ningún cambio realizado allí es observable por partes externas (a menos que el cambio rompa algo, por supuesto).
Siento que hay una pregunta más profunda más allá de esto: ¿existe una clase específica como una entidad independiente por sí misma? En la mayoría de los casos, la respuesta es no : la clase solo existe como parte de un componente más grande, un ecosistema de clases y objetos, sin el cual no se puede instanciar y / o es inutilizable. Este ecosistema no solo incluye sus dependencias (directas / indirectas), sino también otras clases / objetos que dependen de él. Esto se debe a que sin estas clases de nivel superior, la responsabilidad asociada con nuestra clase puede no tener sentido / inútil para los usuarios del sistema.
Por ejemplo, en nuestro proyecto que se ocupa del alquiler de autos, hay un Chargeclase. Esta clase no tiene utilidad para los usuarios del sistema por sí sola, porque los agentes de estaciones de alquiler y los clientes no pueden hacer mucho con un cargo individual: se ocupan de los contratos de contrato de alquiler en su conjunto (que incluyen un montón de diferentes tipos de cargos) . Los usuarios están principalmente interesados en la suma total de estos cargos, que deben pagar al final; el agente está interesado en las diferentes opciones de contrato, la duración del alquiler, el grupo de vehículos, el paquete de seguro, los artículos adicionales, etc., etc. seleccionados (a través de reglas comerciales sofisticadas) que rigen qué cargos están presentes y cómo se calcula el pago final fuera de estos. Y los representantes de los países / analistas comerciales se preocupan por las reglas comerciales específicas, su sinergia y sus efectos (sobre los ingresos de la empresa, etc.).
Recientemente reescribí esta clase, renombrando la mayoría de sus campos y métodos (para seguir la convención de nomenclatura estándar de Java, que nuestros predecesores descuidaron por completo). También planeo refactorizaciones adicionales para reemplazar Stringy charcampos con más apropiados enumy booleantipos. Sin duda, todo esto cambiará la interfaz de la clase, pero (si hago mi trabajo correctamente), nada de eso será visible para los usuarios de nuestra aplicación. A ninguno de ellos le importa cómo se representan los cargos individuales, aunque seguramente conocen el concepto de cargo.. Podría haber seleccionado como ejemplo otras cien clases que no representan ningún concepto de dominio, por lo que son incluso conceptualmente invisibles para los usuarios finales, pero pensé que es más interesante elegir un ejemplo donde haya al menos algo de visibilidad a nivel de concepto. Esto muestra muy bien que las interfaces de clase son solo representaciones de conceptos de dominio (en el mejor de los casos), no lo real *. La representación se puede cambiar sin afectar el concepto. Y los usuarios solo tienen y entienden el concepto; Es nuestra tarea hacer el mapeo entre concepto y representación.
* Y se puede agregar fácilmente que el modelo de dominio, que representa nuestra clase, es solo una representación aproximada de algo "real" ...