REFACTORING

Tabla de Contenido
1. Introduccin .................................................................................................................................... 3 1.1 Justificacin ............................................................................................................................... 4 1.2 Objetivos ................................................................................................................................... 4 1.2.1 Objetivo General ................................................................................................................ 4 1.2.2 Objetivos Especficos .......................................................................................................... 4 1.3 Metas......................................................................................................................................... 5 1.4 Lmites ....................................................................................................................................... 5 1.5 Alcances..................................................................................................................................... 5 2. Metodologa .................................................................................................................................... 6 2.1 Lnea de Investigacin ............................................................................................................... 6 2.2 Mtodos de Investigacin ......................................................................................................... 6 3. Antecedentes .................................................................................................................................. 7 3.1 Explicacin Inicial de Conceptos ........................................................................................... 7 4. Ejemplo [2] ...................................................................................................................................... 8 5. Explicacin ..................................................................................................................................... 37 5.1 Implantacin de la refactorizacin.......................................................................................... 38 5.2 Pasos para implantar la refactorizacin en un equipo............................................................ 38 5.3 Refactoring Continuo .............................................................................................................. 39 5.4 Dificultades de la refactorizacin en la prctica ..................................................................... 40 5.4.1 El factor humano .............................................................................................................. 40 5.4.1 Trabajo en equipo ............................................................................................................ 40 5.5 Refactoring a posteriori........................................................................................................... 41 5.6 Refactorizacin y pruebas unitarias ........................................................................................ 41 6. Ventajas ......................................................................................................................................... 42 7. Desventajas ................................................................................................................................... 42 8. Recomendaciones ......................................................................................................................... 43 9. Conclusiones.................................................................................................................................. 44 10. Bibliografa .................................................................................................................................. 45

Documento 1

Pg. 2

Versin 1.00

REFACTORING

1. Introduccin
En el presente documento tiene como objetivo introducir al programador acerca del mtodo refactoring, mostrarle a este cmo hacer refactoring de una forma controlada y eficiente, de manera tal que no se introduzcan errores en el cdigo si no que metdicamente se pueda mejorar la estructura del cdigo introducido. Para esto se planteara la teora acerca de es refactoring y se darn ejemplos y la una discusin incluyendo cdigo de manera que estos sean fciles de leer y entender. Los ejemplos estarn en Java debido a que es un lenguaje muy conocido y puede ser fcilmente entendido por cualquier persona con conocimientos en programacin. Tambin es un lenguaje orientado a objetos, y los mecanismos orientados a objetos son de gran ayuda en la refactorizacin. Aunque se centra en el cdigo para lograr comprende el concepto de refactoring, este tiene un gran impacto en el diseo de sistemas. Es de vital importancia para los diseadores y arquitectos de alto nivel para entender los principios del refactoring y usarlos en sus proyectos. Refactoring es el ms presentado por un desarrollador respetado y con experiencia. La estructuracin de este documento ser la siguiente Introduccin Metodologa Antecedentes Explicacin de qu es refactoring? Ejemplos Ventajas Desventajas Recomendaciones Conclusiones

[1]

Documento 1

Pg. 3

Versin 1.00

REFACTORING

1.1 Justificacin
La investigacin propuesta busca, mediante la aplicacin de la teora y conceptos sobre restructuracin o refactorizacin de cdigo, detallar los procesos de este tipo de tcnica que nos brinda la funcionalidad de cambiar el cdigo sin perder su comportamiento externo, as como explicar las principales caractersticas de implementacin durante el desarrollo de aplicaciones de software como una herramienta til para tener un cdigo mas entendible para los desarrolladores. Adems se busca darle al lector una serie de recomendaciones para que este pueda valorar los diferentes casos en que se puede usar este tipo de herramienta, y tambin ofrecer una lista detallada de ventajas y desventajas que nos provee la implementacin de la tcnica refactorizacin de cdigo en nuestras aplicaciones.

1.2 Objetivos
1.2.1 Objetivo General

Investigar, explicar y profundizar en el tema de Refactorizacin de cdigo en ambientes de desarrollo de aplicaciones de software y dejar claro su concepto, adems de exponer los principales componentes y caractersticas que posee y dar un ejemplo detallado de su implementacin en cdigo (este ser en el lenguaje de programacin Orientado a Objetos Java ya que es de los mas utilizados actualmente). 1.2.2 Objetivos Especficos

1. Explicar las principales ventajas y desventajas de utilizar la herramienta de Refactoring en el desarrollo de aplicaciones. 2. Enfatizar y explicar los detalles de implementacin especficos de como hacer la refactorizacin de cdigo en una arquitectura Orientada a Objetos. 3. Explicar claramente los diferentes tipos de Refactoring que se utilizan actualmente. 4. Detallar los pasos que se deben seguir cuando se implementa la estrategia de Refactoring en un equipo de trabajo.

Documento 1

Pg. 4

Versin 1.00

REFACTORING

1.3 Metas
Cubrir una gran rea de conocimiento sobre la tcnica de refactorizacin de cdigo, analizando su implementacin, as como sus conceptos y caractersticas principales. Dar a conocer las principales ventajas y desventajas del uso de esta tcnica en nuestras aplicaciones, as como brindar una lista de recomendaciones de cuando usarlo y cuando no. Informar sobre los principales pasos a seguir para cuando se vaya a implementar esta tcnica en algn equipo de trabajo, para que el cdigo quede ms ordenado y estandarizado.

1.4 Lmites
A continuacin se enlistan los aspectos que no sern contenidos ni analizados en la investigacin: Implementacin detalla y especfica sobre la tcnica de refactorizacin de cdigo para las tecnologas especificas, es decir, el ejemplo mostrado es una versin generalizada en el lenguaje Java de como implementar el Refactoring. La utilizacin e implementacin de Pruebas Unitarias y cualquier otro tipo de pruebas para la verificacin de que la refactorizacin de cdigo estn bien hechas y libre de errores.

1.5 Alcances
Los siguientes subtemas si estn cubiertos por la Investigacin: Detalles de implementacin y diversos tipos de Refactoring como los son el continuo y el A posteriori. Definicin de los pasos especficos para la implementacin de Refactoring en un equipo de trabajo. Definicin y concepto sobre la factorizacin de cdigo as como sus antecedentes. Caractersticas principales y componentes de la factorizacin de cdigo. Ventajas y desventajas. Explicacin detallada de su Uso en diferentes aplicaciones.

