Refactorización

Refactorización es el proceso de cambiar un sistema de software de tal manera que no altera el comportamiento externo del código pero mejora su estructura interna. Es una forma disciplinada de limpiar el código que minimiza las posibilidades de introducir errores. (Si quieres saber más sobre código limpio te invito a leer este artículos)

Con la refactorización puede tomar un mal diseño, incluso un caos, y volver a trabajar en un código  bien diseñado. Cada paso es simple, incluso simplista. Sin embargo, el efecto acumulativo de estos  pequeños cambios puede mejorar radicalmente el diseño. 

El problema de la refactorización es que puede ser costoso y altamente peligroso, puesto que se debe cambiar código que funciona por código que no sabemos si puede funcionar. Como solución a este inconveniente se recomienda que el código tenga pruebas unitarias automatizadas.

En este post solo veremos algunos método de refactorización, si quieres conocer un catalogo más amplio y detallado puede ingresar a https://www.refactoring.com/catalog/. 

Los métodos son:

1. Rename: Consiste en cambiar el nombre de variables, métodos o clases según sea el caso con el fin de tener un código limpio, de esta forma el código sea más legible, mantenible entre otras características.
2. Extract Function: En ocasiones se tienen métodos que tienen muchas líneas, realiza más responsabilidades de las que debería hacer o simplemente no queda claro para que se quiere ese método. Para solucionar lo anterior se debe crear un método o métodos donde se realice la operación que se quiere extraer del método principal con el fin de separar las responsabilidades o entender mejor el método.
3. Inline: Un caso especifico del método en linea se presenta cuando tenemos uno o mas métodos cuyos códigos son lo suficientemente auto-explicativos como para poder prescindir de ellos. Bastará con sustituir las llamadas al método por el cuerpo de dicho método; pero esto también ocurre con las variables, en ocasiones se tiene una variables que solo se usa para almacenar un valor y posteriormente retornarlo.
4. Extract Class: Cuando una clase hace el trabajo de dos, resulta torpe. En su lugar, cree una nueva clase y coloque los campos y métodos responsables de la funcionalidad relevante en ella.
5. Encapsulated Fields: Consiste en cambiar los modificadores de acceso que se requieran. Por ejemplo se cambian métodos públicos a privados porque solamente se acceden desde la misma clase.

El camino es largo y conlleva aprender más métodos y adquirir nuevas destrezas pero te aseguro que dando este primer paso veras cambios significativos en tu código.

Para poner en práctica estos métodos puedes ingresar a mi repositorio https://github.com/cedaniel200/Refactorizacion donde encontraras una series de ejercicios simples para afianzar los conceptos vistos.

Adicionalemente te recomiendo este excelente libro de Martin Fowler llamado Refactoring: Improving the Design of Existing Code 1era Edición o su 2da edición.

Espero que si realizas mis ejercicios propuestos, al finalizarlos, me dejes un comentario con la retroalimentación de los mismos.

Para finalizar te recomiendo este otro artículo donde hablo acerca de los principios SOLID una destreza que debes adquirir si sigues el camino para ser un excelente desarrollador de software.

Principio de Inversión de Dependencia

Es un principio estructural, que habla que los módulos de alto nivel no deben depender de los módulos de bajo nivel, en otras palabras las dependencias del código se refieren solo a abstracciones, no a concreciones. El seguir este principio nos da el control sobre la dirección de todas las dependencias.

Para ilustrar lo anterior miremos la siguiente imagen.

En esta imagen vemos dos componentes uno es el de las vistas y otro es el de los controladores y como se observa un controlador necesita una instancia de la vista para poder indicar que acción realizar, pero esto presenta varios problemas, por ejemplo, no queremos que un cambio en la Vista1 nos obligue a volver a compilar o modificar nuestra clase Controlador1, para esto podemos usar la inversión de dependencia como veremos en la siguiente imagen.

Al crear una interfaz en el componente de los controladores que abstrae el comportamiento de una vista podemos invertir la dependencia, ahora el componente de las vistas depende del componente de los controladores, de esta forma protegemos al componente de los controladores de los cambios en componente de las vistas.

Que tal si vemos un ejemplo más concreto para ver esto.

Imaginemos estamos viendo el espectáculo de Gepetto y Pinocho y decidimos recrearlo en una pequeña aplicación.

Para empezar con nuestra aplicación debemos hacernos un par de preguntas.
¿Quien conoce como manipular un títere?, ¿Quien realiza la acción?. Es claro que quien sabe como manipular un títere es Gepetto y quien realiza la acción es Pinocho, solo con estas dos simples preguntas ya podemos hacernos una idea quien tiene las funciones de alto nivel y quien las de bajo nivel.

