Concepto de refactorización ......................................................................................... 2
Limitaciones ................................................................................................................. 3
Patrones de refactorización ........................................................................................... 3
Refactorización en Eclipse............................................................................................ 4
Renombrar ................................................................................................................ 4
Mover ....................................................................................................................... 5
Cambiar signatura del método................................................................................... 5
Extraer variable local ................................................................................................ 7
Convertir variable local en atributo ........................................................................... 7
Extraer método ......................................................................................................... 8
Autoencapsular atributo ............................................................................................ 9
Más refactorizaciones recomendadas ............................................................................ 9
Eliminar variable temporal de un solo uso ................................................................ 9
Sustituir variable temporal por un método reutilizable en más lugares..................... 10
Sustituir cálculo por una función-método ................................................................ 10
Variables autoexplicativas ...................................................................................... 10
Uso de final para cálculo en métodos ...................................................................... 11
Cambio de algoritmo que busque la eficiencia ........................................................ 11
Cuándo cambiar métodos entre clases ..................................................................... 12
Extracción de clases ................................................................................................ 13
Clases delegadas ..................................................................................................... 14
Reemplazar valores con objetos .............................................................................. 15
Uso adecuado de herencia y polimorfismo .............................................................. 16
El principio SOLID ................................................................................................ 17
1
,ED Refactorización 2021-2022
Concepto de refactorización
La refactorización es una técnica, que consiste en realizar pequeñas transformaciones en
el código de un programa, para mejorar la estructura sin que cambie el comportamiento
ni funcionalidad del mismo. Su objetivo es mejorar la estructura, la legibilidad o la
eficiencia del código.
Con la refactorización se mejora el diseño del software, hace que el software sea más fácil
de entender, hace que el mantenimiento del software sea más sencillo, la refactorización
ayuda a que el programa sea más rápido.
La idea de refactorización de código, se basa en el concepto matemático de factorización
de polinomios. Así, resulta que (x + 1)(x − 1) se puede expresar como x2 − 1 sin que se
altere su sentido.
Algunas pistas que nos pueden indicar la necesidad de refactorizar un programa son:
• Código duplicado.
• Métodos demasiado largos.
• Clases muy grandes o con demasiados métodos.
• Métodos más interesados en los datos de otra clase que en los de la propia.
• Grupos de datos que suelen aparecer juntos y parecen más una clase que datos
sueltos.
• Clases con pocas llamadas o que se usan muy poco.
• Exceso de comentarios explicando el código.
Hay que resaltar que la refactorización no cambia el comportamiento observable del
software. El software sigue cumpliendo la misma función que hacía antes. Ningún
usuario, ya sea usuario final u otro programador, podrá determinar qué cosas han
cambiado.
Podemos definir el concepto de refactorización de dos formas:
• Refactorización: Cambio hecho en la estructura interna del software para hacerlo
más fácil de entender y fácil de modificar sin modificar su comportamiento.
Ejemplos de refactorización es "Extraer Método" y "Encapsular Campos". La
refactorización es normalmente un cambio pequeño en el software que mejora su
mantenimiento.
• Campos encapsulados: Se aconseja crear métodos getter y setter, (de asignación
y de consulta) para cada campo que se defina en una clase. Cuando sea necesario
acceder o modificar el valor de un campo, basta con invocar al
método getter o setter según convenga.
• Refactorizar: Reestructurar el software aplicando una serie de refactorizaciones
sin cambiar su comportamiento
2
, ED Refactorización 2021-2022
Limitaciones
Se ha constatado que la refactorización presente problemas en algunos aspectos del
desarrollo.
Un área problemática de la refactorización son las bases de datos. Una base de datos
presenta muchas dificultades para poder ser modificada, dado la gran cantidad de
interdependencias que soporta. Cualquier modificación que se requiera de las bases de
datos, incluyendo modificación de esquema y migración de datos, puede ser una tarea
muy costosa. Es por ello que la refactorización de una aplicación asociada a una base de
datos, siempre será limitada, ya que la aplicación dependerá del diseño de la base de datos.
Otra limitación, es cuando cambiamos interfaces. Cuando refactorizamos, estamos
modificando la estructura interna de un programa o de un método. El cambio interno no
afecta al comportamiento ni a la interfaz. Sin embargo, si renombramos un método, hay
que cambiar todas las referencias que se hacen a él. Siempre que se hace esto se genera
un problema si es una interfaz pública. Una solución es mantener las dos interfaces, la
nueva y la vieja, ya que si es utilizada por otro clase o parte del proyecto, no podrá
referenciarla.
Hay determinados cambios en el diseño que son difíciles de refactorizar. Es muy difícil
refactorizar cuando hay un error de diseño o no es recomendable refactorizar, cuando la
estructura a modificar es de vital importancia en el diseño de la aplicación.
Hay ocasiones en las que no debería refactorizar en absoluto. Nos podemos encontrar con
un código que, aunque se puede refactorizar, sería más fácil reescribirlo desde el
principio. Si un código no funciona, no se refactoriza, se reescribe.
Patrones de refactorización
Algunos de los patrones más habituales de refactorización, que vienen ya integrados en
la mayoría de los entornos de desarrollos, son los siguientes:
• Renombrar. Cambiar el nombre de un paquete, clase, método o campo, por un
nombre más significativo.
• Encapsular campos. Crear métodos de asignación y de consulta (getters y
setters) para los campos de la clase, que permitan un control sobre el acceso de
estos campos, debiendo hacerse siempre mediante el uso de estos métodos.
• Sustituir bloques de código por un método. En ocasiones se observa que un
bloque de código puede constituir el cuerpo de un método, dado que implementa
una función por si mismo o aparece repetido en múltiples sitios. De esta forma,
cada vez que queramos acceder a ese bloque de código, bastaría con invocar al
método.
• Modificar la extensión del código. Hacer un código más extenso si se gana en
claridad o menos extenso sólo si con eso se gana eficiencia.
• Reorganizar código condicional complejo. Patrón aplicable cuando existen
varios if o condiciones anidadas o complejas.
• Crear código común (en una clase o método) para evitar el código repetido.
3
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through EFT, credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying this summary from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller saragonzalo. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy this summary for R139,04. You're not tied to anything after your purchase.