Documento 1

Pg. 5

Versin 1.00

REFACTORING

2. Metodologa
2.1 Lnea de Investigacin
Para la presente investigacin se obtuvieron datos sobre el Tema principal Refactoring en programacin. La lnea de investigacin sigui los siguientes subtemas principales: Implementacin de la estrategia de refactorizacin. Pasos para implantar la refactorizacin en un equipo. Refactoring Continuo Dificultades de la Refactorizacin en la Prctica. Refactoring a Posteriori Refactorizacin y Pruebas Unitarias.

2.2 Mtodos de Investigacin

La tcnica de recoleccin de informacin utilizada fue el anlisis documental: Este alude al conjunto de conocimientos relativos a los principios, mtodos y tcnicas que permiten examinar, distinguir y separar cada una de las partes de un documento y analizar su forma estructural y propiedades para obtener un resultado para cierta investigacin. Se buscaron estudios previos de diversas fuentes como informes, artculos y libros publicados en la web. As mismo, se consultaron diferentes medios visuales como animaciones, videos y presentaciones que ayudaron a enriquecer los conocimientos para la investigacin. Para llevar a cabo la investigacin, primeramente se realiz una pequea bsqueda de informacin para formar la propuesta de investigacin. Posteriormente se procedi a recolectar ms informacin para poder realizar un estudio detallado y completo del tema en cuestin. Finalmente se analizaron y se procesaron los datos para obtener los resultados.

Documento 1

Pg. 6

Versin 1.00

REFACTORING

3. Antecedentes
3.1 Explicacin Inicial de Conceptos .1
La refactorizacin de programas surge como herramienta necesaria para ser aplicada en los procesos de mantenimiento debido a las caractersticas esenciales del software para reducir los costos de esta fase del proceso de desarrollo y como herramienta en la introduccin de nueva funcionalidad dentro del ciclo evolutivo de las aplicaciones. El objetivo de la refactorizacin de software es principalmente mantener o aumentar el valor del mismo. La refactorizacin de cdigo es una de las Tcnicas y/o Herramientas para tratar de hacer el cdigo Herramientas ms entendible y ahorrar tiempos, costos en el mantenimiento. Hay dos puntos de vista, por una parte hay muchos programadores que hacen algo en 2 lneas y sper Eficiente pero que nadie entiende. Y hay otros que lo hacen en 10 lneas pero que entiende cualquier persona. Qu es mejor?, desde nuestro punto de vista depende del tipo caso. Si es un proyecto cada byte de ms es un desperdicio optas por ser ptimo, en otro caso es mejor comentar y programar con modelos y tcnicas propuestas que a primera vista son muy tontas, pero a largo plazo suelen funcionar muy bien. Software refactoring surge como el proceso en el cual se aplican cambios en un sistema de software de forma tal que no altere el comportamiento externo del cdigo, mejorando su cdigo, estructura interna". Por definicin, el proceso de refactorizacin de cdigo fuente debe preservar el comportamiento del sistema. El trmino se cre como analoga con la factorizacin de nmeros y polinomios Por ejemplo, polinomios. puede ser factorizado como , revelando una estructura interna que no era visible previamente. De manera similar, en la refactorizacin del software, el cambio en la estructura visible puede frecuentemente revelar la estructura interna "oculta" del cdigo original.

Documento 1

Pg. 7

Versin 1.00

REFACTORING

4. Ejemplo [2]
El ejemplo trata de un programa para calcular e imprimir una declaracin de cargos de un cliente en una tienda de video. El programa se dijo que un cliente alquila pelculas y por cunto tiempo. A continuacin, calcula los cargos, que dependen de la duracin de la pelcula se alquila, e identifica el tipo de pelcula. Hay tres tipos de pelculas: regulares (regular), nios (childrens), y estrenos (new release). Est escrito en cdigo Java.

Adems de los cargos de clculo, la declaracin tambin calcula los puntos frecuentes de socios, los cuales varan dependiendo de si la pelcula es una nueva versin. En el ejemplo en cdigo y diagramas, se utilizara el nombre de las funciones, clases y mtodos en ingles.

Diagrama de clases con las clases iniciales. Slo las caractersticas ms importantes se muestran.

Clase Movie

Documento 1

Pg. 8

Versin 1.00

REFACTORING

Clase Rental

Clase Costumer

Mtodo statement

Diagrama de interaccin del mtodo

Documento 1

Pg. 9

Versin 1.00

REFACTORING

Cdigo del mtodo

Documento 1

Pg. 10

Versin 1.00

REFACTORING

En este caso el cdigo no est bien diseado, y no est orientado a objetos. Para que un programa tan simple como este, que en realidad no importa. No hay nada malo con un simple programa rpido. Pero si se trata de un fragmento representativo de un sistema ms complejo, entonces tengo algunos problemas reales con este programa. Esa declaracin larga en la clase de hace demasiado, muchas de las cosas que hace debe realmente ser hecho por las otras clases. Aun as, el programa funciona. No es esto slo un juicio esttico, una aversin del cdigo feo?. Al compilador no le importa si el cdigo es feo o limpio. Sin embargo, cuando cambiamos el sistema, hay personas involucradas, que se preocupan por esto. Un sistema mal diseado es difcil de cambiar, y es difcil porque, es difcil de entender que los cambios son necesarios dentro de este. Si es difcil de averiguar que cambiar, hay una gran posibilidad de que el programador se cometa un error o introduzca errores dentro del cdigo. En este caso tenemos un cambio que los usuarios les gustaria realizar. En primer lugar quieren el statement este disponible en HTML. Se debe considerar el impacto que este cambio tendra. Como nos fijamos en el cdigo se puede ver que es imposible volver a utilizar cualquiera de la comportamiento que tenga el mtodo statement actual de para la versin de HTML. La nica alternativa es escribir un mtodo completamente nuevo que duplica la mayor parte del comportamiento de statement. Ahora, por supuesto, esto no es demasiado complicado el hacer esto, puede simplemente copiar el mtodo de declaracin y hacer los cambios que se necesitan. Usted tiene que fijar tanto en statement y htmlStatement y asegurar que las revisiones son compatibles. El problema con copiar y pegar el cdigo viene cuando se tiene que cambiar ms adelante. Si usted est escribiendo un programa que no te espera cambiar, cortar y pegar est muy bien. Si el programa es de larga vida y es probable que cambie, cortar y pegar es una amenaza. Esto me lleva a un segundo cambio. Los usuarios desean realizar cambios en la clasificacin de las pelculas, pero todava no han decidido sobre el cambio que se va a hacer. Tienen una serie de cambios en mente. Estos cambios afectarn la manera la que los socios pagan por las pelculas y la forma en que los puntos frecuentes se calculan. La nica garanta de que vamos a tener, es que lo van a cambiar de nuevo en un plazo de seis meses. El en mtodo statement es donde se realizaran los cambios para hacer frente a cambios en la clasificacin y las reglas de puntos. Sin embargo, si se copia statement a htmlStatement, tenemos que asegurarnos de que los cambios son completamente consistentes. Adems, como las reglas se hacen ms complejas que va a ser ms difcil de averiguar dnde hacer los cambios y las ms difciles de hacerlos sin cometer un error. Para tener este cdigo legible y bien diseado para los dems desarrolladores o para los futuros desarrolladores vamos a aplicar el refactoring.
Documento 1 Pg. 11 Versin 1.00

