Rojas Garca Ral Omar

3cv2

Un Refactoreo Bsico solo se trata de optimizar la legibilidad del cdigo y en algunas oportunidades mejorar substancialmente el rendimiento del mismo. Muchos desarrolladores creen que escribir todo en una sola lnea es una tcnica vlida de Refactoreo. La respuesta es No. Por ejemplo:

Button2.BackColor = Color.Violet : Button2.ForeColor = Color.White : ...

Este trozo de cdigo no encierra estrategias de Refactoreo, de hecho, lo invitara a que evite este tipo de codificaciones por varias razones. La primera y la de mayor peso es la organizacin de su cdigo y por otro lado evitar potenciales errores de diversa ndole. Como siempre le digo a mis alumnos, "Que Ud., tenga un Automvil y lo utilice para llevar un mueble de su cocina a la casa de su ta, no significa que su Automvil se trate de una Pick-Up o 4x4". Aqu ocurre exactamente lo mismo. Que funcione no significa que sea apropiado. Refactoreo Sencillo

Para ver un caso de refactoreo muy sencillo, analicemos el siguiente cdigo que est hecho en Visual Basic .NET Insisto nuevamente, esta tcnica podra aplicarla en otros lenguajes. Tan solo deber encontrar la sintaxis apropiada para cada estructura de refactoreo. Como ver, no resulta para nada complicado.

Button2.BackColor = Color.Violet Button2.ForeColor = Color.White Button2.Text = "Mi Botn" Button2.TextAlign = ContentAlignment.MiddleCenter Button2.Width = 80 Button2.Height = 30

Si observa detenidamente vera que el objeto Button2 se repite en cada lnea para cada propiedad asignada. Pues bien, una sencilla forma de Refactorizar este cdigo, simplemente, bastar con organizar el cdigo utilizando el estamento With...End. Vase el siguiente resultado de un Refactoreo extremadamente sencillo.

Rojas Garca Ral Omar

3cv2

With Button2 .BackColor = Color.Violet .ForeColor = Color.White .Text = "Mi Botn" .TextAlign = ContentAlignment.MiddleCenter .Width = 80 .Height = 30 End With

Ahora bien, siguiendo de cerca el Refactoreo recientemente hecho, an podemos seguir mejorando nuestro cdigo. Si observa las propiedades finales Width y Heigth, como sabr, ambas responden a la clase Size. Bien, por tanto, podemos utilizar la clase Size para pasarle mediante una instancia constructor los valores de Width y Height en una sla lnea. Aqu s no solo ahorramos lneas de cdigo y legibilidad, sino que tambin, mejoramos el rendimiento del cdigo dado que lo estamos orientando fuertemente a objetos. Veamos como quedara esta nueva modificacin.

With Button2 .BackColor = Color.Violet .ForeColor = Color.White .Text = "Mi Botn" .TextAlign = ContentAlignment.MiddleCenter .Size = New Point(80, 30) End With

Rojas Garca Ral Omar BAD CODE SMELLS

3cv2