Gepetto contiene las funciones de alto nivel (Es quien conoce las reglas del negocio y sabe como manipular un titere), cuales serian estas funciones.

• void mostrarTitereInmovil();
• void moverCabezaDelTitere();
• void moverBrazoIzquierdoDelTitere();
• void moverBrazoDerechoDelTitere();
• void moverPiernaIzquierdoDelTitere();
• void moverPiernaDerechoDelTitere();

Pinocho contiene las funciones de bajo nivel (Es quien simplemente realiza las acciones que Gepetto sabiamente le ordena), cuales serian estas funciones.

• void inmovil();
• void moverCabeza();
• void moverBrazoIzquierdo();
• void moverBrazoDerecho();
• void moverPiernaIzquierdo();
• void moverPiernaDerecho();

Para ilustrar esto tendremos dos componentes uno de alto nivel (donde estará Gepetto) y otra de bajo nivel (Donde estará Pinocho). A estas alturas es obvio que Gepetto debe tener una instancia de Pinocho para poder manipularlo por lo que el diagrama se vería algo así.

Es evidente a simple vista que el componente de alto nivel depende del componente de bajo nivel lo cual es un error, imaginemos que Pinocho sale a vacaciones y viene en su reemplazo Pepito Grillo, ¿Qué pasaría?, ¿Tendríamos que hacer cambios en nuestra aplicación?, es obvio que la respuesta es si, primero Gepetto no debería estar condicionado a trabajar con un solo títere, él es un titiritero y sabe manipular a cualquier títere que le pongan, por lo cual empiezo a evidenciar un problema de abstracción, una ultima consideración seria, y que tal que él que salga a vacaciones es Gepetto, podríamos crear un nuevo titiritero para Pinocho, es evidente que con el diseño actual no podríamos, por lo que vamos a hacer una mejor abstracción y mejorar considerablemente nuestro diseño e invirtiendo la dependencia.

Creo que ya nos dimos cuenta que los conceptos principales del dominio de la aplicación son Titiritero y Títere por lo que creo que deberíamos abstraer su comportamiento creando dos Interfaces y que estas contengan la declaración de las funciones ya mencionadas.

Como segundo paso Gepetto debería implementar la interfaz Titiritero porque es claro que él es un titiritero.

El tercer paso consiste en que Pinocho implemente la interfaz Titere.

Ahora Gepetto no debe tener una instancia de Pinocho sino declara una variable de clase de tipo Titere y es necesario entonces que los titiriteros tengan una función adicional setTitere(Titere titere) tengamos presente que en un espectáculo de títeres un titiritero puede cambiar contantemente de títere y creo que esta función le caería de mil maravillas.

Por ultimo viene la pregunta crucial donde deben ir estas interfaces porque de dicha ubicación dependen si se logra la inversión de dependencia o no.  Imagino que ya tienes la respuesta, si así es, deben ir en el componente de alto nivel, nuestro nuevo diagrama queda así.

Si comparas los dos diagramas ahora la flecha de dependencia se ha invertido y el componente de bajo nivel depende del componente de alto nivel y nuestra aplicación ahora puede crecer de una forma mas flexible, puedes crear más títeres y mas titiriteros si así lo deseas.

El código fuente de este ejemplo en encuentras en mi repositorio de GitHub dedicado a la Programación Orientada a Objetos

Si deseas ampliar más este tema te recomiendo el artículo The Dependency Inversion Principle de Robert C. Martin.

Si deseas leer sobre los demás principios SOLID da click aquí.

Principio de Segregación de la Interfaz

Este es un principio estructural y para definirlo utilizare la conclusión dada por Robert C. Martin en su libro Arquitectura limpia mas un par de mis palabras, entonces, este principio se ocupa de las desventajas de depender de algo que carga con un equipaje que no necesita, ya que, depender de esto puede traerle problemas que no espera.

En algunos otros textos se hablara de depender de interfaces "gordas" (Interfaces que declara más métodos de los que necesita una clase) y estas clases que tienen interfaces "gordas" son clases cuyas interfaces no son cohesivas, por lo que son forzadas a depender de interfaces que no utilizan. Cuando los clientes se ven obligados a depender de interfaces que no usan, esos clientes están sujetos a cambios en esas interfaces, esto resulta en un acoplamiento inadvertido entre todos los clientes.