REFACTORING

Primer paso refactoring Cada vez que hace refactoring, el primer paso es siempre el mismo. Necesito crear un conjunto slido de pruebas para esa seccin de cdigo. Las pruebas son esenciales para evitar la mayora de las oportunidades de introducir errores. Debido a que el resultado que statement produce un String, puedo crear unos pocos clientes, dar a cada cliente unos pocos alquileres de diversos tipos de pelculas, y generar los statement String. Luego se debe realizar una comparacin entre la nuevo String y algunas String de referencia que he comprobado de antemano. Una parte importante de las pruebas es la forma en que informan sobre sus resultados. O bien decir "OK" o visto bueno, lo que significa que todas los String son idnticos a los de referencia, o imprimir una lista de fracasos con los que resultaron de otra manera. Las pruebas por lo tanto son de auto-comprobacin. Es de vital importancia para realizar pruebas de comprobacin en s mismo, si no lo hace, se termina gastando tiempo revisando algunos nmeros de la prueba en contra de algunos nmeros del sistema anterior. Descomposicin y la redistribucin de la Declaracin del Mtodo La meta primera y ms obvia de mi atencin es el mtodo statement es demasiado largo. Cuando se mira un mtodo a largo como ese, se debe buscar descomponer el mtodo en pedazos ms pequeos que tienden a hacer que las cosas sean ms manejables y ms fciles de trabajar y moverse. El primer paso es encontrar un grupo lgico de cdigo y utilizar el mtodo de extraccin. Realizando un cambio dentro de la declaracin del cdigo extrayendo una gran parte de este. Al extraer un mtodo, como en cualquier refactoring, se necesita saber que puede salir mal. Si realiza la extraccin mal, se podra introducir un error en el programa. As que antes de hacer el refactoring tengo que encontrar la manera de hacerlo con seguridad. En primer lugar se debe mirar en el fragmento de cdigo correspondiente a las variables que son locales en el mbito de aplicacin para el mtodo que estamos viendo (variables locales y parmetros). Este segmento de cdigo utiliza dos: each y thisAmount. De estos each no se modifica el cdigo, pero thisAmount si se modifica. Cualquier variable no modificada que pueda pasada como un parmetro. Con las variables modificadas necesitan ms cuidado. Si slo hay uno, puedo volver. temp se inicializa a 0 en el ciclo y no se altera hasta que el switch cambia. As que slo se puede asignar el resultado.

Documento 1

Pg. 12

Versin 1.00

REFACTORING Las dos pginas siguientes muestran el cdigo antes y despus de refactoring. El cdigo que se esta extrayendo desde el original, y cualquier cambio en el nuevo cdigo estar en negrita.

Documento 1

Pg. 13

Versin 1.00

REFACTORING

Cada vez que realiza un cambio como ste, se debe compilar y probar. En este cdigo existe un error en amountFor bebido a que el tipo de retorno es un int lugar de double

Documento 1

Pg. 14

Versin 1.00

REFACTORING

Ahora que he dividido el mtodo original en pedazos, se puedo trabajar en ellos por separado. Al no tener las variables con nombre Aqu est el cdigo original:

Aqu est el cdigo modificado:

Documento 1

Pg. 15

Versin 1.00

REFACTORING Una vez que he hecho el renombramiento de la variable, se compila y prueba para asegurarse de que exista error alguno. Moviendo Amount Calculation Cuando se observa amountFor, se puede ver que utiliza la informacin de la renta, pero no utiliza la informacin del cliente.

El mtodo es en el objeto est equivocado y no pertenece a la clase customer, en la mayora de los casos, un mtodo que se encuentra dentro del objeto utiliza los datos de este, por lo que el mtodo debe ser trasladado a la renta. Para hacer esto mover el mtodo. Con esto, primero copia el cdigo a alquiler, ajustndolo la a su nueva clase y compilar para que quede de la siguiente manera:

Documento 1

Pg. 16

Versin 1.00

REFACTORING En este caso, cuando se introduce el mtodo en la clase customer significa la eliminacin del parmetro, tambin cambi el nombre del mtodo. Ahora puede probar para ver si este mtodo funciona. Para ello puedo reemplazar el cdigo de Customer.amountFor delegar este nuevo mtodo.

Se compila para comprobar que no existan errores en el cdigo. El siguiente paso es encontrar todas las referencias al mtodo antiguo y ajustarlas la referencias para utilizar el nuevo mtodo:

En este caso, este paso es fcil, ya que acaba de crear el mtodo, que se encuentra en un solo lugar. En general, sin embargo, hay que "encontrar" ese cambio a travs de todas las clases que puedan estar utilizando este mtodo:

Documento 1

Pg. 17

Versin 1.00

REFACTORING

Cuando he hecho el cambio a las clases, lo siguiente es quitar el viejo mtodo. El compilador debe decirme si me perd nada. Entonces prueba para ver si puede existir error en el cdigo.

Estado de las clases despus de mover el mtodo charge

Se puede dejar el mtodo viejo que delegar hacia el nuevo mtodo. Esto es til si se trata de un mtodo pblico y no quiere cambiar la interfaz de la otra clase.

Documento 1

Pg. 18

Versin 1.00

REFACTORING Volviendo a Customer.statement.