Determinar qu cdigo necesita refactorizarse es ms subjetivo. Martin Fowler presenta en su libro una serie de pistas, basadas en la idea de "malos olores" del cdigo de Kent Beck. Estos "malos olores" son patrones que, por experiencia de Beck y Fowler, son evidencias habituales de problemas en el diseo. A continuacin resumir estos "malos olores". Voy a intentar traducir los nombres que usan para ellos, pero dejar tambin el original en ingls, porque as es ms fcil encontrar referencias a los mismos: Cdigo duplicado (Duplicated Code): Si encontramos la misma estructura de cdigo en varios sitios, lo mejor es unificarla en un nico punto. Mtodo largo (Long Method): Los mtodos pequeos son ms claros en lo que hacen y permiten compartir el cdigo y que se pueda elegir el mtodo a llamar segn el caso. La sobrecarga en la llamada a un mtodo es casi despreciable, por lo que no debe ser excusa para usar mtodos lo ms pequeos posible. Clase grande (Large Class): Una clase que hace demasiadas cosas suele tener muchas variables de instancia y, tras ellas, suele haber cdigo duplicado. Si una clase no utiliza todas sus variables de instancia en todo momento, las que no se usen se deberan eliminar o extraer a otra clase. Lista de parmetros larga (Long Parameter List): De forma distinta a lo que ocurra con tecnologas anteriores, cuando se usan objetos, no hace falta pasar a un mtodo toda la informacin que necesita para su ejecucin, sino slo aquella que es imprescindible para que puede obtener todo lo que necesita. Cambio divergente (Divergent Change): Cuando hay que hacer un cambio, debemos ser capaces de identificar un nico punto en el programa donde ste deba hacerse. Si tenemos una clase donde debamos cambiar 3 mtodos por una razn y otros 4 por otra causa distinta, tal vez este objeto debera ser dividido en 2 con distintas responsabilidades. Cura de un escopetazo (Shotgun Surgery) : Este caso es el contrario del anterior. Hay y que hacer un cambio y para ello deben modificarse varias clases desperdigadas por el cdigo. Los mtodos afectados deberan agruparse en una sola clase. Envidia de capacidades (Feature Envy): Si un mtodo de una clase hace referencia ms a mtodos y parmetros de otra clase, tal vez sea en esa otra clase donde debera estar. Agrupaciones de datos (Data Clumps): Si un grupo de datos aparecen constantemente juntos y se usan siempre en los mismos momentos, estos datos deberan agruparse dentro de un objeto. Obsesin por los tipos primitivos (Primitive Obsession): Existen ciertos datos que estn mejor agrupados en pequeas clases, en lugar de usar primitivas, aunque esto ltimo parezca ms sencillo. Usar clases para estos datos ofrece nuevas capacidades como aadir nueva funcionalidad o realizar comprobaciones de tipo de datos. Sentencias switch (Switch Statements): A veces se encuentran las mismas sentencias switch repartidas por el cdigo. Si se incluye un nuevo apartado clause se debe hacer para todas ellas y es fcil saltarse alguna. Normalmente esto es manejado mucho mejor a travs de polimorfismo, cobre todo cuando la sentencia switch acta en funcin de un valor que define el tipo de un objeto.

Rojas Garca Ral Omar

3cv2

Jerarquas paralelas de herencia (Parallel Inheritance Hierarchies): Esto ocurre cuando al aadir una clase en una jerarqua se hace evidente la necesidad de aadir una nueva clase en otra jerarqua distinta. Si las instancias de una jerarqua hacen referencia a las de la otra se puede eliminar una de ellas llevando sus mtodos a la otra. "Clase vaga" (Lazy Class): Una clase que no hace nada est aadiendo una complejidad innecesaria y es mejor hacerla desaparecer. Generalizacin especulativa (Speculative Generality): Cuando se aade funcionalidad especulando sobre lo que necesitaremos en el futuro, pero que en este momento es innecesario, el resultado es cdigo ms difcil de entender y mantener. Es mejor deshacerse de ello. Campo temporal (Temporary Field): Si existen variables de instancia que parecen usarse slo en algunos casos, puede ser confuso entender en cules. Es mejor sacar estas variables a otra clase. Cadenas de mensajes (Message Chains): Estas cadenas aparecen cuando un cliente pide a otro objeto un objeto y a su vez llama a ste ltimo para obtener otro objeto. De esta menra, el cliente se acopla a toda esta estructura de navegacin y cualquier cambio en ella le afectar. Es mejor recuperar otros objetos mediante un delegado que encapsule dicha navegacin y abstraiga al cliente de ella. "Hombre en el medio" (Middle Man): El caso anterior no es necesario que se cumpla a rajatabla. A veces, si existen muchos mtodos que delegan a una misma clase, es mejor quitarnos el delegado y referirnos a ella directamente. Intimidad inapropiada (Inappropiate Intimacy): Cuando una clase se dedica a hurgar en partes de otra clase que parecen ser privadas, ha llegado el momento de desacoplar dichas clases, por ejemplo, a travs de una tercera que contenga la funcionalidad comn de las dos anteriores. Clases alternativas con interfaces diferentes (Alternative Classes with Different Interfaces): Si tenemos dos mtodos que hace los mismo pero se llaman de forma distinta, es mejor unificarlos para que se use siempre un nico mtodo. Clase de librera incompleta (Incomplete Library Class): A veces una clase de una librera de tercero no hace todo lo que necesitamos y debemos adaptar su uso a nuestras necesidades ya que no podemos modificarla. Clase de datos (Data Class): Las clases que solo tienen datos getters y setters son manipuladas en gran medida por otras clases. Podemos buscar este comportamiento para llevarlo a las clases que contienen los datos. Legado rechazado (Refused Bequest): A veces una subclase no usa todos los mtodos que hereda de su clase padre. Esto puede significar que la jerarqua no es correcta y los mtodos de las clases se deben mover a donde se usan realmente. Comentarios (Comments): A veces los comentarios lo que estn enmascarando es uno de los "malos olores" que se han visto anteriormente. Es mejor invertir el tiempo en mejorar este cdigo que en comentarlo.