Cómo invertir los parámetros de tipo en Java

Question

Tengo una clase A<X, Y> y quiero refactorizarla a A<Y, X> de modo que todas las referencias a ella se modifiquen también.

Answer 1

No creo que se ha implementado en Eclipse todavía. Es una refactorización más bien raro, aunque ...

Pero si su jerarquía de tipos por debajo A no es demasiado complejo, sin embargo, tratar de usar esta expresión regular-buscar-reemplazar (donde A|B|C significa A y todos los subtipos de A, por ejemplo B y C):

\b(A|B|C)<\s*(\w+)\s*,\s*(\w+)\s*> 

actualización:, ya que desea que coincida con las cosas más sofisticado, prueba este (sin las artificiales saltos de línea):

\b(A|B|C)< 
    \s*((?:\w+|\?)(?:\s+(?:extends|super)\s+(?:\w+|\?))?)\s*, 
    \s*((?:\w+|\?)(?:\s+(?:extends|super)\s+(?:\w+|\?))?)\s*> 

sustituir por

$1<$3, $2> 

Dado que está utilizando Eclipse, puede comprobar manualmente cada reemplazo para la corrección

Answer 2

En Eclipse haga clic derecho en el método, entonces Refactor-> Cambiar la firma método, se puede cambiar el orden de los parámetros allí

Answer 3

Si no está utilizando Eclipse (o cualquier otra herramienta que tiene buena refactorización - muy recomendable si no son), entonces puedo pensar en dos formas de hacerlo:

Primero: Si está usando TDD, escriba una prueba que solo tendrá éxito cuando las variables se intercambien correctamente. Luego realice el cambio a la firma del método y asegúrese de que su prueba sea aprobada.

Segundo: 1. Retire el segundo parámetro de la firma del método, que se generan errores de compilación de todas las llamadas a ese método 2. Vaya a cada una de las líneas que se producen errores de compilación, y con cuidado intercambiar las variables de 3 . Ponga la segunda variable nuevamente en la firma del método, en el nuevo orden inverso 4. Ejecute algunas pruebas para asegurarse de que todavía funciona de la manera que espera

El segundo método es obviamente desagradable. Pero si no está utilizando un IDE con un buen soporte de refactorización, los errores de compilación son una buena forma de capturar el 100% de las llamadas a ese método (al menos dentro de su proyecto). Si está escribiendo una biblioteca de códigos utilizada por otras personas o por otros programas, se vuelve mucho más complicado comunicar ese cambio a todas las partes afectadas.