Se debe notar que thisAmount es ahora redundante. Se establece en el resultado de each.charge y no cambia despus. As que puede eliminar mediante el uso de thisAmount Reemplazando Temp con el Query

Documento 1

Pg. 19

Versin 1.00

REFACTORING

Una vez hecho el cambio se debe compilar y probar para asegurarse de que no exista algn error en el cdigo. Lo ideal sera deshacerse de las variables temporales tanto como sea posible. Los temporales son a menudo un problema, puesto que causa que muchos de los parmetros pasen cuando no tiene que hacerlo, y puede perder la pista de lo que ellos transmiten. Por supuesto, hay un precio a pagar, ahora charge se calcula en dos ocasiones. Pero es fcil de optimizar que en la clase Rental y hacerla mucho ms eficaz si el cdigo est correctamente factorizado.

Documento 1

Pg. 20

Versin 1.00

REFACTORING La extraccin de los puntos ms frecuentes El siguiente paso es hacer una cosa similar para los puntos frecuentes de los socios. Las reglas varan con la pelcula, aunque hay una menor variacin que con charge. Parece razonable poner esta responsabilidad en la clase Rental. En primer lugar tenemos que usar extraer el mtodo de los puntos frecuentes del socio (en negrita):

Se deben observar el uso de variables locales. Una vez ms each se utiliza y se puede pasar como un parmetro. El otro temporal usado es frequentRenterPoints. En este caso frequentRenterPoints tiene un valor previo. El cdigo del mtodo que se extrajo no lee el valor, sin embargo, no es necesario pasarlo como parmetro si se lo aadimos ala asignacion. Se realizo la extraccin, compilo y probo, para luego hacer un movimiento, compilado y probado de nuevo. Con esto refactoring en pequeos los pasos es la mejor practica para evitar posibles complicaciones.

Documento 1

Pg. 21

Versin 1.00

REFACTORING

Resumiendo los cambios que acaba de hacer con un antes y despus se debe de actualizar el diagrama de las clases quedando de la siguiente manera:

Diagrama de clase antes de la extraccin y el movimiento del clculo puntos frecuentes.

Diagrama de secuencia antes de la extraccin y el movimiento del clculo puntos frecuentes

Documento 1

Pg. 22

Versin 1.00

REFACTORING

Diagrama de clases despus de la extraccin y el movimiento del clculo de puntos frecuentes

Diagrama de Secuencia despus de la extraccin y el movimiento del clculo puntos frecuentes

Documento 1

Pg. 23

Versin 1.00

REFACTORING Removiendo las variables temporales Como se observo antes, las variables temporales puede ser un problema. Slo son tiles dentro de su propia rutina, por lo tanto no utilizarlas en rutinas largas y complejas. En este caso tenemos dos variables temporales, los cuales estn siendo utilizados para obtener un total del alquiler del cliente, tanto las versiones ASCII y HTML requieren estos totales. Lo ideal sera reemplazar estas variables con Querys para reemplazar TotalAmount, frequentRentalPoints ya que estos son accesibles a cualquier mtodo en la clase y fomentar as un diseo ms limpio, sin mtodos largos y complejos:

Comenzamos sustituyendo TotalAmount con un mtodo charge en el customer

Documento 1

Pg. 24

Versin 1.00

REFACTORING

Este no es un caso de reemplazar simplemente la variable temporal con el query, TotalAmount fue asignado a dentro de ciclo, as que tengo que copiar el ciclo en el mtodo query.

A continuacin se muestra el cambio del refactoring en los diagramas de clases e interaccin para el mtodo statement

Documento 1

Pg. 25

Versin 1.00

REFACTORING

Diagrama de clase antes de la extraccin de los totales

Diagrama de secuencia antes de la extraccin de los totales

Diagrama de clase despus de la extraccin de los totales

Diagrama de secuencia despus de la extraccin de los totales

En la mayora de los casos el refactoring ayuda reducir la cantidad de cdigo, pero ste se incrementa. Esto se debe a Java que requiere una gran cantidad de estados para establecer un ciclo incrementa. Incluso un simple ciclo con una lnea de cdigo por cada elemento, tiene seis lneas de apoyo a su alrededor. Es un lenguaje que es obvio para cualquier programador, pero es un montn de lneas de todos modos.
Documento 1 Pg. 26 Versin 1.00

REFACTORING La otra preocupacin con este refactoring se encuentra en el rendimiento. El antiguo cdigo ejecutado el "while" una vez, el nuevo cdigo se ejecuta en tres ocasiones. Un ciclo que toma mucho tiempo puede perjudicar el rendimiento. Muchos programadores no haran esto slo por esta razn. Pero tenga en cuenta las palabras si y poder. No se puede decir cunto tiempo necesita el ciclo para calcular o si el ciclo se llama a muchas veces como para que se afecte el rendimiento general del sistema. Al optimizar tendr que preocuparse por ello, pero entonces estar en una posicin mucho mejor para hacer algo al respecto, y usted tendr ms opciones para optimizar la eficiencia. Ahora los query estn disponibles para cualquier cdigo escrito en la clase customer. Ellos pueden ser fcilmente aadidos a la interfaz de la clase siendo accedidos por otras partes del sistema que necesite esta informacin. Se puede ver la diferencia de inmediato con el htmlStatement.

Extraccin los clculos que se puede crear del mtodo htmlStatement y reutilizar todo el cdigo de clculo que estaba en el mtodo de declaracin original. No copiar y pegar, as que si cambian las reglas de clculo de estos, slo tienen un lugar en el cdigo al cual ir. Cualquier otro tipo de declaracin va a ser muy rpida y fcil de preparar. Parte del cdigo se copia de la versin ASCII, debido principalmente a la creacin de la ciclo. Realizar un refactoring adicional ayuda limpiar eso. Pero ahora los clientes estn pidiendo a gritos otra vez, ellos se estn preparando para cambiar la clasificacin de las pelculas en la tienda. Todava no est claro qu cambios quieren hacer, pero parece que las clasificaciones se van a introducir, y los ya existentes podran cambiar, los cargos puntos frecuentes de los clientes segn las clasificaciones son los que deciden. Por el momento, este tipo de cambio es difcil. Se debe de entrar en el charge y los mtodos de puntos frecuentes y alterar el cdigo para hacer cambios a las clasificaciones de pelculas.

Documento 1

Pg. 27

Versin 1.00