Ilustremos lo anterior con un ejemplo, imaginemos que tenemos una clase llamada OperacionesMatematicas con 4 métodos (sumar, restar, multiplicar y dividir), esta clase es empleada por 4 clientes y cada uno utiliza solo uno de los métodos. Como ven si estamos empleando un lenguaje de programación como Java cada cliente se vería obligado a depender los demás métodos, lo anterior lo vemos en la imagen.

La solución al problema anterior lo vemos en la siguiente imagen, donde se segregan las operaciones en interfaces.

Si deseas ampliar más este tema te recomiendo el artículo The Interface Segregation Principle de Robert C. Martin.

Si deseas leer sobre los demás principios SOLID da click aquí.

Principio de Sustitución de Liskov

En la siguiente cita Barbara Liskov definía los subtipos:

Lo que se busca aquí es algo parecido a la siguiente propiedad de sustitución: si por cada objeto o1 del tipo S hay un objeto o2 del tipo T, como aquel para todos los programas P definidos en términos de T, el comportamiento de P no cambia cuando o1 es sustituido por o2, por lo que S es un subtipo de T.  Barbara liskov, "Data Abstraction and Hierarchy", SIGPLAN Notices 23, 5 (Mayo 1988).

Esto es lo que se conoce como Principio de Sustitución de Liskov, el cual hace parte de los principios SOLID y podemos llevarlo a otras palabras no tan formales, más simples y coloquiales, por lo que se podría decir que:

Las clases Base deben poder usar objetos de clases derivadas sin conocerlos. Es decir los tipos derivados son completamente sustituibles por sus tipos base.

En otras palabras este principio afirma que, para crear sistemas de software a partir de partes intercambiables, esas partes deben adherirse a un contrato que les permita ser sustituidas por otras.

Veamos un ejemplo para poder entender mejor esto.

Imaginemos que tenemos una clase Motor como se muestra en la imagen anterior, esta clase tiene un método prender() y dos subtipos Motor2Tiempos y Motor4Tiempos y cada uno tiene su forma de prender. Por su parte la clase Motocicleta invoca el método prender() independiente de cual de los dos subtipo utilice (Ambos subtipos son sustituibles por el tipo Motor) lo que garantiza que se esta cumpliendo el principio de sustitución de Liskov. 

Espero este sencillo ejemplo les permita entender de una forma simple este principio.

Si deseas ampliar más este tema te recomiendo el artículo The Liskov Substitution Principle de Robert C. Martin.

Principio de Responsabilidad Única

Este principio es clave en la programación orientada a objetos, y nos dice que cada clase debe tener un solo motivo para cambiar, entendiendo como motivo la responsabilidad que tiene la clase, en otras palabras, para qué fue hecha o qué hace en específico. También se le puede llamar cohesión, entendiendo cohesión como la medida en que un componente (clase, paquete, método) se dedica a realizar solo la tarea para la cual fue creado.

¿Por qué es necesario aplicar este principio? Bueno, partamos de que tenemos una clase A que tiene dos responsabilidades, es decir, hace dos cosas; de ahora en adelante las llamaremos R1 y R2. En el cuerpo de la clase, esta tiene varios métodos, donde algunos de estos se utilizan tanto para llevar a cabo R1 como para R2. Al momento de la creación de la clase no hay ningún problema y todo funciona bien.

Un mes después ...

Es hora de mantener nuestra aplicación, debemos cambiar una clase. Espero hayas adivinado qué clase es, ¡sí, es la clase A!, resulta que R1 no está del todo bien y se debe corregir, entonces, empieza nuestra labor.

Tres días después, 500 tazas de café y pocas horas de sueño después ...

Creemos que hemos terminado y cuando se empiezan a realizar las pruebas... OOOOOH sorpresa, tú o el equipo de testing (o como se le llame en tu empresa) se dan cuenta que ahora R1 funciona bien, pero R2 no funciona. ¿Qué pasó?, recordemos algo: “Algunos de los métodos de la clase A se utilizan por R1 y R2”, entonces al modificar alguno de estos métodos, se corrige R1 pero genera errores en R2.

Es por lo anterior que se debería cumplir este principio, así cuando se haga un cambio tendremos la certeza que solo se afectará una responsabilidad. Otra justificación se hace evidente cuando ocurre un error y se detecta qué es, es fácil identificar la clase que tiene esa responsabilidad.

Si deseas ampliar más este tema te recomiendo el artículo The Single Responsibility Principle de Robert C. Martin.

Si deseas leer sobre los demás principios SOLID da click aquí.