java - tecnicas - ¿Puedo usar la refactorización para cambiar el tipo de una variable por otra?

tecnicas de refactorizacion de codigo

Question

Android Studio proporciona una poderosa refactorización, por ejemplo, Renombrar . Puedo usarlo para cambiar el nombre de las variables, campos, parámetros, sin embargo, parece que no puedo encontrar una forma de cambiar el nombre de un tipo. Por ejemplo:

LinearLayout layout = (LinearLayout) v.findViewById(....);
// ........
// A bunch of code using `layout` many times

¿Cómo puedo refactorizar rápidamente LinearLayout a RelativeLayout y hacer que se aplique al resto del código también? ¿Y puedo hacer lo mismo para los campos?

Answer 1

Respuesta corta

La función que estás buscando es Type Migration !

Una migración de tipo se puede realizar haciendo clic derecho en el tipo de una variable o campo y luego seleccionando Refactor -> Tipo de migración . Alternativamente puedes usar estos atajos de teclado:

• En una Mac: Shift + ⌘ + F6
• En Windows: Shift + Ctrl + F6

¡Simplemente elija el tipo al que desea migrar, haga clic en refactor y Android Studio comienza a hacer realidad su magia!

Respuesta larga y más detallada

Pareces malinterpretar lo que Rename realmente hace.

Renombrar se puede usar para literalmente renombrar elementos. Así que puedes cambiar el nombre de una variable, parámetro, método o clase con él. Por ejemplo, si tienes una clase llamada Foo y quieres cambiar su nombre a Bar , puedes hacerlo fácilmente con Renombrar .

Pero no puede cambiar el nombre de LinearLayout ya que es una clase de marco y, por supuesto, no se pueden modificar. Sin embargo, esto no debería ser un problema en absoluto porque realmente no desea cambiar el nombre de LinearLayout , ¿verdad? Lo que realmente desea hacer es cambiar el tipo de LinearLayout a RelativeLayout . Y hay otra característica de refactor muy útil para hacer exactamente eso, se llama migración de tipos .

Puede realizar una migración de tipo haciendo clic con el botón derecho en cualquier variable cuyo tipo desee intercambiar por otra y luego seleccionando Refactor -> Type Migration . Después de eso, se abre un diálogo y puede ingresar el tipo al que desea migrar, en su caso, RelativeLayout . Luego simplemente haga clic en Refactor y Android Studio comenzará a trabajar su magia. Puede haber una ventana emergente adicional que le informa de todas las cosas en su código que no pueden migrarse automáticamente. Simplemente escanee la lista de conflictos y, cuando haya terminado, presione Ignorar y corrija esos conflictos manualmente.

Aquí hay un ejemplo de la migración de tipos en el trabajo. Comencé con este código:

private LinearLayout mLayout;

private void doStuff(ViewGroup container) {
    LinearLayout layout = (LinearLayout) container.findViewById(0);

    layout.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
            ...
        }
    });

    mLayout = layout;
    fooTheBar(layout);   
}

private void fooTheBar(LinearLayout layout) {
    ...
}

Ahora realicé una migración de tipo a RelativeLayout en el layout variable local en doStuff() . El resultado se ve así:

private RelativeLayout mLayout;

private void doStuff(ViewGroup container) {
    // Here is the only conflict which could not be refactored automatically.
    // I had to change the cast to RelativeLayout manually.
    RelativeLayout layout = (LinearLayout) container.findViewById(R.id.linearLayout);

    layout.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
            ...
        }
    });

    mLayout = layout;
    fooTheBar(layout);
}

private void fooTheBar(RelativeLayout layout) {
    ...
}

Como se puede ver, Type Migration hizo un excelente trabajo. El tipo del campo e incluso el tipo del parámetro de fooTheBar() se cambió a RelativeLayout . Solo hubo un conflicto. Android Studio no pudo cambiar automáticamente el tipo de lanzamiento en la parte superior de doStuff() . Tuve que arreglar eso manualmente. Como mencioné anteriormente, me advirtieron sobre este conflicto mientras realizaba la refactorización.

Por supuesto, podría preguntarse por qué podría cambiar el tipo de campo y el parámetro automáticamente, pero no pudo cambiar el tipo de conversión, pero si lo piensa, eso realmente tiene mucho sentido:

La parte del código que no pudo migrar automáticamente fue (LinearLayout) container.findViewById(R.id.linearLayout) . Por supuesto, este método busca una View con el ID R.id.linearLayout . Esta View puede definirse en un xml de diseño o puede agregarse dinámicamente al container en el tiempo de ejecución, pero en cualquier caso no es algo que pueda ser refactorizado automáticamente sin el riesgo de romper la funcionalidad. Es algo que solo el desarrollador puede decidir cómo manejar y por eso se le advierte al respecto.