REFACTORING Sustitucin de la lgica condicional en el cdigo del Precio con polimorfismo La primera parte de este problema es cambio en la declaracin del cdigo. Es una mala idea para hacer un switch basado en atributos de otro objeto. Si tiene que usar el switch en la declaracin, esta se debe realizar con datos propios.

Esto implica que getCharge debe pasar a Movie

Para que esto funcione se tuvo que pasar la duracin del alquiler, que es uno de los datos de la clase rental. El mtodo utiliza dos piezas de datos, la duracin del alquiler y del tipo de la pelcula. Por qu prefieren pasar la duracin del alquiler de la pelcula en lugar del tipo de pelcula para el alquiler? Esto se debe a los cambios propuestos son todos acerca de la adicin de nuevos tipos. La informacin de tipo general, tiende a ser ms voltil. Si puedo cambiar el tipo de pelcula, quiero
Documento 1 Pg. 28 Versin 1.00

REFACTORING que el menor efecto posible, por lo que prefiero, para calcular el charge, este se encuentre dentro de la pelcula. Se compilado el mtodo en Movie y luego se cambi el getCharge en la clase Rental para utilizar el nuevo mtodo.

Diagrama de clases antes de pasar el mtodo Movie

Diagrama de clases despus de pasar el mtodo Movie

Una vez que me movido el mtodo getCharge, se hace lo mismo con el clculo puntos frecuentes. Esto mantiene a las dos cosas que varan en la misma clase:

Documento 1

Pg. 29

Versin 1.00

REFACTORING Por ltimo herencia Tenemos varios tipos de pelcula que tienen diferentes formas de responder la misma pregunta. Esto suena como un trabajo para las subclases. Podemos tener tres subclases de pelcula, cada uno de ellos puede tener su propia versin de la carga.

Usando herencia en Movies

Esto me permite reemplazar el cambio en la declaracin mediante el uso de polimorfismo. Lamentablemente tiene un defecto, que es menor y no funciona. Una pelcula puede cambiar su clasificacin durante su vida til. Un objeto no puede cambiar su clase durante su vida til. Hay una solucin, la cual es aplicar el patrn State pattern.

Usando el patrn en Movie

Mediante esta adicin podemos hacer de la creacin de subclases del cdigo objeto, precio y cambiar el precio cada vez que necesitamos. Si usted est familiarizado con la Gang of four patterns (nombre con el que se conoce comnmente a los autores del libro Design Patterns), se puede preguntar, "Es esto un estado, o es una estrategia?" El rango de precios representan un algoritmo para calcular el precio (en cuyo se puede llamarlo Pricer o PricingStrategy de manera que sean nombres significativos), o representa un estado de la pelcula (Star Trek X es una nueva versin). En esta etapa, la eleccin del modelo y nombre refleja la forma en que la que quiere pensar acerca de la estructura. En este momento se est pensando en esto como un estado de
Documento 1 Pg. 30 Versin 1.00

REFACTORING pelcula. Si ms tarde decide una estrategia para comunicar mejor la intencin mejor por lo que aplicar refactoring para tener estos cambios en cuenta. Para introducir el state pattern se utilizaran tres refactorings. En primer lugar se va a mover el comportamiento del cdigo al state pattern reemplazando el cdigo con el Estado/Estrategia.

Se ajusta el mtodo

Luego de compilar y probar para asegurarse de que no existan errores, se puede aadir las nuevas clases. Que proporcionan el cdigo de comportamiento en el objeto de precio. Se puede hacer esto con un mtodo abstracto sobre los mtodos de precios y concretos en las subclases:

Documento 1

Pg. 31

Versin 1.00

REFACTORING Se compilan las clases nuevas en este punto. Ahora se cambiar el cdigo de acceso en Movie para precio en la nueva clase:

Esto significa reemplazar el campo cdigo de precio, con un campo de precio, y el cambio de los mtodos de acceso:

Ahora se compilar y prueban. Los mtodos ms complejos, no se dan cuenta que el mundo ha cambiado. Ahora aplico el muevo el mtodo getCharge:

Documento 1

Pg. 32

Versin 1.00

REFACTORING Es un simple movimiento

Una vez que se movi se puede empezar a usar reemplazar las condiciones con polimorfismo

Documento 1

Pg. 33

Versin 1.00

REFACTORING Se toma una parte de la declaracin del caso a la vez y crear un mtodo de reemplazo, empezando con RegularPrice:

Esto anula la declaracin en el caso del padre, que acaba de dejar como est y se pasa a compilar y probar este caso luego tomar la siguiente etapa de compilacin, y la prueba.

Cuando se ha realizado esto con todos los casos, declaro el mtodo abtracto de Price.getCharge:

Ahora hace lo mismo procedimiento getFrequentRenterPoints:

Documento 1

Pg. 34

Versin 1.00

REFACTORING En primer lugar se mueve en el mtodo de precio:

En este caso, sin embargo, cree un mtodo abstracto para la superclase. En lugar de eso, cree un mtodo reemplazar los nuevos lanzamientos y dejar a un mtodo definido (por defecto) de la superclase:

Poner en el state pattern fue un gran esfuerzo pero la ganancia es, que si cambia cualquier comportamiento de precios, o aaden nuevos precios, el cambio ser mucho ms fcil de hacer. El resto de la aplicacin no conoce el uso del state pattern. En un sistema ms complejo, con precios que dependen de una docena de mtodos, esto hara una gran diferencia. Todos estos cambios fueron pequeos pasos. Una vez terminado el segundo gran refactoring del cdigo. Va a ser mucho ms fcil cambiar la estructura de clasificacin de pelculas, y para alterar las reglas de cobro y el sistema de puntos frecuente. A continuacin se muestra el modelo del Estado que trabaja con la informacin de los precios.

Interacciones usando state pattern

Documento 1

Pg. 35

Versin 1.00

REFACTORING

diagrama de clase despus de la adicin del state pattern

Este es un ejemplo simple, pero da la nocin de que es el refactoring se aplico este varias ocasiones con los mtodos de Extraer, Mover, y reemplazo con polimorfismo. Todo ello conduce tener, mejor distribuidas las responsabilidades de manera que el cdigo que es ms fcil de mantener. La leccin ms importante de este ejemplo es el ritmo del refactoring: prueba, un pequeo cambio, de prueba, un pequeo cambio, de prueba, un pequeo cambio y es que este ritmo es el que permite refactoring pueda realizarse rpidamente y con seguridad.

Documento 1

Pg. 36

Versin 1.00

REFACTORING

5. Explicacin
La refactoring es uno de los nuevos conceptos que se han introducido en la terminologa del mundo del desarrollo. La idea de refactorizacin no es nueva, lo que resulta novedoso es la forma en que se lleva a cabo, una forma gil y agresiva, pero al tiempo ordenada y segura. Qu significa refactoring? refactoring es realizar modificaciones en el cdigo con el objetivo de mejorar su estructura interna, sin alterar su comportamiento externo, no es una tcnica para encontrar y corregir errores en una aplicacin, puesto que su objetivo no es alterar su comportamiento externo. De hecho, no modificar el comportamiento externo de la aplicacin es uno de los pilares de cualquiera de las prcticas que forman parte de la tcnica, para lo que en muchas ocasiones se hace uso de las pruebas unitarias. La esencia de esta tcnica consiste en aplicar una serie de pequeos cambios en el cdigo manteniendo su comportamiento. Cada uno de estos cambios debe ser tan pequeo que pueda ser completamente controlado por nosotros sin miedo a equivocarnos. Es el efecto acumulativo de todas estas modificaciones lo que hace de la refactoring una potente tcnica. El objetivo final del refactoring es hacer el software ms fcil de comprender y modificar. pero por qu aplicar refactoring? para responder esto se toman en cuenta cuatro aspectos importantes: la Calidad: refactoring es un continuo proceso de revisin sobre cdigo que permitiendo que generar cdigo sencillo y bien estructurado, de manera que cualquiera con conocimientos en programacin pueda leer y entender sin necesidad de estado en el equipo de desarrollo. Eficiencia: mantener un buen diseo y un cdigo estructurado es la forma ms eficiente de desarrollar ayudando esto a evitar la duplicacin de cdigo y simplificar, de manera que ayuda a la escalabilidad del software solucin. Diseo evolutivo: cuando se est comenzando a desarrollar cada artefacto que se est obteniendo de cada etapa, son documentos vivos ya que al principio del proyecto no estn suficientemente especificados y debemos abordar el diseo de una forma gradual donde se van aadiendo nuevas funcionalidades segn va avanzando. refactoring nos permitir ir evolucionando el diseo segn incluyamos nuevas funcionalidades, lo que implica muchas veces cambios importantes en la arquitectura, aadir cosas y borrar otras. Evita reescribir el cdigo: En la mayora de los casos refactoring es mejor que rescribir o duplicar el cdigo. Es difcil tratar de comprender un cdigo que no conocemos y que no sigue los estndares que uno utiliza, pero eso no es motivo para empezar de cero.

Documento 1

Pg. 37

Versin 1.00

REFACTORING

5.1 Implantacin de la refactorizacin

En el caso de comenzar un proyecto desde cero, refactoring debe ser un proceso continuo en la prctica ya que trae un gran nmero de beneficios y evita de forma natural algunos peligros mencionados. Sin embargo, no siempre se parte de cero, y lo habitual es encontrarnos con cdigo cuyo diseo o estructura est lejos de ser los ptimos. Esta situacin puede darse cuando tenemos que ampliar la funcionalidad de cdigo previamente existente o simplemente porque en un proyecto empezado desde cero no se detect la necesidad del uso refactoring a tiempo. En estos casos nos encontramos con un refactoring que se debe hacer a posteriori y deben tomarse medidas especficas para que afecte lo menos posible al ritmo normal de desarrollo.

5.2 Pasos para implantar la refactorizacin en un equipo

Implantar la refactorizacin debe realizarse de una manera progresiva. En la implantacin de esta tcnica es necesario seguir los siguientes pasos: Escribir pruebas unitarias y funcionales: refactoring sin pruebas unitarias y funcionales resulta demasiado costoso y de mucho riesgo. Usar herramientas especializadas (opcional): refactoring en muchas ocasiones obligan a pequeas modificaciones muy simples en muchas clases de nuestro cdigo. Con herramientas especializadas estas refactorizaciones se realizan automticamente y sin riesgo. Dar formacin sobre patrones de refactoring y de diseo. Una buena base terica sobre los refactoring ms comunes permite al programador detectar problemas en el cdigo de los que no es consciente y que harn que su cdigo se degrade progresivamente. Refactoring de los principales fallos de diseo: Nuestra recomendacin es comenzar realizando refactoring concretos que permitan corregir los principales fallos de diseo, como puede ser cdigo duplicado. Comenzar con el refactoring en el cdigo tras aadir cada nueva funcionalidad en grupo. Una vez corregido los errores del cdigo existente, la mejor manera de aplicar refactoring es el aadir una nueva funcionalidad, de manera que se desarrolle de la manera ms eficiente. Realizar discusiones en grupos sobre la conveniencia aplicar refactoring suele ser muy productivo. Implantar refactoring continuo. Esta es la ltima fase y es cuando cada desarrollador incorpora el uso de refactoring como una tarea dentro de su proceso de desarrollo de Software.

Documento 1

Pg. 38

Versin 1.00

REFACTORING

5.3 Refactoring Continuo

Es una prctica que consiste en mantener el diseo siempre correcto, utilizando refactoring siempre que sea posible, despus de aadir una nueva funcionalidad. Dado que el refactoring supone un cambio en la estructura del cdigo sin cambiar la funcionalidad, cuanto mayor sea el cambio en la estructura ms difcil ser garantizar que no ha cambiado la funcionalidad. Dicho de otra forma, cuanto mayor sea el refactoring aplicado en el cdigo, mayor ser el nmero de elementos implicados y mayor ser el riesgo de que el sistema deje de funcionar. El tiempo necesario para llevarla a cabo tambin aumenta y por tanto el costo de realizar esta tarea se multiplica. Cuando un diseo no es ptimo y necesita aplicar refactoring, cada nueva funcionalidad contribuye a empeorar el diseo un poco ms. Por ello cuanto ms tiempo esperamos mayor refactoring necesita en el proyecto. Esta es la mayor de las justificaciones de una refactoring continuo, que trata de evitar refactoring en grandes bloques, si no haciendo refactoring en pequeas escala muy a menudo. En concreto el aplicar refactoring de forma inmediata, cuando se incluye de una nueva funcionalidad. Las claves para poder aplicar refactoring continuo son: Concienciacin del desarrollador y todo el equipo de desarrollo dentro del proyecto. Habilidad o conocimientos necesarios para identificar si es necesario aplicar refactoring. Compartir con todo el equipo de desarrollo la visin de una arquitectura global que gue a todos en el uso de refactoring, de manera que todos vallan en una misma direccin.

Lo ms habitual es que al implementar una funcionalidad y dejar los tests pasando satisfactoriamente, estos mismos tests nos garantizarn que el cdigo sigue funcionando despus del refactoring. Sin embargo no siempre resulta evidente para todos los desarrolladores la necesidad de utilizar refactoring en algn caso, por lo que el uso de herramientas pueden emplearse como ayuda para identificar donde se debera de aplicar. En cualquier caso es importante que estas herramientas no sustituyan nunca al sentido comn y se usen nicamente como ayuda. El principal riesgo del refactoring continuo consiste en adoptar posturas excesivamente exigentes o criterios excesivamente personales respecto a la calidad del cdigo. Cuando esto ocurre se acaba dedicando ms tiempo al cmo y dnde se debe aplicar refactoring que a desarrollar el software. La propia presin para aadir nuevas funcionalidades a la mayor velocidad posible que impone el mercado es suficiente en ocasiones para prevenir esta situacin. Si se mantiene bajo unos criterios razonables y se realiza de forma continuada el refactoring, debe tender a ocupar una parte pequea en relacin al tiempo dedicado a las nuevas funcionalidades.
Documento 1 Pg. 39 Versin 1.00

REFACTORING La consecuencia inmediata de la aplicacin de esta prctica suele ser la evolucin de la arquitectura inicial, en beneficio de un cdigo bien estructurado, de una arquitectura orientada en todo momento a la funcionalidad implementada y por tanto, clara y sencilla, caractersticas necesarias para que un cdigo sea mantenible.

5.4 Dificultades de la refactorizacin en la prctica

En un proyecto real hay que ser consciente de que no utilizar refactoring a tiempo un diseo puede tener consecuencias muy negativas, pero a la vez debe tener en cuenta que el tiempo dedicado al uso refactoring no suele ser considerado como un avance del proyecto, por los usuarios, clientes o gestores del mismo. Otros factores clave para una correcta aplicacin del refactoring, son la forma en que afecta a otros miembros del equipo, el hecho de que un desarrollador realice refactoring sobre el cdigo en el que todos estn trabajando, el que un refactoring provoque que el cdigo est mucho tiempo sin funcionar o el efecto negativo de no utilizarlo, en el nimo de los desarrolladores por la sensacin de no estar haciendo un trabajo de calidad. 5.4.1 El factor humano Una realidad a veces olvidada es que cualquier desarrollador prefiere hacer cdigo de calidad, que esta realidad a veces queda oculta debido a condiciones de presin excesiva o menosprecio del trabajo tcnico. En este sentido refactoring es una forma de mejorar la calidad y por tanto es una forma de hacer que el desarrollador est ms orgulloso de su trabajo, pero tambin hay un peligro en este hecho y tratar de conseguir un resultado de calidad puede llegar a generar un nmero excesivo del uso del refactoring dando vueltas sobre diseos similares una y otra vez. Una posible solucin consiste en mantener el refactoring bajo control, definir claramente los objetivos antes de comenzar y estimar su duracin. 5.4.1 Trabajo en equipo Un equipo de desarrollo debe ser uno. Todos los miembros del equipo deben conocer la arquitectura en cada momento, el estado actual, los problemas que tenemos y el objetivo que se busca. Una reunin diaria es una prctica que facilita la comunicacin entre todos los miembros del equipo, y supone una prctica que proporciona un momento a todos los miembros del grupo para plantear sus ideas, dudas e inquietudes respecto al proyecto. Cuando un desarrollador hace refactoring, afecta al resto del equipo. En este sentido, uso interno de este es menos problemtico, pero con las arquitecturales es necesario aplicar refactoring, se debe tener mucho cuidado ya que supone cambios en un gran tamao en el cdigo y por tanto es probable que se afecte el cdigo fuente de los archivos que estn siendo trabajados por los otros desarrolladores. La comunicacin y coordinacin entre los afectados es fundamental para que esto no se convierta en un problema. Por tanto es necesario que en la reunin diaria del equipo, donde se planteen las problemas de este tipo, de esta forma se sabr en todo momento quienes son los afectados y cul es el objetivo de la uso refactoring en algn rea del cdigo. De esta forma se promueve la colaboracin de todos en el refactoring arquitectural que se va a llevar a cabo.
Documento 1 Pg. 40 Versin 1.00

REFACTORING

5.5 Refactoring a posteriori

Los cambios estructurales que se realizan un tiempo despus de la implementacin de la funcionalidad existente. Existen varios motivos para encontrarse con esta situacin. Algunos de ellos son: Un equipo comienza a trabajar con cdigo desarrollado por un equipo anterior que o bien no tiene buena calidad o bien no est preparado para que se incorporen nuevas funcionalidades. Se ha aplicado refactoring continuo pero la calidad del cdigo o el diseo se ha degradado porque no se identific a tiempo la necesidad o bien se equivoc cuando se aplico esta.

Este tipo de refactoring tiene un gran riesgo ya que los que nos encontramos con refactoring continuo. Otra caracterstica del refactoring es que afectan no slo al desarrollador o desarrolladores que van a aplicar, sino a todos aquellos que trabajan con la parte del cdigo que se ve afectada por este proceso ya que por un lado no pueden trabajar con el cdigo o deben hacerlo con mayor precaucin durante un tiempo; y por otro cuando vuelvan a trabajar con l se encontrarn con un diseo desconocido. La mejor estrategia a seguir en estos casos es tratar de dividir el refactoring en el mayor nmero de pasos pequeos. Tras cada paso el cdigo debe seguir funcionando sin fallos. Antes de abordar cada uno de estos pasos se debe comunicar a todas las personas afectadas por los cambios que se van a realizar. De esta forma se evita que cuando vuelvan a trabajar con ese cdigo se encuentren con un panorama completamente desconocido. En ocasiones tambin es recomendable dar explicaciones despus para explicar el diseo final. Si este tipo de explicaciones deberan de ser frecuentemente, la solucin no es no realizarlas, sino identificar los motivos de tanta refactoring a posteriori, probablemente sea necesario aplicar refactoring continuo en un mayor grado.

5.6 Refactorizacin y pruebas unitarias

La existencia de pruebas automatizadas facilita enormemente el refactoring. Los principales motivos son: El riesgo disminuye, dado que es posible comprobar cuando esta concluye que todo sigue funcionando satisfactoriamente. El desarrollador que realiza el refactoring puede comprobar que no ha estropeado la funcionalidad implementada por otros. Evita efectos colaterales. El tiempo necesario para comprobar que todo sigue funcionando es menor, lo que permite avanzar en pasos ms pequeos si se desea. Refactoring sin tests es una actividad de alto riesgo y no debe hacerse salvo para los refactoring ms simples y realizadas con herramientas especializadas. En ocasiones incluso algunas refactoring muy pequeos pueden provocar la aparicin de bugs muy difciles de identificar a posteriori.
Pg. 41 Versin 1.00

Documento 1

REFACTORING En este sentido es muy importante resaltar la importancia de que las pruebas tanto funcionales como unitarias que comprueben que el cdigo bajo prueba, funcione correctamente independientemente de cmo est implementado. Cuanto mayor sea el acoplamiento de la prueba con la implementacin, mayores sern los cambios que habr que realizar en esta cuando se lleve a cabo, en refactoring grandes, que afectan al diseo del cdigo significativamente, obligarn a realizar cambios en las pruebas. En este sentido tambin resulta til pensar que antes usar el refactoring, se deben ver cmo van a afectar a los tests y cmo podemos usarlos en nuestro beneficio. La mejor solucin es prevenir este refactoring grande es aplicando refactoring continuo y en proporciones ms pequeas. Pero una vez nos encontramos con esta situacin, es recomendable cambiar las pruebas antes o a la vez que el cdigo, de esta forma las pruebas colaborarn guiando el proceso.

6. Ventajas
Refactoring continuo tiene dos ventajas principalmente: El cdigo afectado es el mismo que el que se modific para aadir la funcionalidad y por tanto se reduce o evita completamente los inconvenientes para otros desarrolladores. El tiempo que se debe dedicar es reducido dado que en ese momento se tiene un conocimiento preciso del cdigo que se ver afectado.

7. Desventajas
Adems de la evidente prdida de tiempo, refactoring puede llevar a dos efectos negativos. El primero, es que la modificacin del cdigo incremente la complejidad de nuestro diseo, que es justo el efecto contrario del que intentbamos lograr al aplicarlo. Por otro, es habitual fomentar la sensacin al desarrollador o bien de todo el equipo de que no se est avanzando. Una sensacin que conduce a repercusiones anmicas negativas. A veces, el no comentar con el resto del equipo un refactoring que parece muy necesario, puede afectar a otros compaeros y de los que no ramos conscientes. En refactoring grandes, que afectan al diseo del cdigo significativamente, obligarn a realizar cambios en las pruebas. Esto provoca una situacin incmoda, las pruebas que deben ser una ayuda se convierten en este caso en un estorbo.

Documento 1

Pg. 42

Versin 1.00

REFACTORING

8. Recomendaciones
- No hay que escribir muchos comentarios en el cdigo. Con demasiados comentarios se obtiene lo contrario a lo deseado es decir, ofuscacin en lugar de claridad y un esfuerzo y tiempo extra por parte del desarrollador (los comentarios hay que mantenerlos junto con el cdigo). Por eso no es bueno abusar de los comentarios. - Las partes ms complejas del cdigo (por ejemplo en un algoritmo, una compleja operacin matemtica, un tipo complejo de datos, etc.) que no sean triviales a simple vista deberan llevar un mnimo de comentarios para ayudar a su comprensin y entendimiento puesto que la refactorizacin por si sola no da la suficiente informacin con los nombres de funciones, variables, mtodos, clases, etc. - Refactorizar, es decir, hacer el cdigo ms limpio, claro, manejable y mantenible (mejorarlo a grandes rasgos) debera ser obligatorio cada vez que se escribe, rescribe o se mantiene cdigo. - Cada refactorizacin que realicemos debe estar justificada. Slo debemos refactorizar cuando identifiquemos cdigo mal estructurado o diseos que supongan un riesgo para la futura evolucin de nuestro sistema. - La Refactorizacin no es un proceso que podemos aislar como una tarea. Es necesario que lo incluyamos como una actividad que realizaremos cuando estemos desarrollando. - La restructuracin no slo se da en cdigo, sino en todo el proceso de desarrollo de software: datos, diseo externo, documentacin. - Por definicin, los objetos tienen propiedades/caractersticas/atributos (variables) que son propias y que no deben de ser modificables por otros, incluso objetos del mismo tipo.

Documento 1

Pg. 43

Versin 1.00

REFACTORING

9. Conclusiones
1- La refactorizacin hace el cdigo muchsimo ms legible y claro (eso es indudable) y aadiendo las pruebas unitarias tenemos incluso una mnima documentacin (y, por supuesto, validacin). 2- Refactorizar es realizar modificaciones en el cdigo con el objetivo de mejorar su estructura interna, sin alterar su comportamiento externo. 3- El desarrollo dirigido por pruebas incluye de forma natural la refactorizacin continua, es lo que se conoce como TDD (Test Driven Development), prctica en la que se hace la prueba, se aade la funcionalidad necesaria para satisfacerla, se generaliza la prueba y se refactoriza. 4- Normalmente desarrollamos nuestros sistemas de software a marchas forzadas, apremiados por los plazos de entrega, lo cual acaba generando un cdigo desordenado. 5- El problema de abordar una refactorizacin es que supone un esfuerzo que no se ve compensado por ninguna nueva funcionalidad y por ese motivo muchas veces es complicado de justificar. 6- La refactorizacin de cdigos no es una tcnica para encontrar y/o corregir errores. 7- El tema de Refactoring esta inmaduro: Falta de documentacin escrita. Falta y mejora de herramienta.

Documento 1

Pg. 44

Versin 1.00

REFACTORING

10. Bibliografa
[1]. Kerievsky, Joshua (2004). Refactoring to Patterns. Addison Wesley. [2]. Martin Fowler, Kent Beck, John Brant y William Opdyke, Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999. [3]. Prez Jess, Ferrer Jorge Refactorizacin en la prctica: peligros y soluciones

Documento 1

Pg. 45

Versin 1.00