CSO Unidad 1A PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES

Ph.D. Franklin Parrales 124/10/2021

Construcción de Software Carrera de Software

PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES

Unidad 1A

Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo

para uso de los cursos de Construcción de Software

http://creativecommons.org/licenses/by-nc-sa/3.0/



Objetivo general de la Unidad 1

Identificar los principios básicos del desarrollo de software

y del tratamiento de excepciones en el desarrollo mediante

la aplicación de técnicas usadas en la industria para

construir software seguro.



Unidad 1: Principios básicos de construcción de

software y tratamiento de excepciones

• Principios básicos del desarrollo de software

• Refactorización del código

• Detección de errores

• Tolerancia a fallos y tratamiento de excepciones

Unidad 1A



Objetivos específicos

• Seguir las fases adecuadas para llegar a una

solución de un problema

• Desarrollar un estilo de programación propio y

adecuado

• Valorar la importancia de la documentación

interna del código



¿Que queremos decir con proceso de

desarrollo?

Deseos, necesidades, Especificaciones, …

Software



Introducción al proceso de desarrollo.

• En general, cuando las personas abordan

el desarrollo de cualquier proyecto

evolucionan desde ideas abstractas hacia

concreciones realizables.



¿Donde nos encontramos?

• Con Problemas, tendremos que disponer de:

– Técnicas de desarrollo que minimicen la

complejidad de un sistema software.

– Métodos y conceptos que permitan al productor y

al cliente explorar la naturaleza del sistema

software lo antes posible.

– Técnicas que minimicen los efectos

devastadores de las modificaciones durante el

desarrollo y la explotación.



¿Que hace un Ingeniero?

• Construir artefactos dentro de unas

limitaciones de coste, utilizando el

conocimiento y las teorías de la ciencia sobre

la cual se basa el artefacto.



Síntesis automática de software

Requerimientos

Informales Análisis de

Requerimientos

Especificación Formal

(Prototipo)

Validación

Mantenimiento Optimización

Mecánica

Desarrollo

Formal

Ajuste

(tuning)

Programa

Fuente

Racionalidad y

Decisiones






– Principios de construcción y cambio de software

– Principios SOLID






Es extraño que alguien diga:

– "Me puse a programar y me salió una

contabilidad"

– Algunas aplicaciones da la impresión de que...– Recordar que la probabilidad de que un mono teclee en

una maquina de escribir y salga el quijote no es cero



El Software se desarrolla, no se

fabrica.

• En cualquier sistema de producción

podemos observar dos fases la de

desarrollo y la de fabricación.• El desarrollo es lento y costoso.

• La fabricación en serie y con costes estables.

• Con el Software ocurre lo mismo pero ...• Muchas aplicaciones se desarrollan a medida, sin

usar componentes existentes.

• La fabricación no se considera tal.



Normalmente el planteamiento es:

• Vamos a desarrollar una contabilidad,» Hacer la especificación. (Ingeniería de requerimientos)

• en Java y MySql,» Realizar el diseño (Modelamiento de software, Diseño

y Arquitectura de Software)

• y se codifica la aplicación» Implementar (Construcción de software)



El grado de precisión con que se lleve a

cabo cada paso influirá en el resultado

• ¿Me podrías indicar, por favor, hacia dónde

tengo que ir?

• Eso depende de adónde quieras llegar,

contesto el gato.

• A mí no me importa demasiado adónde...-

empezó a explicar Alicia.

• En ese caso, da igual cualquier dirección -

interrumpió el Gato.

• ...Siempre que llegue a alguna parte -

terminó Alicia a modo de explicación.

• Basta que empieces a andar - le aseguro el

Gato-, dando un paso tras otro.

– Alicia en el país de las maravillas



El software es excesivamente

maleable.

• Todo el mundo exige que se realicen

cambios sobre el Software como

respuesta a pequeños cambios del

entorno.

• Además no es fácil comprender su

comportamiento, según Pressman:

– La curva de fallos del Hardware.

– La curva ideal de fallos del Software.

– La curva real de fallos del Software.



Tiempo

Ind

ice

de

fa

llos

Defectos fabricación Estropeado

Obsolescencia

Curva de fallos del Hardware.



Curva ideal de fallos del Software.

Tiempo

Ind

ice

de

fa

llos

Defectos fabricación

Mismo nivel hasta obsoleto

Obsolescencia



Curva real de fallos del Software.

Tiempo

Ind

ice

de

fa

llos

Defectos fabricación

Curva ideal

Cambio Cambio Cambio

Obsolescencia



Resolución de problemas

• Proceso completo donde

– Se toman las descripciones de un problema y

– Se desarrolla un programa de computadora

para resolverlo

• Requiere de algunas fases

– Comprender bien el problema

– Diseñar la solución en forma conceptual

– Implementar la solución con un programa en

la computadora



Componentes de una solución

• Para llegar a una solución es necesario:

– La especificación de los pasos para llegar a ella

– Datos necesarios para generarla

• Los algoritmos operan sobre los datos

• Para facilitar las operaciones sobre los datos

– Organizar los grupos de datos

– Tal como lo necesite el algoritmo

Algoritmo

Armar estructuras de datos o clases ideales



Diseño: Arquitectura vs. Programas

Implementaciones de partes

Interacciones entre partes

Muestra

Copia de código o llamado a bibliotecas

Composición de subsistemas

Reutilización

Dentro de los límites de módulo

Fuera de los límites de módulo

Visión

Desempeño de algoritmos

Desempeño a nivel del Sistema

Evaluación

En general dinámicoEn general estáticoAnálisis

Propiedades computacionales

Propiedades estructurales

Considera

ProgramasArquitectura



Herramientas para resolver problemas

• Para ayudar al diseño de una solución

– Diseño Descendente: Modularidad

– Abstracción• De Procedimientos

• De Datos

– Ocultar Información: Encapsular

– Recursividad

– Programación Orientada a Objetos

– etc.



Diseño descendente

• Permite abordar problemas complejos

• Descomponer el problema grande en varios

pequeños

– Módulos independientes

– Procedimientos, funciones y bloques de código

Mo

du

lari

da

d

Función F1

Función F2

Procedimiento P1

Programa Principal



Descomposición

Deben hacerse módulos, pero con cuidado para permanecer enla cercanía de M. Debe evitarse hacer pocos o muchosmódulos.

Región de

costo mínimo

M

Costo

de

lesfu

erz

o Costo de integración

Costo total del software

Costo por módulo

Número de módulos



Avión militar Avión comercial

Avión de carga Avión de pasajeros

Motor Vendedor de billetes

Avión

1..4

1

Piloto

Reserva

n

1

Línea aérea

Vuelon1

1..2

nn1

1

n

n

▪ Las relaciones de Agregación y Generalización forman jerarquías de clases

Descomposición: Jerarquía de clases



Descomposición: Jerarquía de módulos

• Dividir sucesivamente, obteniendo niveles

– Se formará una jerarquía de módulos

– Los de mas bajo nivel • Resuelven problemas más pequeños y

• Contienen mas detalle

• Hasta que los módulos de nivel inferior

– Sean sumamente simples

– Y solo contengan funciones y procedimientos

– Que resuelven problemas independientes y pequeños



Abstracción procedimental

• En un diseño descendente, un modulo

– Equivale a una “caja negra” y ejecuta una tarea

determinada

• Cada “caja negra” o procedimiento

– Nos interesa lo que hace, no como lo hace

– Puede conocer otras cajas negras y usarlas

• Un procedimiento/modulo ya escrito

– Se puede usar sin saber como esta escrito

– Basta con su nombre y una descripción



Abstracción de datos

• Al analizar un problema, podemos centrarnos en:

– Los datos que vamos a necesitar y

– Las operaciones que se pueden realizar sobre los mismos

– Definiran sus TIPOS DE DATOS ABSTRACTOS o CLASES

• TDAs

– Los módulos los conocerán y usarán

– Sin interesarles como se escribieron sus operaciones

– Se pueden implementar usando estructuras de datos

• Para diseñar una solución se deben desarrollar

– Algoritmos y

– TDAs



Estilo de programación

• Al escribir un programa se busca

– Que sea legible y

– Modificable

– Para quien lo escribió y para cualquier otro programador

• Un lenguaje natural humano tiene

– Sintaxis y reglas de escritura

• Para lograr un estilo de programación

– Se deben también guardar ciertas reglas



Reglas de estilo

• Modularizar en partes coherentes

• Evitar variables globales en los módulos

• Usar nombres significativos para identificadores

• Definir constantes desde el principio

• Escribir módulos que hagan una sola cosa

• Uso adecuado de parámetros por valor/por referencia

• Comentarios adecuados

• Manejo de Errores

• Legibilidad

• Documentación



Cuando modularizar

• Si un conjunto de sentencias realiza una

tarea

– Recurrente, repetitiva, identificable

• Debe ser un módulo

• Sin embargo,

– Una tarea no necesita ser recurrente para

hacerla un módulo



NO a las variables globales

• Se usan módulos para aislar las tareas

– Pero las variables globales no son aisladas

• Si usa variables globales en módulos

– Se pierde aislamiento

– Se expone a generar un caos en la secuencia de

pasos

• Si puede usar variables globales en módulos

– Solo si todos los subprogramas DEBEN acceder

a la misma variable



NO a los objetos degenerados

• Un objeto contiene datos y operaciones quemanipulan los datos, pero ...

• Podemos distinguir dos tipos de objetos degenerados:– Un objeto sin datos (que sería lo mismo que una biblioteca

de funciones). Si los métodos son estáticos, “peor” aún.

– Un objeto sin “operaciones”, con sólo atributos lo quepermitiría crear, recuperar, actualizar y borrar su estado(que se correspondería con las estructuras de datostradicionales)

• Un sistema construido con objetos degenerados NOes un sistema verdaderamente orientado a objetos



Nombres significativos

• Variables, constantes, funciones y tipos de datos

• Use identificadores largos para objetos generales: – Calcular_Movimiento

• Use identificadores cortos para objetos locales: – i, j, k, Indice, Total, etc.

• Use sustantivos para variables, constantes y tipos:– Salario, Total

• Use verbos para nombrar procedimientos: – LeerCaracter, Calcular_Promedio

• Use formas del verbo ser y estar para funciones predicado: – SonIguales, EsCero, EsVacio, etc.



Defina las constantes

• Evite constantes explicitas como:

– 3.1416, para Pi

– 7, para días de la semana

• Defina constantes con sus nombres

– #define Pi 3.141592

– #define NumDiasSemana 7



Cuando usar por valor y por referencia

• Siempre procure usar parámetros por valor

• Si necesita devolver un valor

– Use una función, no un procedimiento, con parámetros por valor

• Si necesita devolver mas de un valor

– Los valores que necesita retornar deben ser parámetros por referencia

• El uso de parámetros por referencia

– Complica la legibilidad y mantenibilidad

– Pero mejora la rapidez del programa



Uso adecuado de funciones

• Una función solo debe devolver el valor requerido– NUNCA TIENE UN EFECTO LATERAL

• Funciones con variables globales– Se rompe aislamiento

– Si las usa, no modifique su valor en la función

• Funciones con parámetros por referencia– Si va a usar parámetros por referencia, trabaje con

procedimientos (void)

• Funciones que realizan E/S– Si va a imprimir leyendas, use procedimientos

– Las funciones no deben realizar E/S



Manejar errores

• Un programa bien diseñado debe

– Comprobar errores en el ingreso de datos

– Comportarse bien cuando encuentra errores

• Un sistema puede

– Presentar un mensaje de error

– Ignorar datos erróneos

– Terminar el programa



Identificación y tratamiento de

excepcionesExcepciones más comunes:

➢ Fracaso al proporcionar un servicio.➢ Proporcionar un servicio o dato erróneo.➢ Corrupción de datos.

Las excepciones se pueden manejar según uno de lossiguientes criterios:Corregir: se restaura el sistema a su estado previo y se

intenta realizar el servicio utilizando una estrategiadiferente.

Reintentar: se restaura el sistema a su estado previo yse intenta realizar el servicio usando la misma estrategia.

Informar: se restaura el sistema a su estado previo, seinforma el problema a un componente de tratamiento deerror y no se proporciona el servicio.



Corregir



Reintentar



Informar



Soporte al Usuario

• Sistema de ayuda debe proveer:

– Mensajes de error

• Amables, concisos, consistentes y constructivos, si es

posible incluir sugerencia para correción

– Ayuda en línea

• Páginas web con hipervinculos, ventanas múltiples

• Cuidar la estructura de navegación, si es compleja los

usuarios se pierden

– Documentación de usuario

• Incluyendo secciones de: instalación, descripción

general, descripción funcional, mensajes de error.



Mensajes de error

Error #27

Identificador de paciente no válido?

El paciente J. Bates no está registrado

Seleccione:

Pacientes para listado de pacientes registrados

Reintentar para reingresar el nombre del paciente

Ayuda para más información

Pacientes

Mensaje orientado al sistema

Mensaje orientado al usuario

Ayuda Reintentar Cancelar

Aceptar Cancelar



Cuidado…



Legibilidad

• Siga las reglas para uso de identificadores

• Use sangría o identación para las líneas del

programa

– Los bloques deben tener unos 3 o 5 espacios de

sangría

– Los {} deben estar alineados

– Use la misma sangría para el mismo tipo de

construcciones



Presentación

• Documentación Interna

– La cabecera del programa• Nombre del programador, fecha actual,

descripción el programa

– Comentarios relativos a la función del programa y los módulos

– Claridad de estilo y formato• Una sentencia por línea

• Identación, líneas en blanco

– Comentarios significativos



Presentación

• Documentación Del Programa

– Un comentario de cabecera incluye

• Descripción del programa: propósito

• Autor y fecha

• Descripción de la entrada y salida del programa

• Descripción de cómo usar el programa

• Descripción de las estructuras de datos

• Descripción de las variables importantes

– En cada módulo aplicar comentarios similares a la cabecera

– Escribir comentarios inteligentes en las partes importantes y

confusas de c/modulo

/* ******************************************** DICCIONARIO - ejemplo de programa distribuido**********************************************AUTORES: Roberto Carlos Lozano Lopez / Sara Palma Amador* Practicas de Sistemas Operativos Distribuidos* 2o. Cuatrimestre. 4o Ingeniería Informática* EPCC - UEX. Curso 98/99**********************************************Archivo dict.c: Diccionario NO distribuido (Paso 1) ***********************************************/

/******************************** Funcion CelsiusAFahrenheit********************************* Uso: f=CelsiusAFahrenheit(c);* Esta funcion retorna el equvalente * en Fahrenheit del valor c en Celsius********************************/



Presentación

• No deje la documentación para la ultima

etapa

• Asegúrese de que código y comentarios

correspondan

• Si hace un cambio en el código, cambie

también el comentario






– Principios de construcción y cambio de software

– Principios SOLID






¿Qué es SOLID en el desarrollo de software?

• SOLID es el acrónimo de cinco principios básicos de diseñoque tienen como intención hacer que el diseño de softwaresea más simple y comprensible permitiendo reducir ademáslos costes de mantenimiento.

• SOLID apunta a lograr una alta cohesión y un bajoacoplamiento en nuestros programas

• Veamos con ejemplos de que se trata cada principio y comoutilizarlo.

– S: Single responsibility principle (Principio de responsabilidadúnica)

– O: Open/closed principle (Principio abierto/cerrado)

– L: Liskov substitution principle (Principio de sustitución de Liskov)

– I: Interface segregation principle (Principio de segregación deinterfaces)

– D: Dependency inversion principle (Principio de inversión dedependencias)



Single responsibility principle(Principio de responsabilidad única)

• Este principio se refiere a la responsabilidad única quedebiera tener cada programa con una tarea bienespecífica y acotada. Se pretende entonces quenuestro programa haga algo determinado y concreto.

• Algunos de los beneficios de este principio deresponsabilidad única:– En relación al testing. Se simplifica porque una clase tiene

una única responsabilidad.

– Se disminuye el acoplamiento porque el tener menorfuncionalidad en una clase hará que esta tenga menosdependencias.

– Se obtiene una mejor y más sencilla organización de lasclases.

• Veamos un ejemplo que no sigue este principio yluego lo modificaremos para que si lo siga.

1



MAL uso de este principio de

responsabilidad únicaEsta

clase UserLogin tiene como responsabilidad realizar el proceso de

login…

…pero además tiene responsabilidad de enviar

mensajes al usuario.

Este código viola el principio de

responsabilidad única. Está haciendo dos cosas con objetivos diferentes.

package solid;

class UserLogin {private final DataBase db;UserLogin(DataBase db) {

this.db = db;}void login(String userName, String password) {

User user = db.findUserByUserName(userName);if (user == null) {

// do something}// login process..

}void sendEmail(User user, String msg) {

// sendEmail email to user}

}

1



BUEN uso de este principio de

responsabilidad única

• ¿Entonces qué deberíamos hacer?

– Sería conveniente separar la clase en dos. Una para lo

específico del login y otra para la funcionalidad de envío

de mensajes.

– Llevemos entonces el método sendMail a otra clase que

tenga como responsabilidad el envío de mensajes.

1

package solid;

class EmailSender {void sendEmail(User user, String msg) {

// send email to user}

}



Open/closed principle(Principio abierto/cerrado)

• El principio de open/closed dice que toda clase,

modulo, método, etc. debería estar abierto para

extenderse pero debe estar cerrado para

modificarse.

• Lo que deseamos es evitar que nuestro código

sea modificado sin intención causando errores o

funcionalidades no esperadas.

• Esta definición puede ser algo confusa. Veamos

un ejemplo para aplicarlo.

2



MAL uso de este principio

abierto/cerrado

• Veamos esta clase Car con la funcionalidad básica para

un vehículo.

2

package solid;

class Car {void accelerate() {

// accelerate car }void stop() {

// stop car }

}

• Ahora si quisiéramos

también agregar

funcionalidad para un

vehículo de

carrera RaceCar podríamos

estar tentados a hacerlo en

la misma clase.

• Un

vehículo RaceCar necesita

este esta funcionalidad

extra injectExtraGas

package solid;

class Car {void accelerate(boolean isCarRace) {if (isCarRace) {injectExtraGas();

}// accelerate car

}void stop() {// stop car

}private void injectExtraGas() {// do..

}}



BUEN uso de este principio

abierto/cerrado• Pero en vez de hacer esto,

para cumplir con el principio de open/closed podemos extender nuestra clase creando otro tipo de clase derivada de la principal.

• Creamos nuestra clase RaceCar que extiende Car agregando aquí la funcionalidad.

• Extendiendo nuestra clase Car estamos seguros que nuestra aplicación que usa Car no se verá afectada de algún modo.

2

package solid;

public class RaceCar extends Car {@Override void accelerate() {

injectExtraGas();super.accelerate();

}private void injectExtraGas() {

// do.. }

}



Liskov substitution principle(Principio de sustitución de Liskov)

• Hablemos ahora de este principio. Este es

quizás el más complejo de los cinco principios.

• El principio de sustitución de Liskov dice que si

la clase A es de un subtipo de la clase B,

entonces deberíamos poder reemplazar B con A

sin afectar el comportamiento de nuestro

programa.

• Veamos algo de código para entender mejor

este concepto.

3




sustitución de Liskov (1/3)• Utilicemos el ejemplo del Auto para demostrar un mal uso de

este principio.

• Creamos una interfaz y dos implementaciones a continuación. La primera para un auto común en nuestra clase Car y la segunda para un auto eléctrico en nuestra clase ElectricCar .

3

package solid.l;

interface ICar {void accelerate();void stop();

}

package solid.l;

public class Car implements ICar {@Override public void accelerate() {

System.out.println("accelerating the car");}@Override public void stop() {

System.out.println("stopping the car");}

}




sustitución de Liskov (2/3)

El auto eléctrico necesita verificar el

estado de la batería, cosa que

hacemos en el método

hasBattery.

3

package solid.l;

interface ICar {void accelerate();void stop();

}

package solid.l;public class ElectricCar implements ICar {

private int battery;

@Override public void accelerate() {System.out.println("accelerating the car");

}@Override public void stop() {

System.out.println("accelerating the car");}public boolean hasBattery() {

System.out.println("checking battery");if (battery < 95) {

System.out.println("the battery is very low :(");return false;

} else {System.out.println("battery OK :)");return true;

}}

}




sustitución de Liskov (3/3)Observa cómo en el caso

de el auto eléctrico necesitamos invocar el

método hasBattery() para luego poder acelerar.

Con este diseño de clases estamos

rompiendo el principio de sustitución porque

necesitamos explícitamente conocer el

tipo de vehículo y no podemos reemplazar la

clase ElectricCar con la interfaz ICar

3

package solid.l;public class CarDrive {

public static void main(String[] args) {String cardType = args[0];if ("car" == cardType) {

Car car = new Car();car.accelerate();

} else if ("electric" == cardType) {ElectricCarBad electricCar

= new ElectricCarBad();if ((electricCar.hasBattery())) {

electricCar.accelerate();}

} else {throw new RuntimeException("Invalid car");

}}

}





Vamos a arreglar esto para que el diseño de

nuestras clases previas

cumplan con este principio.

Arreglemos la clase

ElectricCar

3

package solid.l;public class ElectricCar implements ICar {private int battery;@Override public void accelerate() {if (hasBattery()) {System.out.println("accelerating the car");

} else {System.out.println("I can not accelerate the car");

}}@Override public void stop() {System.out.println("accelerating the car");

}private boolean hasBattery() {System.out.println("checking battery");if (battery < 95) {System.out.println("the battery is very low :(");return false;

} else {System.out.println("battery OK :)");return true;

}}

}





• Veamos como ahora podemos usar el principio de sustitución.

• Para acelerar el auto no necesitamos conocer el tipo de clase.

3

package solid.l;public class CarDrive {

public static void main(String[] args) {ICar car;String cardType = args[0];if ("car" == cardType) {

car = new Car();} else if ("electric" == cardType) {

car = new ElectricCar();} else {

throw new RuntimeException("Invalid car");}car.accelerate();

}}



Interface segregation principle(Principio de segregación de interfaces)

• Este principio es bastante fácil de comprender. Sihabitualmente usas interfaces es muy probable queestés aplicando este principio.

• El principio se segregación de interfaz dice que ningúncliente debería estar obligado a depender de losmétodos que no utiliza.

• ¿Cómo es esto? En una interfaz existente nodeberíamos agregar nuevos métodos que obliguen aimplementar funcionalidad adicional. En vez deagregar métodos a una interfaz existente, es mejorcrear otra interfaz y que la clase que la necesite laimplemente.

• Veamos un ejemplo de cómo de un mal uso deinterfases que viola este principio.

4




segregación de interfaces (1/4)

• Creamos una interfaz para IProduct de la cual luego

crearemos sus implementaciones.

4

package solid.i;public interface IProduct {

String getType();}

• Implementamos un producto Shoes desde la

interfaz IProductpackage solid.i;class Shoes implements IProduct {

@Override public String getType() {return "shoes";

}}




segregación de interfaces (2/4)4

• Implementamos otro producto Games desde la interfaz IProduct

package solid.i;class Games implements IProduct {

@Override public String getType() {return "game";

}}

• Ahora necesitamos que nuestra clase Games también implemente

un método getAge() para conocer para que edad son los juegos.

La forma simple para esto sería agregar a la interfaz IProduct el

método de este modo.package solid.i;public interface IProduct {

String getType();int getAge();

}





• Pero esto nos obligará a implementar el método

getAge() también en todas las clases. Lo

implementamos en nuestra clase Games, en dónde si

aplica este método.

4

package solid.i;class Games implements IProduct {

private int age;@Override public String getType() {

return "game";}@Override public int getAge() {

return age;}// get and set..

}





• Pero nos vemos obligados también a usarlo en esta clase Shoes que no lo necesita.

4

package solid.i;class Shoes implements IProduct {

@Override public String getType() {return "shoes";

}@Override public int getAge() {

throw new UnsupportedOperationException();}

}




segregación de interfaces (1/2)• Lo que podemos hacer para solucionar el problema

anterior del mal uso de este principio es crear otrainterfaz para el caso de productos que requieran laedad getAge() , así solo las clases que necesiten larestricción por edad lo implementarán.

• De este modo NO obligamos a ninguna clase aimplementar el método que no utilizará

4

package solid.i;public interface IProduct {String getType();

}

package solid.i;public interface IRestrictedProduct {

int getAge();}




segregación de interfaces (2/2)4

La clase Shoes solo implementa la

interfaz IProduct

La clase Games ahora

implementa las dos

interfaces. Resolvemos

de este modo el

principio de

segregación de

interfaces.

package solid.i;class Shoes implements IProduct {

@Override public String getType() {return "shoes";}

}

package solid.i;class Games implements IProduct, IRestrictedProduct {

private int age;@Override public String getType() {

return "game";}@Override public int getAge() {

return age;}// get and set..

}



Dependency inversion principle(Principio de inversión de dependencias)

• El principio de inversión de dependencias nos permite desacoplarlos distintos módulos de un software.

• Los que nos dice este principio es que no deben existirdependencias entre los módulos, en especial entre módulos de bajonivel y de alto nivel. Dicho de otro modo nuestra software nodebería depender, por ejemplo, de cómo esta implementados losframeworks para acceso a base de datos o conexiones con elservidor.

• Para este fin debemos depender de interfaces sin conocer quésucede exactamente en la implementación de dichas interfaces.

• Para usar este principio necesitamos este patrón de inversión dedependencias que habitualmente en java se resuelve con lainyección de dependencias. Spring hace un buen uso de esteprincipio.

• Lo que deseamos es que: Las clases de nuestro código nodependan directamente de las clases de bajo nivel. Debemos usarabstracciones a través de interfaces y solo depender de estasabstracciones.

5



MAL uso de este principio

de inversión de dependencias• Tenemos esta clase Cash que recibe un producto y un método de pago. Luego

instancia la base de datos para persistir el producto con su respectivo método de pago.

• Observa que estamos haciendo un uso directo de Database dependiendo directamente de su implementación. Estamos utilizando en nuestro código clases de bajo nivel, la clase MySqlDatabase.

• Si el día de mañana quisiéramos migrar a otra base de datos deberíamos modificar nuestro código directamente.

5

package solid.d;class Cash {

public void pay(Product product, PaymentType paymentType) {MySqlDatabaseBad persistence = new MySqlDatabaseBad();persistence.save(product, paymentType);

}}

package solid.d;class MySqlDatabase{

void save(Product product, PaymentType paymentType) {System.out.println("Save product " + product +

" paymentType " + paymentType);// save into MySqlDatabase...

}}




inversión de dependencias (1/2)• Lo primero que tenemos que hacer es dejar de depender

directamente de la clase concreta MySqlDatabase por lo que vamos a crear una interfaz que nos desacople de la persistencia. No tenemos porqué saber en nuestro código como o donde se guarda el producto.

• Creamos nuestra interfaz para la persistencia

5

package solid.d;interface Persistence {

void save(Product product, PaymentType paymentType);}

package solid.d;class MySqlDatabase implements Persistence {

public void save(Product product, PaymentType paymentType) {System.out.println("Save product " + product + " paymentType " + paymentType);// save into MySqlDatabase...

}}

• Implementamos la interfaz en nuestra clase MySqlDatabase




inversión de dependencias (2/2)• Nuestra clase cash ahora recibirá la interfaz Persistence en

el constructor.

• ¿Se ve mejor así, no?

• La clase ya no necesita saber quién o cómo implementa la

persistencia. La clase Cash utiliza la interfaz y desconoce su

implementación.

5

package solid.d;class Cash {

Persistence persistence;public Cash(Persistence persistence) {

this.persistence = persistence;}public void pay(Product product, PaymentType paymentType) {

persistence.save(product, paymentType);}

}

Persistence a = new MySqlDatabase();Cash c= new Cash(a);c.pay(“01223”,“EFECTIVO”);



Conclusión

• Vimos para cada principio SOLID ejemplosde mal uso y luego como corregirlo paratener una idea clara de los beneficios queobtenemos utilizando esos principios.

• Aplicando estos principios hacen que tucódigo sea reusable, mantenible, escalable.Ayudando además que sea más fácil sutesteo.

• No te olvides de usarlos, ganarás mucho enla legibilidad de tu código.



Referencias

• Fowler,

Martin. Refactoring:

improving the design

of existing code.

Addison-Wesley

Professional, 2018.

• https://refactoring.com/

• https://refactoring.guru

/es

https://refactoring.com/

https://refactoring.guru/es







– Conceptos básicos

– ¿Cuando refactorizar?

– Técnicas de refactorización

– Code smells

• Detección de errores.




Refactoring

• La refactorización esun procesosistemático paramejorar el código sincrear una nuevafuncionalidad.

• El propósito estransformar un códigodesordenado en uncódigo limpio y dediseño simple.

La refactorización de código tiene el objetivo de que los métodos puedan

leerse de la manera más fácil posible.

En el mejor de los casos, los programadores externos que lean el código

deberían poder captar la lógica interna del método.



La vida de un ingeniero de software

Mucho después…

Pizarra limpia. Cimientos sólidos. Esta vez construiré

las cosas de la forma correcta.

Oh no... Lo he vuelto a hacer, ¿no es así?



¿Por qué refactorizar?

• Para mejorar el diseño de software

• Para contrarrestar el deterioro del código (envejecimiento del software), la refactorización ayuda a que el código se mantenga en forma

• Para aumentar la comprensibilidad del software

• Para encontrar errores y escribir código más robusto

• Para aumentar la productividad (programar más rápido) a largo plazo, no a corto plazo

• Para reducir los costos de mantenimiento del software.

• Para reducir las pruebas

– Se garantiza que las refactorizaciones automáticas preservan el comportamiento.

• Preparar / facilitar futuras personalizaciones.

• Para convertir una aplicación OO en un framework

• Para introducir patrones de diseño de una manera que conserve el comportamiento.



Dirty Code

• El código sucio es el resultado de la inexperiencia multiplicada por plazos ajustados, mala gestión y atajos desagradables tomados durante el proceso de desarrollo.



Code smells

• Los olores de código son indicadores de problemas que se pueden abordar durante la refactorización.

• Los olores de código son fáciles de detectar y corregir, pero pueden ser solo síntomas de un problema más profundo con el código.



Refactoring techniques

• Las técnicas de refactorización describen los pasos de refactorización reales. – La mayoría de las

técnicas de refactorización tienen sus pros y sus contras.

– Por lo tanto, cada refactorización debe estar debidamente motivada y aplicada con precaución.



Clean Code

• El código limpio es un código que es fácil de leer, comprender y mantener.

• El código limpio hace que el desarrollo de software sea predecible y aumenta la calidad del producto resultante.



Refactoring Process

• El llevar a cabo la refactorización paso por paso y el ejecutar las pruebas después de cada cambio son elementos clave de la refactorización que la hacen predecible y segura.










– Code smells





¿Cuando refactorizar?

• Regla de tres– Cuando esté haciendo algo por

primera vez, simplemente hágalo.

– Cuando esté haciendo algo similar por segunda vez, sienta vergüenza de tener que repetir, pero haga lo mismo de todos modos.

– Cuando esté haciendo algo por tercera vez, comience a refactorizar.




• Al agregar una nueva característica

– La refactorización te ayuda a comprender el código de otras personas.

• Si tiene que lidiar con el código sucio de otra persona, intente refactorizarlo primero.

• El código limpio es mucho más fácil de comprender.

• Lo mejorará no solo para usted, sino también para quienes lo utilicen después de usted.

– La refactorización facilita la adición de nuevas funciones.

• Es mucho más fácil realizar cambios en el código limpio.




• Al reparar/corregir un error (bugs)– Los errores en el código se comportan

como los de la vida real: viven en los lugares más oscuros y sucios del código.

– Limpia tu código y los errores prácticamente se descubrirán por sí mismos.

– Los gerentes aprecian la refactorización proactiva, ya que elimina la necesidad de realizar tareas especiales de refactorización más adelante.

– ¡Los jefes felices hacen felices a los programadores!




• Durante una revisión de código

– La revisión del código puede ser la

última oportunidad para poner en

orden el código antes de que esté

disponible para el público.

– Es mejor realizar estas revisiones en

pareja con un autor. De esta manera,

podría solucionar problemas simples

rápidamente y calcular el tiempo para

solucionar los más difíciles.










– Code smells





Técnicas de refactorización

• Composing Methods

• Moving Features between Objects

• Organizing Data

• Simplifying Conditional Expressions

• Simplifying Method Calls

• Dealing with Generalization



Composing Methods(Métodos de composición)

• Gran parte de la refactorización se dedica a componer correctamente los métodos.

– En la mayoría de los casos, los métodos excesivamente largos son la raíz de todos los males.

– Los fragmentos de código existentes dentro de estos métodos:

• ocultan la lógica de ejecución y

• hacen que el método sea extremadamente difícil de entender,

• e incluso más difícil de cambiar.

• Las técnicas de refactorización de este grupo agilizan los métodos, eliminan la duplicación de código y allanan el camino para futuras mejoras.



1) Extract Method

• Problema: Tiene un fragmento de código que se puede agrupar.

void printOwing() { printBanner(); // Print details.System.out.println("name: " + name); System.out.println("amount: " + getOutstanding());

}

• Solución: Mueva este código a un nuevo método (o función)

separado y reemplace el código anterior con una llamada al

método.

void printOwing() { printBanner(); printDetails(getOutstanding());

} void printDetails(double outstanding) {

System.out.println("name: " + name); System.out.println("amount: " + outstanding);

}

inverso de Inline Method



1) Extract Method• ¿Por qué Refactorizar de esta forma?

– Cuantas más líneas se encuentren en un método, más difícilserá averiguar qué hace el método. Esta es la razón principal deesta refactorización.

– Además de eliminar las asperezas en su código, la extracciónde métodos también es un paso en muchos otros enfoques derefactorización.

• Beneficios– ¡Código más legible! Asegúrese de darle al nuevo método un

nombre que describa el propósito del método: createOrder (),renderCustomerInfo (), etc.

– Menos duplicación de código. A menudo, el código que seencuentra en un método se puede reutilizar en otros lugares desu programa. Por lo tanto, puede reemplazar los duplicados conllamadas a su nuevo método.

– Aísla partes independientes del código, lo que significa que loserrores son menos probables (por ejemplo, si se modifica lavariable incorrecta).



1) Extract Method• ¿Cómo Refactorizar de esta forma?

– Cree un nuevo método y nómbrelo de una manera que haga evidentesu propósito.

– Copie el fragmento de código relevante a su nuevo método. Elimine elfragmento de su ubicación anterior y coloque una llamada para elnuevo método allí.

– Encuentre todas las variables utilizadas en este fragmento de código. Sise declaran dentro del fragmento y no se usan fuera de él, simplementedéjelos sin cambios; se convertirán en variables locales para el nuevométodo.

– Si las variables se declaran antes del código que está extrayendo,deberá pasar estas variables a los parámetros de su nuevo métodopara poder usar los valores previamente contenidos en ellos. A veceses más fácil deshacerse de estas variables recurriendo a ReplaceTemp with Query.

– Si ve que una variable local cambia en su código extraído de algunamanera, esto puede significar que este valor cambiado será necesariomás adelante en su método principal. ¡Doble verificación! Y si este esrealmente el caso, devuelva el valor de esta variable al método principalpara mantener todo funcionando.



2) Inline Method

• Problema: Cuando el cuerpo de un método es más obvio que elmétodo en sí, utilice esta técnica

• Solución: Reemplace las llamadas al método con el contenido del

método y elimine el método en sí.

class PizzaDelivery { // ...int getRating() {

return moreThanFiveLateDeliveries() ? 2 : 1; } boolean moreThanFiveLateDeliveries() {

return numberOfLateDeliveries > 5; }

}

class PizzaDelivery { // ...int getRating() {

return numberOfLateDeliveries > 5 ? 2 : 1; }

}

inverso de Extract Method



2) Inline Method• ¿Por qué Refactorizar de esta forma?

– Un método simplemente delega a otro método. En sí misma, estadelegación no es un problema. Pero cuando existen muchos deestos métodos, se convierten en un enredo confuso que es difícilde resolver.

– A menudo, los métodos no son originalmente demasiado cortos,pero se vuelven así a medida que se realizan cambios en elprograma. Así que no dude en deshacerse de los métodos que hansobrevivido a su uso.

• Beneficios– Al minimizar el número de métodos innecesarios, el código llega a

ser más sencillo.

• ¿Cómo Refactorizar de esta forma?– Asegúrese de que el método no se redefina en subclases. Si se

redefine el método, absténgase de esta técnica.

– Encuentre todas las llamadas al método. Reemplace estasllamadas con el contenido del método.

– Elimine el método.



3) Extract Variable• Problema: Tienes una expresión que es difícil de entender.

• Solución: Coloque el resultado de la expresión o sus partes en

variables independientes que se expliquen por sí mismas.

void renderBanner() { if ((platform.toUpperCase().indexOf("MAC") > -1) &&

(browser.toUpperCase().indexOf("IE") > -1) && wasInitialized() && resize > 0 )

{// do something

} }

void renderBanner() { final boolean isMacOs = platform.toUpperCase().indexOf("MAC") > -1; final boolean isIE = browser.toUpperCase().indexOf("IE") > -1; final boolean wasResized = resize > 0;

if (isMacOs && isIE && wasInitialized() && wasResized) { // do something

} }

inverso de Inline Temp (variable)



3) Extract Variable• ¿Por qué Refactorizar de esta forma?

– La principal razón para extraer variables es hacer máscomprensible una expresión compleja, dividiéndola en sus partesintermedias. Estos pueden ser:

• Condición del operador if() o una parte del operador ?: en lenguajes basados enC

• Una expresión aritmética larga sin resultados intermedios

• Líneas largas de varias partes

– Extraer una variable puede ser el primer paso para realizar elExtract Method si ve que la expresión extraída se usa en otroslugares de su código.

• Beneficios– ¡Código más legible! Intente dar a las variables extraídas buenos

nombres que anuncien el propósito de la variable alto y claro. Máslegibilidad, menos comentarios prolijos. Busque nombres comocustomerTaxValue, cityUnemploymentRate, clientSalutationString,etc.



3) Extract Variable• Inconvenientes

– Hay más variables presentes en su código. Pero esto se ve

contrarrestado por la facilidad de lectura de su código.

– Al refactorizar expresiones condicionales, recuerde que lo más

probable es que el compilador lo optimice para minimizar la

cantidad de cálculos necesarios para establecer el valor

resultante. Digamos que tiene una expresión siguiente if (a () || b

())... El programa no llamará al método b si el método a devuelve

true porque el valor resultante seguirá siendo true, sin importar

qué valor devuelva b.

– Sin embargo, si extrae partes de esta expresión en variables,

siempre se llamarán a ambos métodos, lo que podría afectar el

rendimiento del programa, especialmente si estos métodos

hacen un trabajo pesado.



3) Extract Variable

• ¿Cómo Refactorizar de esta forma?

– Inserte una nueva línea antes de la expresión relevante y

declare una nueva variable allí. Asigne parte de la expresión

compleja a esta variable.

– Reemplace esa parte de la expresión con la nueva variable.

– Repita el proceso para todas las partes complejas de la

expresión.



4) Inline Temp(Inline variable)

• Problema: Tiene una variable temporal a la que se le asigna elresultado de una expresión simple y nada más.

• Solución: Reemplace las referencias a la variable con la expresión

en sí.

boolean hasDiscount(Order order) { double basePrice = order.basePrice(); return basePrice > 1000;

}

boolean hasDiscount(Order order) { return order.basePrice() > 1000;

}

• ¿Por qué Refactorizar de esta forma?

– Las variables locales en línea casi siempre se usan como parte de

Replace Temp with Query o para allanar el camino para el Extract

Method.

inverso de Extract variable



4) Inline Temp

• Beneficios:– Esta técnica de refactorización no ofrece casi ningún beneficio

en sí misma. Sin embargo, si a la variable se le asigna elresultado de un método, puede mejorar marginalmente lalegibilidad del programa al deshacerse de la variableinnecesaria.

• Inconvenientes– A veces, se utilizan temperaturas aparentemente inútiles para

almacenar en caché el resultado de una operación costosa quese reutiliza varias veces. Por lo tanto, antes de utilizar estatécnica de refactorización, asegúrese de que la simplicidad nose produzca a costa del rendimiento.

• ¿Cómo Refactorizar de esta forma?– Encuentra todos los lugares que usan la variable. En lugar de la

variable, utilice la expresión que se le asignó.

– Elimina la declaración de la variable y su línea de asignación.



5) Replace Temp with Query• Problema: Coloca el resultado de una expresión en una

variable local para su uso posterior en su código.

• Solución: Mueva toda la expresión a un método separado y devuelva

el resultado de ella. Consulta el método en lugar de utilizar una

variable. Incorpore el nuevo método en otros métodos, si es necesario.

double calculateTotal() { double basePrice = quantity * itemPrice; if (basePrice > 1000) {

return basePrice * 0.95; } else { return basePrice * 0.98; }

}

double calculateTotal() { if (basePrice() > 1000) { return basePrice() * 0.95; } else { return basePrice() * 0.98; }

}

double basePrice() { return quantity * itemPrice; }



5) Replace Temp with Query• ¿Por qué Refactorizar de esta forma?

– Esta refactorización puede sentar las bases para aplicar el

Extract Method para una parte de un método muy largo.

– La misma expresión a veces también se puede encontrar en

otros métodos, lo cual es una razón para considerar la creación

de un método común.

• Beneficios

– Legibilidad del código. Es mucho más fácil comprender el

propósito del método getTax () que la línea orderPrice () * 0.2.

– Código más delgado mediante deduplicación (eliminar copias

duplicadas), si la línea que se reemplaza se usa en varios

métodos.



5) Replace Temp with Query• Bueno saber

– Rendimiento: Esta refactorización puede generar la pregunta

de si este enfoque puede causar un impacto en el rendimiento.

– La respuesta honesta es: sí, lo es, ya que el código resultante

puede verse sobrecargado al consultar un nuevo método. Pero

con las CPU rápidas de hoy y los excelentes compiladores, la

carga casi siempre será mínima. Por el contrario, el código

legible y la capacidad de reutilizar este método en otros lugares

del código del programa, gracias a este enfoque de

refactorización, son beneficios muy notables.

– No obstante, si su variable temporal se usa para almacenar en

caché el resultado de una expresión que realmente consume

mucho tiempo, es posible que desee detener esta

refactorización después de extraer la expresión a un nuevo

método.



5) Replace Temp with Query


– Asegúrese de que se asigne un valor a la variable una vez y

solo una vez dentro del método. De lo contrario, use Split

Temporary Variable para asegurarse de que la variable se usará

solo para almacenar el resultado de su expresión.

– Utilice Extract Method para colocar la expresión de interés en un

nuevo método. Asegúrese de que este método solo devuelva un

valor y no cambie el estado del objeto. Si el método afecta el

estado visible del objeto, utilice Separate Query from Modifier.

– Reemplace la variable con una consulta a su nuevo método.



6) Split Temporary Variable

• Problema: Tiene una variable local que se usa para almacenar varios

valores intermedios dentro de un método (excepto las variables de

ciclo-loop variables).

• Solución: Utilice diferentes variables para diferentes valores. Cada

variable debe ser responsable de una sola cosa en particular.

double temp = 2 * (height + width); System.out.println(temp); temp = height * width; System.out.println(temp);

final double perimeter = 2 * (height + width); System.out.println(perimeter); final double area = height * width; System.out.println(area);

inverso de Inline Temp



6) Split Temporary Variable• ¿Por qué Refactorizar de esta forma?

– Si escatima en la cantidad de variables dentro de una función y lasreutiliza para varios propósitos no relacionados, seguramenteencontrará problemas tan pronto como necesite realizar cambios en elcódigo que contiene las variables. Tendrá que volver a comprobar cadacaso de uso de variables para asegurarse de que se utilizan los valorescorrectos.

• Beneficios– Cada componente del código del programa debe ser responsable de

una sola cosa. Esto hace que sea mucho más fácil mantener el código,ya que puede reemplazar fácilmente cualquier cosa en particular sintemor a efectos no deseados.

– El código se vuelve más legible. Si una variable se creó hace muchotiempo con prisa, probablemente tenga un nombre que no expliquenada: k, a2, value, etc. Pero puede solucionar esta situaciónnombrando las nuevas variables de una manera comprensible yautoexplicativa. . Dichos nombres pueden parecerse acustomerTaxValue, cityUnemploymentRate, clientSalutationString ysimilares.

– Esta técnica de refactorización es útil si prevé utilizar Extract Methodmás adelante.



6) Split Temporary Variable


– Encuentre el primer lugar en el código donde se le da un valor a

la variable. Aquí debe cambiar el nombre de la variable con un

nombre que corresponda al valor que se está asignando.

– Use el nuevo nombre en lugar del anterior en los lugares donde

se usa este valor de la variable.

– Repita según sea necesario para los lugares donde a la variable

se le asigna un valor diferente.



7) Remove Assignments to Parameters

• Problema: Se asigna algún valor a un parámetro dentro del cuerpo del

método.

• Solución: Utilice una variable local en lugar de un parámetro.

int discount(int inputVal, int quantity) { if (quantity > 50) {

inputVal -= 2; } // ...

}

int discount(int inputVal, int quantity) { int result = inputVal; if (quantity > 50) {

result -= 2; } // ...

}

Similar a Split Temporary Variable



7) Remove Assignments to Parameters• ¿Por qué Refactorizar de esta forma?

– Las razones de esta refactorización son las mismas que paraSplit Temporary Variable, pero en este caso estamos tratandocon un parámetro, no con una variable local.

– Primero, si se pasa un parámetro a través de una referencia,luego, después de que se cambia el valor del parámetro dentrodel método, este valor se pasa al argumento que solicitó llamara este método. Muy a menudo, esto ocurre accidentalmente yconduce a efectos desafortunados. Incluso si los parámetrosgeneralmente se pasan por valor (y no por referencia) en sulenguaje de programación, esta peculiaridad de codificaciónpuede alienar a aquellos que no están acostumbrados a ella.

– En segundo lugar, las asignaciones múltiples de valoresdiferentes a un solo parámetro le dificultan saber qué datosdeben estar contenidos en el parámetro en un momentodeterminado. El problema empeora si su parámetro y sucontenido están documentados, pero el valor real puede diferirde lo que se espera dentro del método.



7) Remove Assignments to Parameters

• Beneficios

– Cada elemento del programa debe ser responsablede una sola cosa. Esto hace que el mantenimientodel código sea mucho más fácil en el futuro, ya quepuede reemplazar el código de forma segura sinefectos secundarios.

– Esta refactorización ayuda a extraer código repetitivoen métodos separados (Extract method).


– Cree una variable local y asigne el valor inicial de suparámetro.

– En todo el código de método que sigue a esta línea,reemplace el parámetro con su nueva variable local.



8) Replace Method with Method Object

Problema: Tiene un método largo

en el que las variables locales

están tan entrelazadas que no

puede aplicar Extract Method.

Solución: Transforme el método en una clase

separada para que las variables locales se conviertan

en campos de la clase. Luego, puede dividir el método

en varios métodos dentro de la misma clase.

class Order { // ...public double price() { double primaryBasePrice; double secondaryBasePrice; double tertiaryBasePrice; // Perform long computation.

} }

class Order { // ...public double price() { return new PriceCalculator(this).compute();

} } class PriceCalculator { private double primaryBasePrice; private double secondaryBasePrice; private double tertiaryBasePrice; public PriceCalculator(Order order) { // Copy relevant information from the// order object.

} public double compute() { // Perform long computation.

} }



8) Replace Method with Method Object• ¿Por qué Refactorizar de esta forma?

– Un método es demasiado largo y no se puede separar debido amasas enredadas de variables locales que son difíciles de aislarunas de otras.

– El primer paso es aislar todo el método en una clase separada yconvertir sus variables locales en campos de la clase.

– En primer lugar, esto permite aislar el problema a nivel de clase.En segundo lugar, allana el camino para dividir un métodogrande y difícil de manejar en otros más pequeños que de todosmodos no encajarían con el propósito de la clase original.

• Beneficios– Aislar un método largo en su propia clase permite evitar que un

método aumente de tamaño. Esto también permite dividirlo ensubmétodos dentro de la clase, sin contaminar la clase originalcon métodos de utilidad.

• Inconvenientes– Se agrega otra clase, aumentando la complejidad general del

programa.



8) Replace Method with Method Object

• ¿Cómo Refactorizar de esta forma?– Crea una nueva clase. Nómbrelo según el propósito del método

que está refactorizando.

– En la nueva clase, cree un campo privado para almacenar una referencia a una instancia de la clase en la que se ubicó previamente el método. Podría usarse para obtener algunos datos requeridos de la clase original si es necesario.

– Cree un campo privado separado para cada variable local del método.

– Cree un constructor que acepte como parámetros los valores de todas las variables locales del método y también inicialice los campos privados correspondientes.

– Declare el método principal y copie el código del método original en él, reemplazando las variables locales con campos privados.

– Reemplaza el cuerpo del método original en la clase original creando un objeto de método y llamando a su método principal.



9) Substitute Algorithm

• Problema: ¿desea

reemplazar un algoritmo

existente por uno nuevo?

• Solución: Reemplace el

cuerpo del método que

implementa el algoritmo con

un nuevo algoritmo.

String foundPerson(String[] people){ for (int i = 0; i < people.length; i++) {

if (people[i].equals("Don")){ return "Don"; }

if (people[i].equals("John")){ return "John"; }

if (people[i].equals("Kent")){ return "Kent"; }

} return ""; }

String foundPerson(String[] people){ List candidates =

Arrays.asList(new String[] {"Don", "John", "Kent"});

for (int i=0; i < people.length; i++){ if (candidates.contains(people[i])){

return people[i]; }

}return "";

}



9) Substitute Algorithm

• ¿Por qué Refactorizar de esta forma?– La refactorización gradual no es el único método para

mejorar un programa.• A veces, un método está tan abarrotado de problemas que

es más fácil deshacerse del método y empezar de nuevo. Yquizás haya encontrado un algoritmo que sea mucho mássimple y eficiente.

• Si este es el caso, simplemente debe reemplazar elalgoritmo antiguo por el nuevo.

– A medida que pasa el tiempo, su algoritmo puedeincorporarse a una biblioteca o marco bien conocidoy desea deshacerse de su implementaciónindependiente para simplificar el mantenimiento.

– Los requisitos de su programa pueden cambiar tantoque su algoritmo existente no se puede salvar para latarea.



9) Substitute Algorithm• ¿Cómo Refactorizar de esta forma?

– Asegúrese de haber simplificado el algoritmo existentetanto como sea posible. Mueva el código sin importancia aotros métodos usando Extract Method. Cuantas menospartes móviles haya en su algoritmo, más fácil seráreemplazarlo.

– Cree su nuevo algoritmo en un nuevo método. Reemplaceel algoritmo antiguo por el nuevo y comience a probar elprograma.

– Si los resultados no coinciden, vuelva a la implementaciónanterior y compare los resultados. Identifique las causasde la discrepancia. Si bien la causa suele ser un error enel algoritmo anterior, es más probable que se deba a quealgo no funciona en el nuevo.

– Cuando todas las pruebas se completen con éxito,¡elimine el antiguo algoritmo para siempre!






• Organizing Data






Moving Features between Objects(Mover características entre objetos)

• Estas técnicas derefactorización muestrancómo mover de formasegura la funcionalidadentre clases, crearnuevas clases y ocultarlos detalles deimplementación delacceso público.

• Incluso si ha distribuidola funcionalidad entrediferentes clases de unamanera menos queperfecta, todavía hayesperanza.



1) Move Method

• Problema– Un método se usa más en otra clase que en su propia clase.

• Solución– Cree un nuevo método en la clase que más usa el método,

luego mueva el código del método anterior allí.

– Convierta el código del método original en una referencia alnuevo método en la otra clase o elimínelo por completo.

• ¿Por qué Refactorizar de esta forma?– Mover un método a una clase que contiene la mayoría de los

datos utilizados por el método hace que las clases sean máscoherentes internamente.

– El mover un método para reducir o eliminar la dependencia de laclase que llama al método en la clase en la que se encuentrapuede ser útil si la clase que llama ya depende de la clase a laque planea mover el método. Esto reduce la dependenciaentre clases.



1) Move Method

• Si un método en una clase usa (o es usado por) otra clase más que

la clase en la que está definido, muévalo a la otra clase

public class Student

{

public boolean isTaking(Course course)

{

return (course.getStudents().contains(this));

}

}

public class Course

{

private List students;

public List getStudents()

{

return students;

}

}



1) Move Method• La clase del estudiante ya no necesita conocer la interfaz del curso,

y el método isTaking() está más cerca de los datos en los que

se basa, lo que hace que el diseño del curso sea más cohesivo y el

diseño general se acople de manera más flexible.


{

}

public class Course

{


public boolean isTaking(Student student)

{

return students.contains(student);

}

}

Refactored



1) Move Method

• ¿Cómo Refactorizar de esta forma?– Verifique todas las características utilizadas por el método

anterior en su clase. También puede ser una buena ideamoverlos. Como regla general, si una característica es utilizadasolo por el método en consideración, ciertamente debe mover lacaracterística a él. Si la función también es utilizada por otrosmétodos, también debe mover estos métodos. A veces esmucho más fácil mover una gran cantidad de métodos queestablecer relaciones entre ellos en diferentes clases.

• Asegúrese de que el método no esté declarado en superclases ysubclases. Si este es el caso, tendrá que abstenerse de moverse oimplementar una especie de polimorfismo en la clase receptora paragarantizar la funcionalidad variable de un método dividido entre lasclases donantes.

– Declare el nuevo método en la clase receptora. Es posible quedesee dar un nuevo nombre al método que sea más apropiadopara él en la nueva clase.



1) Move Method

– Decida cómo se referirá a la clase destinataria. Es posible que ya tenga

un campo o método que devuelva un objeto apropiado, pero si no es

así, deberá escribir un nuevo método o campo para almacenar el objeto

de la clase destinataria.

– Ahora tiene una forma de hacer referencia al objeto destinatario y un

nuevo método en su clase. Con todo esto en su haber, puede convertir

el método antiguo en una referencia al nuevo método.

– Eche un vistazo: ¿puede eliminar el método anterior por completo? Si

es así, coloque una referencia al nuevo método en todos los lugares

que usan el antiguo.



2) Move Field

• Problema: Un campo se usa más en

otra clase que en su propia clase.

class Customer { // ...get plan() {return this._plan;

} get discountRate() {return this._discountRate;

}}


– A menudo, los campos se mueven como parte de la técnica Extract Class.

Decidir en qué clase dejar el campo puede ser difícil. Aquí está nuestra regla

de oro: coloque un campo en el mismo lugar que los métodos que lo usan

(o donde están la mayoría de estos métodos).

– Esta regla ayudará en otros casos cuando un campo simplemente está

ubicado en el lugar equivocado.

• Solución: Cree un campo en una

nueva clase y redirija a todos los

usuarios del campo anterior a él.

class Customer { // ...get plan() {

return this._plan;} get discountRate() {

return this._plan.discountRate;}

}

Preceder las variables de una clase con underscore (guión bajo) permite diferenciar los atributos de una clase con los que se reciben como parámetros



2) Move Field

• ¿Cómo Refactorizar de esta forma?– Si el campo es público, la refactorización será mucho más

fácil si lo hace privado y proporciona métodos de accesopúblicos (para esto, puede usar Encapsulate Field).

– Cree el mismo campo con métodos de acceso en la clasede destinatario.

– Decida cómo se referirá a la clase destinataria. Es posibleque ya tenga un campo o método que devuelva el objetoapropiado; si no es así, deberá escribir un nuevo método ocampo para almacenar el objeto de la clase destinataria.

– Reemplace todas las referencias al campo anterior conllamadas apropiadas a métodos en la clase dedestinatario. Si el campo no es privado, ocúpese de estoen la superclase y subclases.

– Elimina el campo de la clase original.



3) Extract Class

• Problema: Cuando una

clase hace el trabajo de

dos, resulta incómodo.

• Solución: En su lugar, cree una

nueva clase y coloque los campos

y métodos responsables de la

funcionalidad relevante en ella.

class Soldier { public int health; public int damage; public int weaponStatus; public int getDamage() {

// ...} public void attack() {

// ...}

}

class Soldier { public int health; public Weapon weapon; public void attack() {

// ...}

}

class Weapon { public int damage; public int weaponStatus; public int getDamage() {

// ...}

}



3) Extract Class• ¿Por qué Refactorizar de esta forma?

– Las clases siempre comienzan de forma clara y fácil de entender.Hacen su trabajo y se ocupan de sus propios asuntos, por asídecirlo, sin meterse en el trabajo de otras clases. Pero a medidaque el programa se expande, se agrega un método y luego uncampo ... y, finalmente, algunas clases están desempeñando másresponsabilidades de las que se habían imaginado.

• Beneficios– Este método de refactorización ayudará a mantener la adherencia

al principio de responsabilidad única (principios SOLID). El códigode tus clases será más obvio y comprensible.

– Las clases de responsabilidad única son más fiables y tolerantes alos cambios. Por ejemplo, digamos que tienes una claseresponsable de diez cosas diferentes. Cuando cambia esta clasepara mejorarla para una cosa, corre el riesgo de romperla para lasotras nueve.

• Inconvenientes– Si te excedes con esta técnica de refactorización, tendrás que

recurrir a Inline Class.



3) Extract Class

• ¿Cómo Refactorizar de esta forma?– Antes de comenzar, decida exactamente cómo quiere dividir las

responsabilidades de la clase.

– Cree una nueva clase para contener la funcionalidad relevante.

– Cree una relación entre la clase anterior y la nueva. De maneraóptima, esta relación es unidireccional; esto permite reutilizar lasegunda clase sin problemas. No obstante, si cree que esnecesaria una relación bidireccional, esta siempre se puedeestablecer.

– Utilice Move Field y Move Method para cada campo y métodoque haya decidido mover a la nueva clase. Para los métodos,comience con los privados para reducir el riesgo de cometer unagran cantidad de errores. Trate de reubicarse poco a poco ypruebe los resultados después de cada movimiento, para evitaruna acumulación de errores al final.



3) Extract Class

• ¿Cómo Refactorizar de esta forma?– Una vez que haya terminado de extraer la clase y los métodos,

eche un vistazo más a las clases resultantes. Se puede cambiarel nombre de una clase antigua con responsabilidadescambiadas para mayor claridad. Verifique nuevamente para versi puede deshacerse de las relaciones de clase bidireccionales,si las hay.

– También piense en la accesibilidad a la nueva clase desde elexterior. Puede ocultar la clase al cliente por completohaciéndola privada, administrándola a través de los campos dela clase anterior. Alternativamente, puede hacerlo públicopermitiendo que el cliente cambie los valores directamente. Sudecisión aquí depende de qué tan seguro sea para elcomportamiento de la clase anterior cuando se realizan cambiosdirectos inesperados en los valores de la nueva clase.



4) Inline Class

• Problema: Una clase no hace casi nada y no es responsable de nada, y

no se planean responsabilidades adicionales para ella.

• Solución: Mueva todas las funciones de la clase a otra.

class Person { get officeAreaCode() {return this._telephoneNumber.areaCode;} get officeNumber() {return this._telephoneNumber.number;}

} class TelephoneNumber { get areaCode() {return this._areaCode;} get number() {return this._number;}

}

class Person { get officeAreaCode() {return this._officeAreaCode;} get officeNumber() {return this._officeNumber;}

}

inverso de Extract Class



4) Inline Class


– En la clase de destinatario, cree los campos públicos y los métodos presentesen la clase de donante. Los métodos deben referirse a los métodos equivalentesde la clase de donantes.

– Reemplace todas las referencias a la clase donante con referencias a loscampos y métodos de la clase receptora.

– Ahora pruebe el programa y asegúrese de que no se hayan agregado errores. Silas pruebas muestran que todo está funcionando correctamente, comience ausar Move Method y Move Field para trasplantar completamente todas lasfunciones a la clase receptora desde la original. Continúe haciéndolo hasta quela clase original esté completamente vacía.

– Elimine la clase original.


– A menudo, esta técnica es necesaria después de que las características de una

clase se “trasplanten” a otras clases, dejando a esa clase con poco que hacer.

• Beneficios

– La eliminación de clases innecesarias libera memoria operativa en la

computadora y ancho de banda en su cabeza XD



5) Hide Delegate• Problema

– El cliente obtiene el objeto B de un campo o método del objeto А.

Luego, el cliente llama a un método del objeto B.


– Para empezar, veamos la terminología:

• Servidor: es el objeto al que el cliente tiene acceso directo.

• Delegado: es el objeto final que contiene la funcionalidad requerida por el cliente.

– Aparece una cadena de llamadas cuando un cliente solicita un objeto de otro objeto,

luego el segundo objeto solicita otro, y así sucesivamente. Estas secuencias de

llamadas involucran al cliente en la navegación a lo largo de la estructura de clases.

Cualquier cambio en estas interrelaciones requerirá cambios por parte del cliente.

• Solución

– Cree un nuevo método en la clase A que delegue la llamada al objeto B. Ahora

el cliente no conoce ni depende de la clase B

manager = aPerson.department().manager();

manager = aPerson.manager(); class Person {

get manager() {return this.department.manager();}}

inverso de Remove Middle Man



5) Hide Delegate

• Beneficios– Oculta la delegación del cliente. Cuanto menos necesite saber el código

del cliente sobre los detalles de las relaciones entre los objetos, másfácil será realizar cambios en su programa.

• Inconvenientes– Si necesita crear una cantidad excesiva de métodos de delegación, la

clase de servidor corre el riesgo de convertirse en un intermediarioinnecesario, lo que lleva a un exceso de Middle Man.

• ¿Cómo Refactorizar de esta forma?– Para cada método de la clase de delegado llamado por el cliente, cree

un método en la clase servidor que delegue la llamada a la clasedelegada.

– Cambie el código del cliente para que llame a los métodos de la claseservidor.

– Si sus cambios liberan al cliente de la necesidad de la clase delegada,puede eliminar el método de acceso a la clase delegada de la claseservidor (el método que se usó originalmente para obtener la clasedelegada).



6) Remove Middle Man


– Para empezar, veamos la terminología:

• Servidor: es el objeto al que el cliente tiene acceso directo.

• Delegado: es el objeto final que contiene la funcionalidad requerida por el cliente.

– Hay dos tipos de problemas:

• La clase servidor no hace nada por sí misma y simplemente crea una complejidad

innecesaria. En este caso, piense si esta clase es necesaria.

• Cada vez que se agrega una nueva característica a la clase delegada, debe crear

un método de delegación para ella en la clase servidor. Si se realizan muchos

cambios, esto será bastante tedioso.

• Problema

– Una clase tiene demasiados métodos que simplemente delegan en

otros objetos.

• Solución

– Elimine estos métodos y obligue al cliente a llamar directamente a los métodos

finales.

inverso de Hide Delegate

manager = aPerson.manager(); class Person {

get manager() {return this.department.manager();}}

manager = aPerson.department().manager();



6) Remove Middle Man


– Cree un get para acceder al objeto de clase delegada desde el

objeto de clase servidor.

– Reemplace las llamadas para delegar métodos en la clase

servidor con llamadas directas a los métodos de la clase

delegada.



7) Introduce Foreign Method• Problema: Una Utility Class no

contiene el método que necesita

y no puede agregar el método a

la clase.

• Solución: Agregue el método a una

clase cliente y pásele un objeto de la

Utility Class como argumento.

class Report { // ...void sendReport() {

Date nextDay = new Date(previousEnd.getYear(), previousEnd.getMonth(), previousEnd.getDate() + 1);

// ...}

}

class Report { // ...void sendReport() {

Date newStart = nextDay(previousEnd);// ...

} private static Date nextDay(Date arg) {

return new Date(arg.getYear(), arg.getMonth(), arg.getDate() + 1);

}}

Las Utility Class son estructuras que contienen métodos auxiliares reutilizables y sin

estado. Implementamos estos métodos para manejar cualquier tipo de operaciones

específicas para propósitos específicos. Debido a su naturaleza apátrida, en su

mayoría preferimos definirlos como estáticos. Ej: java.lang.Math



7) Introduce Foreign Method• ¿Por qué Refactorizar de esta forma?

– Tienes un código que usa los datos y métodos de unadeterminada clase. Te das cuenta de que el código severá y funcionará mucho mejor dentro de un nuevométodo en la clase. Pero no puede agregar el método a laclase porque, por ejemplo, la clase está ubicada en unabiblioteca de terceros.

– Esta refactorización tiene una gran recompensa cuando elcódigo que desea mover al método se repite varias vecesen diferentes lugares de su programa.

– Dado que está pasando un objeto de la Utility Class a losparámetros del nuevo método, tiene acceso a todos suscampos. Dentro del método, puedes hacer prácticamentetodo lo que quieras, como si el método fuera parte de laUtility Class.

Mas info sobre Utility class:

https://yavuztas.dev/java/collections/streams/2019/08/10/java8-utility-class.html



7) Introduce Foreign Method

• Beneficios:– Elimina la duplicación de código. Si su código se repite en

varios lugares, puede reemplazar estos fragmentos decódigo con una llamada al método. Esto es mejor que laduplicación incluso considerando que el método externoestá ubicado en un lugar subóptimo.

• Inconvenientes:– Las razones para tener el método de una clase de utilidad

en una clase de cliente no siempre serán claras para lapersona que mantiene el código después de usted. Si elmétodo se puede usar en otras clases, podría beneficiarsecreando un contenedor para la clase de utilidad ycolocando el método allí. Esto también es beneficiosocuando existen varios métodos de utilidad. Introduce LocalExtension puede ayudar con esto.



7) Introduce Foreign Method

• ¿Cómo Refactorizar de esta forma?– Cree un nuevo método en la clase cliente.

– En este método, cree un parámetro al que se le pasará elobjeto de la Utility Class. Si este objeto se puede obtenerde la clase cliente, no es necesario que cree dichoparámetro.

– Extraiga los fragmentos de código relevantes para estemétodo y reemplácelos con llamadas al método.

– Asegúrese de dejar la etiqueta del Foreign method en loscomentarios del método junto con el consejo de colocareste método en una Utility Class si es posible másadelante. Esto facilitará la comprensión de por qué estemétodo se encuentra en esta clase en particular paraaquellos que mantendrán el software en el futuro.



8) Introduce Local Extension

Problema: Una Utility Class

no contiene algunos de los

métodos que necesita. Pero

no puede agregar estos

métodos a la clase.

Solución: Cree una nueva clase que contenga los

métodos y conviértala en hijo o contenedor (wrapper) de

la Utility Class .

import java.util.Date;

public class Main {private Date date;public static void main(final String[] arguments) {

// ...}

}

import java.util.Date;

public class NewDate extends Date {

public NewDate() {

super();

}

public NewDate(long date) {

super(date);

}

public NewDate(int year, int month, int date) {

super(year, month, date);

}

public NewDate(int year, int month,

int date, int hrs, int min) {

super(year, month, date, hrs, min);

}

public NewDate(int year, int month, int date,

int hrs, int min, int sec) {

super(year, month, date, hrs, min, sec);

}

public NewDate(String s) { super(s); } }



8) Introduce Local Extension

• ¿Por qué Refactorizar de esta forma? La clase que estásusando no tiene los métodos que necesitas. Lo que es peor, nopuede agregar estos métodos (porque las clases están en unabiblioteca de terceros, por ejemplo). Hay dos salidas:

– Cree una subclass de la clase relevante, que contenga losmétodos y herede todo lo demás de la clase principal. De estamanera es más fácil, pero a veces está bloqueado por la propiaUtility Class (debido a final).

– Cree una wrapper (clase contenedora) que contenga todos losmétodos nuevos y en cualquier otro lugar se delegará en elobjeto relacionado de la clase de utilidad. Este método es mástrabajo ya que no solo necesita código para mantener la relaciónentre el contenedor y el objeto de una Utility Class, sino tambiénuna gran cantidad de métodos de delegación simples paraemular la interfaz pública de la Utility Class.



8) Introduce Local Extension• Beneficios:

– Al mover métodos adicionales a una clase de extensión separada(wrapper o subclass), evita engordar las clases cliente con códigoque no encaja. Los componentes del programa son máscoherentes y más reutilizables.

• ¿Cómo Refactorizar de esta forma?– Cree una nueva clase de extensión:

• Opción A: convertirlo en un elemento secundario de la Utility Class.

• Opción B: Si ha decidido crear un contenedor, cree un campo en élpara almacenar el objeto de Utility Class al que se hará la delegación.Cuando utilice esta opción, también deberá crear métodos que repitanlos métodos públicos de la Utility Class y que contengan unadelegación simple a los métodos del objeto de Utility Class.

– Cree un constructor que use los parámetros del constructor de laUtility Class.

– También cree un constructor de "conversión" alternativo que tomesolo el objeto de la clase original en sus parámetros. Esto ayudaráa sustituir la extensión por los objetos de la clase original.

– Crea nuevos métodos extendidos en la clase. Mueva foreignmethods de otras clases a esta clase o elimine los foreign methodssi su funcionalidad ya está presente en la extensión.






• Organizing Data






Organizing Data

• Estas técnicas derefactorización ayudan conel manejo de datos,reemplazando las variablesprimitivas con una ricafuncionalidad de clase.

• Otro resultado importantees desenredar lasasociaciones de clases, loque hace que las clasessean más portátiles yreutilizables.

Modulo

A

Modulo

D

Modulo

B

Modulo

C

Area de Data Compartida

Alto Acoplamiento



1) Self Encapsulate Field• Problema: Utiliza el acceso

directo a los campos

privados dentro de una

clase.

• Solución: Cree un get y un set

para el campo y utilícelos solo para

acceder al campo.

Esta refactorizaciónes distinta del Encapsulate Field ordinario: la técnica de

refactorización dada aquí se realiza en un campo privado.

class Range { private int low, high; boolean includes(int arg) { return arg >= low && arg <= high;

} }

class Range { private int low, high; boolean includes(int arg) { return arg >= getLow() && arg <= getHigh();

} int getLow() {

return low; } int getHigh() {

return high; }

}



1) Self Encapsulate Field• ¿Por qué Refactorizar de esta forma?

– A veces, acceder directamente a un campo privado dentro de una claseno es lo suficientemente flexible. Desea poder iniciar un valor de campocuando se realiza la primera consulta o realizar ciertas operaciones ennuevos valores del campo cuando se asignan, o tal vez hacer todo estode varias maneras en subclases.

• Beneficios– El acceso indirecto a los campos es cuando se actúa sobre un campo a

través de métodos de acceso (get y set). Este enfoque es mucho másflexible que el acceso directo a los campos.

• Primero, puede realizar operaciones complejas cuando los datos en elcampo están configurados (set) o recibidos (get). La inicialización perezosay la validación de los valores de campo se implementan fácilmente dentrode los métodos get y set de los campos.

• En segundo lugar, y lo que es más importante, puede redefinir métodos gety set en las subclases.

– Tiene la opción de no implementar un método set para un campo enabsoluto. El valor del campo se especificará solo en el constructor, porlo que el campo no se puede cambiar durante toda la vida útil delobjeto.



1) Self Encapsulate Field• Inconvenientes

– Cuando se usa el acceso directo a los campos, el código parece

más simple y presentable, aunque la flexibilidad se ve

disminuida.


– Cree un get (y un set opcional) para el campo. Deben estar

protegidos o ser públicos.

– Encuentre todas las invocaciones directas del campo y

reemplácelas con llamadas get y set.

La inicialización perezosa es una optimización del rendimiento en la que

pospones la creación de objetos (potencialmente costosa) hasta justo antes de que

realmente la necesites.

• Un buen ejemplo es no crear una conexión de base de datos por adelantado,

sino solo justo antes de que necesite obtener datos de la base de datos.

• La razón clave para hacer esto es que (a menudo) se puede evitar crear el

objeto por completo si nunca lo necesita.



2) Replace Data Value with Object

• Problema– Una clase (o grupo de clases) contiene un campo de datos. El

campo tiene su propio comportamiento y datos asociados.

• Solución– Cree una nueva clase, coloque el campo antiguo y su

comportamiento en la clase y almacene el objeto de la clase enla clase original.

• ¿Por qué Refactorizar de esta forma?– Esta refactorización es básicamente un caso especial de Extract

Class. Lo que lo hace diferente es la causa de la refactorización.

– En Extract Class, tenemos una sola clase que es responsablede diferentes cosas y queremos dividir sus responsabilidades.

orders.filter(o => "high" === o.priority || "rush" === o.priority);

orders.filter(o => o.priority.higherThan(new Priority("normal")))




– Con el reemplazo de un valor de datos con un objeto, tenemos

un campo primitivo (número, cadena, etc.) que ya no es tan

simple debido al crecimiento del programa y ahora tiene datos y

comportamientos asociados. Por un lado, estos campos no

tienen nada de miedo en sí mismos. Sin embargo, esta familia

de campos y comportamientos puede estar presente en varias

clases simultáneamente, creando código duplicado.

– Por tanto, para todo esto creamos una nueva clase y le

trasladamos tanto el campo como los datos y comportamientos

relacionados.

• Beneficios

– Mejora la relación dentro de las clases. Los datos y los

comportamientos relevantes están dentro de una sola clase.



2) Replace Data Value with Object• Antes de comenzar con la refactorización, vea si hay

referencias directas al campo desde dentro de la clase. Si esasí, use Self Encapsulate Field para ocultarlo en la claseoriginal.

• Crea una nueva clase y copia tu campo y método getrelevante. Además, cree un constructor que acepte el valorsimple del campo. Esta clase no tendrá un establecedor yaque cada nuevo valor de campo que se envía a la claseoriginal creará un nuevo objeto de valor.

• En la clase original, cambie el tipo de campo a la nuevaclase.

• En el método get de la clase original, invoca el get del objetoasociado.

• En el método set, cree un nuevo objeto de valor. Es posibleque también deba crear un nuevo objeto en el constructor silos valores iniciales se habían establecido allí anteriormentepara el campo.




• Próximos pasos– Después de aplicar esta técnica de refactorización,

es aconsejable aplicar Change Value to Reference enel campo que contiene el objeto. Esto permitealmacenar una referencia a un solo objeto quecorresponde a un valor en lugar de almacenardocenas de objetos para un mismo valor.

– La mayoría de las veces, este enfoque es necesariocuando desea que un objeto sea responsable de unobjeto del mundo real (como usuarios, pedidos,documentos, etc.). Al mismo tiempo, este enfoque noserá útil para objetos como fechas, dinero, rangos,etc.



3) Change Value to Reference

• Problema: Se tienen muchas instancias idénticas de una sola clase que tunecesitas reemplazar con un solo objeto.

• Solución: Convierta los objetos idénticos en un solo objeto de referencia.

• ¿Por qué Refactorizar de esta forma?– En muchos sistemas, los objetos se pueden clasificar como valores o

referencias.• Referencias: cuando un objeto del mundo real corresponde a un solo objeto en

el programa. Las referencias suelen ser objetos de la clase usuario / pedido /producto / etc.

• Valores: un objeto del mundo real corresponde a varios objetos en el programa.Estos objetos pueden ser fechas, números de teléfono, direcciones, colores ysimilares.

– La selección de referencia frente a valor no siempre es clara. A veces hay unvalor simple con una pequeña cantidad de datos que no cambian. Entonces esnecesario agregar datos modificables y pasar estos cambios cada vez que seaccede al objeto. En este caso, es necesario convertirlo en una referencia.

Muchos lenguajes de programación permiten pasar parámetros por referencia o por valor.

En Java, solo podemos pasar parámetros por valor.

let customer = new Customer(customerData);

let customer = customerRepository.get(customerData.id);

inverso de Change Reference to Value




• C: Manejo de referencias por punteros

– Los punteros en C constituyen el tema más temido por los estudiantes novatos de este lenguaje.

– Sin embargo, su concepto, como su manipulación son bastante sencillas.

– Son extremadamente útiles para trabajos complejos:• Permiten ahorrar espacio en memoria

• Reservar dinámicamente memoria

• Paso de parámetros por referencia

• Entre otros.

– Saludemos a nuestro nuevo amigo: los punteros




• C: Las Direcciones En Memoria– Al declarar una variable: int a;

• Estamos reservando un espacio en memoria (uno o más bytes)

– Cada byte en memoria tiene una dirección

• La dirección es solo un número entero, único de cada byte.

– Una variable tiene una dirección en memoria.

• Es la dirección del primer byte asignado a la misma

• Es imposible predecir que dirección de memoria va a tener una variable.

• Si es posible, conocer la dirección que ya se ha asignado

– ¿Qué dirección tiene la variable a?

• El operador & antes del nombre de la variable retorna la dirección de memoria de la misma:

printf(“La direccion de la variable a es %d”, &a);

1000

1001

1002

1003

Bytes usados por la variable a. La dirección de a es 1000: &a




• C: ¿Qué son los punteros?– Podemos saber la dirección de una variable ...

– Y.. ¿en que tipo de variable la podemos poner?

• En un tipo de variable especial: un puntero

• Un puntero es una variable que puede almacenar direcciones de memoria de otras variables

– ¿Como declaramos un puntero?

int x;

int *pt;

pt = &x;

• Un puntero se denota por el * antes del nombre.

• pt podrá almacenar la dirección de cualquier entero, es puntero a entero.

• A través de pt podremos acceder a x, pues pt apunta a x.

• char *pt2 es un puntero a char, puede almacenar direcciones de variables tipo char.

1000

1000

10011002

1003

1004

1005

x

ptpt almacena la dirección de x, se dice que pt apunta a x



3) Change Value to Reference• C: Manipulación de Punteros: Operadores Dirección

y Contenido– Estamos ante la presencia de dos nuevos operadores: & y *

– El operador & se conoce como operador de dirección

• Ubicado antes de una variable, permite conocer su dirección.

• Usualmente esta dirección se almacena en un puntero.

– El operador * se conoce como operador de contenido.

• El objetivo de un puntero es poder manipular la variable a la que

este apunta.

• El operador * ubicado antes de un puntero, representa a la variable

a la que este apunta.

char c, *pt;pt = &c;

c = ‘A’

printf(“%c\n”,*pt);

*pt = ‘N’;

printf(“%c\n”,c);

&c devuelve la dirección de c, y se esta almacenado en el puntero a pt.

pt apunta a c

*pt se refiere a la variable a la que apunta pt -> c

Es equivalente a :Printf(“%c”, c);

Es equivalente a :c = ‘N’

Imprime ‘N’ pues c ya cambio

c es un carácter, pt es un puntero a caracter



3) Change Value to Reference• C: Manipulación de Punteros: Ejercicio en Clase

*p1 = *p2;

int x,y;

int *p1,*p2;

x = -42;

y = 163;

p1 = &x;

p2 = &y;

*p1 = 17;

*p2 = x+5;

-42

163

1000

1004

1000

1004

1008

1012

x

y

p2

17

22

22

Es equivalente a escribir x = y;

p1 = p2;Esto indica que p1 ahora apunta

a la misma variable que p2

1004 p1

p1 = NULL;

p2 = NULL;

Esto es equivalente a “encerar” el puntero, y decir que no apunta a

ninguna variable

0

0



3) Change Value to Reference• C: Paso de Parámetros por valor

• Hasta ahora vimos y hemos usado una forma sencilla de pasar parámetros a las

funciones (por valor).

• Cada parámetro de una función espera y recibe una copia del valor de cada

argumento enviado. Ejemplo:

• Cree una función que reciba dos valores y los intercambie.

• Podríamos decir que el prototipo seria:

– void Intercambiar(int a, int b);

• Al retornar la función no efectuaría el

cambio, como lo deseamos. Recordemos

que, al pasar parámetros, se efectúa una

copia de los valores. Este tipo de paso de

parámetros se conoce como PASO DE

PARAMETROS POR VALOR

main()

{

int x, y;

printf(“Ingrese x:”);

x = GetInteger();

printf(“Ingrese y:”);

y = GetInteger();

printf(“x = %d, y= %d”, x, y);

Intercambiar(x,y);


}

void Intercambiar(int a, int b)

{

int tmp;

tmp = a;

a = b;

b = tmp;

}

x

main

y

3 4Intercambiar

a b tmp

33 434

x

main

y

3 4




• C: Paso de Parámetros por referencia– El intercambio en la función anterior no se realiza porque jamás se

trabajo con los argumentos.

– En el paso de parámetros por valor, la función trabaja con una copia de los argumentos.

– Si deseamos que una función manipule sus parámetros, y esto se refleje en los argumentos, se usa paso de parámetros por referencia. En este caso:

• La función no trabaja con copias

• Trabaja directamente con los argumentos

• La función no recibe valores, sino que recibe direcciones de memoria… es decir: punteros

– El paso de parámetros por referencia es útil:

• Cuando deseamos intercambiar valores.

• Cuando deseamos que una función retorne más de un valor.

– Como todos sabemos las funciones solo pueden retornar un valor

– Si necesitamos que una función retorne más de un valor, aquellos valores que necesitamos retornar, deben ser parámetros por referencia.



3) Change Value to Reference• C: Paso de Parámetros por referencia

xmain

y

• Si la función no va a recibir valores, si no direcciones, el prototipo seria:

void Intercambiar(int *a, int *b);

3 4

• Los parámetros a y b son ahora punteros, que representan a los argumentos directamente.

• Cualquier cambio que se haga sobre a y b se esta haciendo realmente a las variables a las que estos apuntan.

Intercambiar

*a *b tmp

4 3

3 43 34

x

3 43

mainy

4 3

main()

{

int x, y;

printf(“Ingrese x:”);

x = GetInteger();

printf(“Ingrese y:”);

y = GetInteger();


Intercambiar(&x,&y);


}

void Intercambiar(int *a, int *b)

{

int tmp;

tmp = *a;

*a = *b;

*b = tmp;

}

En este caso: a apunta a x, b apunta a y

a = &x, b = &y

No se envían valores, se

envían direcciones



3) Change Value to Reference• Java: Las referencias a objetos se pasan por valor

– Todas las referencias a objetos en Java se pasan por valor. Estosignifica que se pasará una copia del valor a un método. Pero eltruco es que pasar una copia del valor también cambia el valorreal del objeto. Para entender por qué, comience con esteejemplo:

public class ObjectReferenceExample {public static void main(String... doYourBest) {

Simpson simpson = new Simpson();transformIntoHomer(simpson);System.out.println(simpson.name);

}static void transformIntoHomer(Simpson simpson) {

simpson.name = "Homer";}

}

class Simpson { String name; }

¿Cuál crees que será

simpson.name después

de que se ejecute el

método

transformIntoHomer?

En este caso, ¡será Homer! La razón es que las variables de objeto de Java son

simplemente referencias que apuntan a objetos reales en la cabecera de memoria (memory

heap). Por lo tanto, aunque Java pasa parámetros a métodos por valor, si la variable apunta

a una referencia de objeto, el objeto real también cambiará.



3) Change Value to Reference• Java: ¿Se pasan los tipos primitivos por valor?

– Al igual que los tipos de objeto, los tipos primitivos también se pasan

por valor. ¿Puede deducir qué pasará con los tipos primitivos en el

siguiente ejemplo de código?

public class PrimitiveByValueExample {public static void main(String... primitiveByValue) {

int homerAge = 30;changeHomerAge(homerAge);System.out.println(homerAge);

}

static void changeHomerAge(int homerAge) {homerAge = 35;

}}

Es 30 porque

(nuevamente) Java

pasa parámetros de

objeto por valor

El número 30 es solo una copia del valor, no el valor real. Los tipos primitivos se asignan en

la pila de memoria (stack memory), por lo que solo se cambiará el valor local. En este caso,

no hay referencia de objeto.




Volviendo al caso de refactorización…

• Beneficios– Un objeto contiene toda la información más actual sobre una

entidad en particular.

– Si el objeto se cambia en una parte del programa, estoscambios son accesibles desde las otras partes del programaque hacen uso del objeto.

• Inconvenientes– Las referencias son mucho más difíciles de implementar.

• ¿Cómo Refactorizar de esta forma?– Utilice Replace Constructor with Factory Method en la clase a

partir de la cual se generarán las referencias.

– Determine qué objeto será responsable de proporcionar accesoa las referencias. En lugar de crear un nuevo objeto, cuando lonecesite, ahora deberá obtenerlo de un objeto dealmacenamiento o de un campo de diccionario estático.




– Determine si las referencias se crearán por adelantado o

dinámicamente según sea necesario. Si los objetos se crean

con anticipación, asegúrese de cargarlos antes de usarlos.

– Cambie el método de fábrica para que devuelva una referencia.

Si los objetos se crean con anticipación, decida cómo manejar

los errores cuando se solicita un objeto inexistente. También es

posible que deba utilizar el método Rename Method para

informar que el método devuelve solo objetos existentes.



4) Change Reference to Value• Problema

– Tiene un objeto de referencia que es demasiado pequeño y que

se cambia con poca frecuencia para justificar la gestión de su

ciclo de vida.

• Solución

– Conviértalo en un objeto de valor.

class Product { applyDiscount(arg) {this._price.amount -= arg;}

class Product { applyDiscount(arg) {

this._price = new Money(this._price.amount - arg, this._price.currency); }


– La inspiración para cambiar de una referencia a un valor puede provenir de la

inconveniencia de trabajar con la referencia. Las referencias requieren gestión

de su parte:

• Siempre requieren solicitar el objeto necesario de almacenamiento.

• Puede resultar inconveniente trabajar con las referencias en la memoria.

• Trabajar con referencias es particularmente difícil, en comparación con

valores, en sistemas distribuidos y paralelos.

– Los objetos de valor son especialmente útiles si prefiere tener objetos

inmutables que objetos cuyo estado puede cambiar durante su vida.

inverso de Change Value to Reference



4) Change Reference to Value• Beneficios

– Una propiedad importante de los objetos es que deben ser inmutables. Sedebe recibir el mismo resultado para cada consulta que devuelva un valorde objeto. Si esto es cierto, no surgen problemas si hay muchos objetosque representan lo mismo.

– Los objetos de valor son mucho más fáciles de implementar.

• Inconvenientes– Si un valor se puede cambiar, asegúrese de que si algún objeto cambia, los

valores de todos los demás objetos que representan la misma entidad seactualizan. Esto es tan oneroso que es más fácil crear una referencia paraeste propósito.

• ¿Cómo Refactorizar de esta forma?– Haz que el objeto sea inmutable. El objeto no debe tener ningún

establecedor u otros métodos que cambien su estado y datos (RemoveSetting Method puede ayudar aquí). El único lugar donde se deben asignardatos a los campos de un objeto de valor es un constructor.

– Cree un método de comparación para poder comparar dos valores.

– Compruebe si puede eliminar el método de fábrica y hacer público elconstructor del objeto.



5) Replace Array with Object

• Problema: Tiene una

matriz que contiene varios

tipos de datos.

• Solución: Reemplace la matriz con

un objeto que tendrá campos

separados para cada elemento.

Esta técnica de refactorización es un caso especial de Replace Data Value with Object.

String[] row = new String[2]; row[0] = "Liverpool"; row[1] = "15";

Performance row = new Performance(); row.setName("Liverpool"); row.setWins("15");


– Las matrices son una excelente herramienta para almacenar datos y

colecciones de un solo tipo. Pero si usa una matriz como apartados de

correos, almacenando el nombre de usuario en el casillero 1 y la

dirección del usuario en el casillero 14, algún día estará muy

descontento por haberlo hecho. Este enfoque conduce a fallas

catastróficas cuando alguien coloca algo en la "caja“ (dirección)

incorrecta y también requiere su tiempo para averiguar qué datos se

almacenan y dónde.



5) Replace Array with Object• Beneficios

– En la clase resultante, puede colocar todos los comportamientos asociados quese habían almacenado previamente en la clase principal o en otro lugar.

– Los campos de una clase son mucho más fáciles de documentar que loselementos de una matriz.

• ¿Cómo Refactorizar de esta forma?– Cree la nueva clase que contendrá los datos de la matriz. Coloque la propia

matriz en la clase como campo público.

– Cree un campo para almacenar el objeto de esta clase en la clase original. Noolvide crear también el objeto en sí en el lugar donde inició la matriz de datos.

– En la nueva clase, cree métodos de acceso uno por uno para cada uno de loselementos de la matriz. Póngale nombres que se expliquen por sí mismos queindiquen lo que hacen. Al mismo tiempo, reemplace cada uso de un elemento dematriz en el código principal con el método de acceso correspondiente.

– Cuando se hayan creado métodos de acceso para todos los elementos, hagaque la matriz sea privada.

– Para cada elemento de la matriz, cree un campo privado en la clase y luegocambie los métodos de acceso para que utilicen este campo en lugar de lamatriz.

– Cuando se hayan movido todos los datos, elimine la matriz.



6) Duplicate Observed Data• Problema

– ¿Los datos dedominio sealmacenan en clasesresponsables de laGUI?

• Solución– Es una buena idea

separar los datos enclases separadas,asegurando laconexión ysincronización entre laclase de dominio y laGUI.



6) Duplicate Observed Data

• ¿Por qué Refactorizar de esta forma?– Desea tener varias vistas de interfaz para los mismos datos (por

ejemplo, tiene una aplicación de escritorio y una aplicaciónmóvil). Si no logra separar la GUI del dominio, tendrá muchasdificultades para evitar la duplicación de código y una grancantidad de errores.

• Beneficios– Se divide la responsabilidad entre clases de lógica de negocio y

clases de presentación (consulte el Principio de responsabilidadúnica), lo que hace que su programa sea más legible ycomprensible.

– Si necesita agregar una nueva vista de interfaz, cree nuevasclases de presentación; no es necesario tocar el código de lalógica de negocio (cf. el principio abierto / cerrado).

– Ahora, diferentes personas pueden trabajar en la lógica denegocio y las interfaces de usuario.



6) Duplicate Observed Data

• Recordando… El patrón observer:

Un mecanismo de suscripción permite a los objetos individuales suscribirse a

notificaciones de eventos.

El notificador notifica a los suscriptores invocando el método de notificación específico

de sus objetos.



6) Duplicate Observed Data• Recordando… El patrón observer:

1. El Notificador (Publisher) envía eventos deinterés a otros objetos. Esos eventos ocurrencuando el notificador cambia su estado o ejecutaalgunos comportamientos. Los notificadorescontienen una infraestructura de suscripción quepermite a nuevos y antiguos suscriptoresabandonar la lista.

2. Cuando sucede un nuevo evento, elnotificador recorre la lista de suscripción einvoca el método de notificación declaradoen la interfaz suscriptora en cada objetosuscriptor.

3. La interfaz Suscriptora(suscriber) declara la interfaz denotificación. En la mayoría de loscasos, consiste en un únicométodo actualizar (update). Elmétodo puede tener variosparámetros que permitan alnotificador pasar algunos detallesdel evento junto a laactualización.

4. Los SuscriptoresConcretos realizan algunasacciones en respuesta a lasnotificaciones emitidas por elnotificador. Todas estas clasesdeben implementar la mismainterfaz de forma que elnotificador no esté acoplado aclases concretas.



6) Duplicate Observed Data• Recordando… El patrón observer:

5. Normalmente, lossuscriptores necesitan ciertainformación contextual paramanejar correctamente laactualización. Por este motivo,a menudo los notificadorespasan cierta información decontexto como argumentosdel método de notificación. Elnotificador puede pasarse a símismo como argumento,dejando que los suscriptoresextraigan la informaciónnecesaria directamente.

6. El Cliente crea objetos tipo notificador y suscriptor por separado y después registra a los suscriptores para las actualizaciones del notificador.



6) Duplicate Observed Data• ¿Cuándo no refactorizar de esta forma?

– Esta técnica de refactorización, que en su forma clásica se realizautilizando el patrón Observer, no es aplicable para aplicaciones web,donde todas las clases son recreadas entre consultas al servidor web.

– De todos modos, el principio general de extraer la lógica de negocio enclases separadas también se puede justificar para las aplicaciones web.Pero esto se implementará utilizando diferentes técnicas de refactorizacióndependiendo de cómo esté diseñado su sistema.

• ¿Cómo Refactorizar de esta forma?– Oculte el acceso directo a los datos del dominio en la clase GUI. Para ello,

es mejor utilizar Self Encapsulate Field. Así que cree los métodos get y setpara estos datos.

– En los controladores para eventos de clase de GUI, use métodos set paraestablecer nuevos valores de campo. Esto le permitirá pasar estos valoresal objeto de dominio asociado.

– Cree una clase de dominio y copie los campos necesarios de la clase GUIen ella. Cree métodos get y set para todos estos campos.



6) Duplicate Observed Data– Cree un patrón Observer para estas dos clases:

• En la clase de dominio, cree una matriz para almacenar objetosObserver (objetos GUI), así como métodos para registrarlos, eliminarlosy notificarlos.

• En la clase GUI, cree un campo para almacenar referencias a la clase dedominio, así como al método update (), que reaccionará a los cambiosen el objeto y actualizará los valores de los campos en la clase GUI.Tenga en cuenta que las actualizaciones de valores deben establecersedirectamente en el método para evitar la recursividad.

• En el constructor de la clase GUI, cree una instancia de la clase dedominio y guárdela en el campo que ha creado. Registre el objeto GUIcomo observador en el objeto de dominio.

• En los métodos set de los campos de la clase de dominio, llame almétodo para notificar al observador (en otras palabras, método paraactualizar en la clase GUI), para pasar los nuevos valores a la GUI.

• Cambie los métodos set de los campos de la clase GUI para queestablezcan nuevos valores en el objeto de dominio directamente. Tengacuidado para asegurarse de que los valores no se establezcan a travésde un método set de clase de dominio; de lo contrario, se producirá unarecursividad infinita.



7) Change Unidirectional Association to Bidirectional


– Originalmente las clases tenían una asociación unidireccional. Pero con el tiempo, el

código del cliente necesitaba acceso a ambos lados de la asociación.

• Beneficios

– Si una clase necesita una asociación inversa, simplemente puede calcularla. Pero si

estos cálculos son complejos, es mejor mantener la asociación inversa.

• Inconvenientes

– Las asociaciones bidireccionales son mucho más difíciles de implementar y mantener

que las unidireccionales.

– Las asociaciones bidireccionales hacen que las clases sean interdependientes. Con

una asociación unidireccional, uno de ellos se puede utilizar independientemente del

otro.

• Problema– Tiene dos clases y cada una necesita usar las

características de la otra, pero la asociaciónentre ellas es solo unidireccional.

• Solución– Agregue la asociación que falta a la clase que la

necesita.

inverso de Change Bidirectional Association to Unidirectional



7) Change Unidirectional Association to Bidirectional

• ¿Cómo Refactorizar de esta forma?– Agregue un campo para mantener la asociación inversa.

– Decida qué clase será "dominante". Esta clase contendrá losmétodos que crean o actualizan la asociación a medida que seagregan o cambian elementos, estableciendo la asociación ensu clase y llamando a los métodos de utilidad para establecer laasociación en el objeto asociado.

– Cree un método de utilidad para establecer la asociación en laclase "no dominante". El método debe usar lo que seproporciona en los parámetros para completar el campo. Asigneal método un nombre obvio para que no se utilice más adelantepara ningún otro propósito.

– Si los métodos antiguos para controlar la asociaciónunidireccional estaban en la clase "dominante", complételos conllamadas a métodos de utilidad desde el objeto asociado.

– Si los métodos antiguos para controlar la asociación estaban enla clase "no dominante", cree los métodos en la clase"dominante", llámelos y delegue la ejecución en ellos.



8) Change Bidirectional Association to Unidirectional• Problema

– Se tiene una asociación bidireccional entre clases, pero una de las clases no usa lasfunciones de la otra.

• Solución– Elimine la asociación no utilizada.

• ¿Por qué Refactorizar de esta forma?– Una asociación bidireccional es generalmente más difícil de mantener que una

unidireccional, lo que requiere código adicional para crear y eliminar correctamentelos objetos relevantes. Esto hace que el programa sea más complicado.

– Además, una asociación bidireccional implementada incorrectamente puede causarproblemas para la garbage collection-recolección de basura (lo que a su vez lleva aque la memoria se hinche debido a los objetos no utilizados).

– Ejemplo: el recolector de basura elimina objetos de la memoria a los que ya no hacenreferencia otros objetos. Supongamos que se creó, usó y luego abandonó un par deobjetos User-Order. Pero estos objetos no se borrarán de la memoria ya que todavíase refieren entre sí. Dicho esto, este problema se está volviendo menos importantegracias a los avances en los lenguajes de programación, que ahora identificanautomáticamente las referencias a objetos no utilizados y las eliminan de la memoria.

– También está el problema de la interdependencia entre clases. En una asociaciónbidireccional, las dos clases deben conocerse entre sí, lo que significa que no sepueden usar por separado. Si muchas de estas asociaciones están presentes, lasdiferentes partes del programa se vuelven demasiado dependientes entre sí ycualquier cambio en un componente puede afectar a los otros componentes.

inverso de Change Unidirectional Association to Bidirectional



8) Change Bidirectional Association to Unidirectional

• Beneficios

– Simplifica la clase que no necesita la relación. Menos código equivale a menos

mantenimiento de código.

– Reduce la dependencia entre clases. Las clases independientes son más fáciles

de mantener ya que cualquier cambio en una clase afecta solo a esa clase.


– Asegúrese de que se cumpla una de las siguientes condiciones para sus clases:

• No se utiliza ninguna asociación.

• Hay otra forma de obtener el objeto asociado, como a través de una

consulta de base de datos.

• El objeto asociado se puede pasar como argumento a los métodos que lo

utilizan.

– Dependiendo de su situación, el uso de un campo que contiene una asociación

con otro objeto debe ser reemplazado por un parámetro o llamada a un método

para obtener el objeto de una manera diferente.

– Elimina el código que asigna el objeto asociado al campo.

– Elimina el campo ahora no utilizado.



9) Replace Magic Number with Symbolic Constant


– Un número mágico es un valor numérico que se encuentra en la fuentepero que no tiene un significado obvio. Este "anti-patrón" dificulta lacomprensión del programa y la refactorización del código.

– Sin embargo, surgen más dificultades cuando necesita cambiar estenúmero mágico. Buscar y reemplazar no funcionará para esto: elmismo número puede usarse para diferentes propósitos en diferenteslugares, lo que significa que tendrá que verificar cada línea de códigoque use este número.

• Problema: Su código usa un número que tiene cierto significado.

• Solución: Reemplaza este número con una constante que tenga un

nombre legible por humanos que explique el significado del número.

double potentialEnergy(double mass, double height) { return mass * height * 9.81;

}

static final double GRAVITATIONAL_CONSTANT = 9.81; double potentialEnergy(double mass, double height) {

return mass * height * GRAVITATIONAL_CONSTANT; }




• Beneficios

– La constante simbólica puede servir como documentación viva del

significado de su valor.

– Es mucho más fácil cambiar el valor de una constante que buscar este

número en todo el código base, sin el riesgo de cambiar

accidentalmente el mismo número utilizado en otro lugar para un

propósito diferente.

– Reducir el uso duplicado de un número o cadena en el código. Esto es

especialmente importante cuando el valor es complicado y largo (como

3.14159 o 0xCAFEBABE).

• Bueno saber

– No todos los números son mágicos. Si el propósito de un número es

obvio, no es necesario reemplazarlo. Un ejemplo clásico es:

for (i = 0; i < сount; i++) { ... }




• Alternativas

– A veces, un número mágico se puede reemplazar con llamadas a métodos.

Por ejemplo, si tiene un número mágico que indica el número de elementos

de una colección, no es necesario que lo utilice para comprobar el último

elemento de la colección. En su lugar, utilice el método estándar para

obtener la longitud de la colección.

– A veces se utilizan números mágicos como código de tipo. Supongamos

que tiene dos tipos de usuarios y usa un campo numérico en una clase

para especificar cuál es cuál: los administradores son 1 y los usuarios

normales son 2. En este caso, debe utilizar uno de los métodos de

refactorización para evitar el código de tipo:

• Replace Type Code with Class

• Replace Type Code with Subclasses

• Replace Type Code with State/Strategy




• ¿Cómo Refactorizar de esta forma?– Declare una constante y asígnele el valor del número mágico.

– Encuentre todas las menciones del número mágico.

– Para cada uno de los números que encuentre, verifique que el número

mágico en este caso particular corresponda al propósito de la constante. Si

es así, reemplace el número con su constante. Este es un paso importante,

ya que el mismo número puede significar cosas absolutamente diferentes

(y reemplazado por diferentes constantes, según sea el caso).



10) Encapsulate Field• Problema: Tienes un

campo público.

• Solución: Haga que el campo sea

privado y cree métodos de acceso

para él.

class Person { public String name;

}

class Person { private String name; public String getName() {

return name; } public void setName(String arg) {

name = arg; }

}• ¿Por qué Refactorizar de esta forma?

– Uno de los pilares de la programación orientada a objetos es la

encapsulación (capacidad de ocultar datos de objetos).

– Sin ello, todos los objetos serían públicos y otros objetos podrían obtener y

modificar los datos de su objeto sin ningún control ni equilibrio. Los datos

se separan de los comportamientos asociados con estos datos, la

modularidad de las secciones del programa se ve comprometida y el

mantenimiento se vuelve complicado.



10) Encapsulate Field

• Los datos no encapsulados son muestras de un mal diseño

de aplicaciones OO. Utilice los procedimientos de obtención y

configuración de propiedades para proporcionar acceso

público a variables privadas (encapsuladas).

public class Course

{

public List students;

}

int classSize = course.students.size();

public class Course

{


public List getStudents()

{

return students;

}

public void setStudents(List s)

{

students = s;

}

}

int classSize = course.getStudents().size();



10) Encapsulate Field• Beneficios

– Si los datos y el comportamiento de un componente están estrechamente

relacionados entre sí y se encuentran en el mismo lugar del código, le resultará

mucho más fácil mantener y desarrollar este componente.

– También puede realizar operaciones complicadas relacionadas con el acceso a

los campos del objeto.

• ¿Cuándo no debo aplicarlo?

– En algunos casos, la encapsulación no es aconsejable debido a consideraciones

de rendimiento. Estos casos son raros pero cuando ocurren, esta circunstancia

es muy importante.

– Digamos que tiene un editor gráfico que contiene objetos que poseen

coordenadas x e y. Es poco probable que estos campos cambien en el futuro.

Además, el programa involucra una gran cantidad de objetos diferentes en los

que estos campos están presentes. Por lo tanto, acceder a los campos de

coordenadas directamente ahorra ciclos de CPU significativos que, de otro

modo, se ocuparían al llamar a los métodos de acceso.

– Como ejemplo de este caso inusual, está la clase Point en Java. Todos los

campos de esta clase son públicos.



10) Encapsulate Field• ¿Cómo Refactorizar de esta forma?

– Crea un método get y set para el campo.

– Encuentra todas las invocaciones del campo. Reemplace la recepción

del valor del campo con métodos get y reemplace la asignación de los

nuevos valores del campo con métodos set .

– Una vez reemplazadas todas las invocaciones de campo, convierta el

campo en private.

• Próximos pasos– Encapsulate Field es solo el primer paso para acercar los datos y los

comportamientos relacionados con estos datos. Después de crear

métodos simples para los campos de acceso, debe volver a verificar los

lugares donde se llaman estos métodos. Es muy posible que el código

en estas áreas parezca más apropiado en los métodos de acceso.



11) Encapsulate Collection

• Problema

– Una clase contiene un campo de colección y métodos get y set

simples para trabajar con la colección.

• Solución.

– Haga que el valor devuelto por el método get sea de solo lectura

y cree métodos para agregar / eliminar elementos de la

colección.

class Person { get courses() {return this._courses;} set courses(aList) {this._courses = aList;}

class Person { get courses() {return this._courses.slice();} addCourse(aCourse) { ... } removeCourse(aCourse) { ... }



11) Encapsulate Collection


– Una clase contiene un campo que contiene una colección de

objetos. Esta colección puede ser una matriz, una lista, un

conjunto o un vector. Se han creado los métodos get y set

normales para trabajar con la colección.

– Pero las colecciones deben ser utilizadas por un protocolo que

sea un poco diferente al utilizado por otros tipos de datos.

• El método get no debería devolver el objeto de la colección en

sí, ya que esto permitiría a los clientes cambiar el contenido de

la colección sin el conocimiento de la clase propietaria.

• Además, esto mostraría demasiado de las estructuras internas

de los datos del objeto a los clientes. El método para obtener

elementos de colección debería devolver un valor que no

permita cambiar la colección o revelar datos excesivos sobre su

estructura.



11) Encapsulate Collection– Además, no debería haber un método que asigne un valor a la

colección. En su lugar, debería haber operaciones para agregar yeliminar elementos. Gracias a esto, el objeto propietario obtiene controlsobre la adición y eliminación de elementos de la colección.

– Dicho protocolo encapsula adecuadamente una colección, lo quefinalmente reduce el grado de asociación entre la clase propietaria y elcódigo del cliente.

• Beneficios– El campo de colección está encapsulado dentro de una clase. Cuando

se llama al método get, se devuelve una copia de la colección, lo queevita el cambio accidental o la sobrescritura de los elementos de lacolección sin el conocimiento de la clase que contiene la colección.

– Si los elementos de la colección están contenidos dentro de un tipoprimitivo, como un array, debes crear métodos más convenientes paratrabajar con la colección.

– Si los elementos de la colección están contenidos dentro de uncontenedor no primitivo (clase de colección estándar), al encapsular lacolección puedes restringir el acceso a métodos estándar no deseadosde la colección (como restringir la adición de nuevos elementos).



11) Encapsulate Collection• ¿Cómo Refactorizar de esta forma?

– Cree métodos para agregar y eliminar elementos de la colección.Deben aceptar elementos de colección en sus parámetros.

– Asigne una colección vacía al campo como valor inicial si esto no sehace en el constructor de la clase.

– Encuentra las llamadas al método set del campo de la colección.Cambie el método set para que use operaciones para agregar yeliminar elementos, o haga que estas operaciones llamen al código delcliente.

Tenga en cuenta que los métodos set solo se pueden usar para reemplazartodos los elementos de la colección por otros. Por lo tanto, puede seraconsejable cambiar el nombre del método set (Rename Method) a replace.

– Busque todas las llamadas a métodos get de la colección después delas cuales se cambia la colección. Cambie el código para que use susnuevos métodos para agregar y eliminar elementos de la colección.

– Cambie el método get para que devuelva una representación de sololectura de la colección.

– Inspeccione el código de cliente que usa la colección en busca decódigo que se vería mejor dentro de la propia clase de colección.



12) Replace Type Code with Class

Problema: Una clase tiene un campo quecontiene un type code. Los valores de estetipo no se utilizan en condiciones deoperador y no afectan el comportamiento delprograma.

¿Qué es el type code? (o código de tipo)

Ocurre cuando, en lugar de un tipo de datos separado, tiene un conjunto de números o

cadenas que forman una lista de valores permitidos para alguna entidad. A menudo,

estos números y cadenas específicos reciben nombres comprensibles a través de

constantes, que es la razón por la que este type code se encuentre con frecuencia.

Solución: Cree una nueva clase y

use sus objetos en lugar de los

valores del type code.



12) Replace Type Code with Class• ¿Por qué Refactorizar de esta forma?

– Una de las razones más comunes para el type code es trabajarcon bases de datos, cuando una base de datos tiene campos enlos que algún concepto complejo está codificado con un númeroo cadena.

– Por ejemplo, tiene la clase Usuario con el campo user_role,que contiene información sobre los privilegios de acceso decada usuario, ya sea administrador, editor o usuario normal.Entonces, en este caso, esta información se codifica en elcampo como A, E y U respectivamente.

– ¿Cuáles son las deficiencias de este enfoque? Los definidoresde campo a menudo no verifican qué valor se envía, lo quepuede causar grandes problemas cuando alguien envía valoresincorrectos o no intencionados a estos campos.

– Además, la verificación de tipo es imposible para estos campos.Es posible enviarles cualquier número o cadena, cuyo tipo noserá verificado por su IDE e incluso permitirá que su programase ejecute (y se bloquee más tarde).



12) Replace Type Code with Class

• Beneficios– Queremos convertir conjuntos de valores primitivos, que es lo

que son los type code, en clases completas con todos losbeneficios que ofrece la programación orientada a objetos.

– Al reemplazar el type code con clases, permitimos sugerenciasde tipo para los valores pasados a métodos y campos en el niveldel lenguaje de programación.

– Por ejemplo, mientras que el compilador anteriormente no veíala diferencia entre su constante numérica y algún númeroarbitrario cuando se pasa un valor a un método, ahora cuandose pasan datos que no se ajustan a la clase de tipo indicada, sele advierte del error dentro de su IDE.

– Por lo tanto, hacemos posible mover código a las clases del tipo.Si necesita realizar manipulaciones complejas con valores detipo en todo el programa, ahora este código puede "vivir" dentrode una o varias clases de tipos.



12) Replace Type Code with Class• ¿Cuándo no debo aplicarlo?

– Si los valores de un type code se utilizan dentro de las estructuras de flujo de control(if, switch, etc.) y controlan el comportamiento de una clase, debe utilizar una de lasdos técnicas de refactorización para el tipo de código:

• Replace Type Code with Subclasses

• Replace Type Code with State/Strategy

• ¿Cómo Refactorizar de esta forma?– Cree una nueva clase y asígnele un nuevo nombre que corresponda al propósito del

type code. Aquí lo llamaremos clase de tipo.

– Copie el campo que contiene el type code en la clase de tipo y conviértalo en privado.Luego crea un método get para el campo. Se establecerá un valor para este camposolo desde el constructor.

– Para cada valor del type code, cree un método estático en la clase de tipo. Creará unnuevo objeto de clase de tipo correspondiente a este valor del type code.

– En la clase original, reemplace el tipo del campo codificado con clase de tipo. Cree unnuevo objeto de este tipo tanto en el constructor como en el método set de campo.Cambie el método get de campo para que llame al método get de clase de tipo.

– Reemplace cualquier mención de valores del type code con llamadas de los métodosestáticos de la clase de tipo relevante.

– Elimine las constantes de type code de la clase original.



13) Replace Type Code with Subclasses

• Problema– Tiene un type code que afecta directamente el comportamiento del

programa (los valores de este campo activan varios códigos encondicionales).

• Solución.– Cree subclases para cada valor del type code. Luego, extraiga los

comportamientos relevantes de la clase original a estas subclases.Reemplace el código de flujo de control con polimorfismo.

• ¿Por qué Refactorizar de esta forma?– Esta técnica de refactorización es un giro más complicado de Replace Type

Code with Class.

– Como en el primer método de refactorización, tiene un conjunto de valoressimples que constituyen todos los valores permitidos para un campo.Aunque estos valores a menudo se especifican como constantes y tienennombres comprensibles, su uso hace que su código sea muy propenso aerrores, ya que todavía son primitivos en efecto.

– Por ejemplo, tiene un método que acepta uno de estos valores en losparámetros. En un momento determinado, en lugar de la constanteUSER_TYPE_ADMIN con el valor "ADMIN", el método recibe la misma cadenaen minúsculas ("admin"), lo que provocará la ejecución de algo más que elautor (tú) no pretendías.




– Aquí se trata de un código de flujo de control, como los condicionales if,switch y?:. En otras palabras, los campos con valores codificados (como$usuario->tipo === self::USER_TYPE_ADMIN) se utilizan dentro de lascondiciones de estos operadores. Si usáramos Replace Type Code withClass aquí, todas estas construcciones de flujo de control se moveríanmejor a una clase responsable del tipo de datos. En última instancia, esto,por supuesto, crearía una clase de tipo muy similar a la original, con losmismos problemas también.

• Beneficios

– Elimina el código de flujo de control. En lugar de un modificador voluminosoen la clase original, mueva el código a las subclases apropiadas. Estomejora la adherencia al principio de responsabilidad única y hace que elprograma sea más legible en general.

– Si necesita agregar un nuevo valor para un type code, todo lo que necesitahacer es agregar una nueva subclase sin tocar el código existente (consulteel Principio Abierto / Cerrado).

– Al reemplazar el type code con clases, allanamos el camino para lasugerencia de tipo (type hinting) para métodos y campos en el nivel dellenguaje de programación. Esto no sería posible utilizando valoresnuméricos o de cadena simples contenidos en un type code.



13) Replace Type Code with Subclasses• ¿Cuándo no debo aplicarlo?

– Esta técnica no es aplicable si ya tiene una jerarquía de clases. No puedecrear una jerarquía dual a través de la herencia en la programaciónorientada a objetos. Aún así, puede reemplazar el type code a través de lacomposición en lugar de la herencia. Para hacerlo, use Replace Type Codewith State/Strategy.

– Si los valores del type code pueden cambiar después de la creación de unobjeto, evite esta técnica. Se tendría que reemplazar de alguna manera laclase del objeto en sí sobre la marcha, lo cual no es posible. Aún así, unaalternativa en este caso también sería Replace Type Code withState/Strategy.

• ¿Cómo Refactorizar de esta forma?– Utilice Self Encapsulate Field para crear un método get para el campo que

contiene el type code.

– Hacer privado el constructor de la superclase. Cree un método de fábrica(factory) estático con los mismos parámetros que el constructor desuperclase. Debe contener el parámetro que tomará los valores iniciales deltype code. Dependiendo de este parámetro, el método de fábrica crearáobjetos de varias subclases. Para ello, en su código debes crear un unalarga sentencia condicional pero, al menos, será el único cuando searealmente necesario; de lo contrario, servirán las subclases y elpolimorfismo.




– Cree una subclase única para cada valor del type code . En él, redefina

el método get del type code para que devuelva el valor

correspondiente del type code .

– Elimine el campo con el type code de la superclase. Haga que su

método get sea abstracto.

– Ahora que tiene subclases, puede comenzar a mover los campos y

métodos de la superclase a las subclases correspondientes (con la

ayuda de Push Down Field y Push Down Method).

– Cuando se haya movido todo lo posible, use Replace Conditional with

Polymorphism para deshacerse de las condiciones que usan el type

code de una vez por todas.



14) Replace Type Code with State/Strategy

• Problema

– Tiene un type code que afecta el comportamiento, pero no

puede usar subclases para deshacerse de él.

• Solución.

– Reemplace el type code con un objeto de estado. Si es

necesario reemplazar un valor de campo con un type code, se

"conecta" otro objeto de estado.


– Tiene un type code y afecta el comportamiento de una clase, por

lo tanto, no podemos usar Replace Type Code with Class.

– El type code afecta el comportamiento de una clase, pero no

podemos crear subclases para el type code debido a la jerarquía

de clases existente u otras razones. Por lo tanto, significa que

no podemos aplicar Replace Type Code with Subclasses.




• Beneficios– Esta técnica de refactorización es una forma de salir de

situaciones en las que un campo con un type code cambia suvalor durante la vida útil del objeto. En este caso, la sustitucióndel valor se realiza mediante la sustitución del objeto de estadoal que se refiere la clase original.

– Si necesita agregar un nuevo valor de un type code, todo lo quenecesita hacer es agregar una nueva subclase de estado sinalterar el código existente (consulte el Principio Abierto /Cerrado).

• Inconvenientes– Si tiene un caso simple de type code pero usa esta técnica de

refactorización de todos modos, tendrá muchas clasesadicionales (e innecesarias).




• Bueno saber– La implementación de esta técnica de refactorización puede hacer uso

de uno de dos patrones de diseño: State o Strategy. La implementaciónes la misma sin importar el patrón que elija. Entonces, ¿qué patróndebería elegir en una situación particular?

– Si está intentando dividir un condicional que controla la selección dealgoritmos, use Strategy.

– Pero si cada valor del type code es responsable no solo de seleccionarun algoritmo sino de toda la condición de la clase, el estado de la clase,los valores de campo y muchas otras acciones, State es mejor paradicho caso.

• ¿Cómo Refactorizar de esta forma?– Utilice Self Encapsulate Field para crear un método get para el campo

que contiene el type code.

– Cree una nueva clase y asígnele un nombre comprensible que seajuste al propósito del type code . Esta clase jugará el papel de State (oStrategy). En él, cree un método get de campo codificado abstracto.




– Cree subclases de la state class para cada valor del type code.En cada subclase, redefina el método get del campo codificadopara que devuelva el valor correspondiente del type code.

– En la abstract state class, cree un método de fábrica estáticoque acepte el valor del type code como parámetro. Dependiendode este parámetro, el método de fábrica creará objetos de variosestados. Para ello, en su código crea una gran sentenciacondicional; será el único cuando se complete la refactorización.

– En la clase original, cambie el tipo de campo codificado a lastate class. En el método set del campo, llame al método deestado de fábrica para obtener nuevos objetos de estado.

– Ahora puede comenzar a mover los campos y métodos de lasuperclase a las subclases de estado correspondientes (usandoPush Down Field y Push Down Method).

– Cuando todo lo movible se haya movido, use ReplaceConditional with Polymorphism para deshacerse de loscondicionales que usan type code de una vez por todas.



15) Replace Subclass with Fields

• Problema: Tiene subclases que difieren solo en sus métodos

(retorno de constante).

• Solución: Reemplace los métodos con campos en la clase principal y

elimine las subclases.

class Person { get genderCode() {return "X";}

} class Male extends Person {

get genderCode() {return "M";} } class Female extends Person {

get genderCode() {return "F";} }

class Person { get genderCode() {return this._genderCode;}

}

inverso de Replace Type Code with Subclasses



15) Replace Subclass with Fields


– A veces, la refactorización es solo el boleto para evitar el type code .

– En uno de esos casos, una jerarquía de subclases puede ser diferente solo

en los valores devueltos por métodos particulares. Estos métodos ni

siquiera son el resultado de un cálculo, sino que se establecen

estrictamente en los propios métodos o en los campos devueltos por los

métodos. Para simplificar la arquitectura de clases, esta jerarquía se puede

comprimir en una sola clase que contiene uno o varios campos con los

valores necesarios, según la situación.

– Estos cambios pueden ser necesarios después de mover una gran cantidad

de funciones de una jerarquía de clases a otro lugar. La jerarquía actual ya

no es tan valiosa y sus subclases ahora son un peso muerto.

• Beneficios

– Simplifica la arquitectura del sistema. Crear subclases es excesivo si todo

lo que quiere hacer es devolver diferentes valores en diferentes métodos.



15) Replace Subclass with Fields• ¿Cómo Refactorizar de esta forma?

– Aplicar Replace Constructor with Factory Method a las subclases.

– Reemplace las llamadas al constructor de subclase con llamadas almétodo de fábrica de superclase.

– En la superclase, declare campos para almacenar los valores de cadauno de los métodos de subclase que devuelven valores constantes.

– Cree un constructor de superclase protegido para inicializar los nuevoscampos.

– Cree o modifique los constructores de subclase existentes para quellamen al nuevo constructor de la clase padre y le pasen los valoresrelevantes.

– Implemente cada método constante en la clase principal para quedevuelva el valor del campo correspondiente. Luego elimine el métodode la subclase.

– Si el constructor de la subclase tiene funcionalidad adicional, use InlineMethod para incorporar el constructor en el método de fábrica de lasuperclase.

– Elimina la subclase..






• Organizing Data






Simplifying Conditional Expressions(Simplificar expresiones condicionales)

• Los condicionales tienden

a complicarse cada vez

más en su lógica con el

tiempo.

• Por ello, existen técnicas

para quitar la

complicación en dichas

sentencias.



1) Decompose Conditional

• Problema: Tienes un condicional complejo (if-then/else o switch).

• Solución: Descomponga las partes complicadas del condicional en

métodos separados: la condición, then y else.

if (date.before(SUMMER_START) || date.after(SUMMER_END)) { charge = quantity * winterRate + winterServiceCharge;

} else { charge = quantity * summerRate;

}

if (isSummer(date)) { charge = summerCharge(quantity);

} else { charge = winterCharge(quantity);

}



1) Decompose Conditional

• Beneficios– Al extraer código condicional a métodos con nombres claros, le facilita la vida a

la persona que mantendrá el código más adelante (¡como usted, dentro de dos meses!).

– Esta técnica de refactorización también es aplicable para expresiones cortas en condiciones. La cadena isSalaryDay() es mucho más bonita y más descriptiva que el código para comparar fechas.

• ¿Cómo Refactorizar de esta forma?– Extraiga el condicional a un método separado mediante Extract Method.

– Repita el proceso para los bloques then y else.


– Cuanto más largo es un fragmento de código, más difícil de entender. Lascosas se vuelven aún más difíciles de entender cuando el código está lleno decondiciones:

• Mientras estás ocupado averiguando qué hace el código en el bloque then,olvidas cuál era la condición relevante.

• Mientras estás ocupado analizando el else, olvidas lo que hace el then.



2) Consolidate Conditional Expression


– Su código contiene muchos operadores alternos que realizan acciones idénticas. No

está claro por qué los operadores están divididos.

– El objetivo principal de la consolidación es extraer el condicional a un método

separado para mayor claridad.

• Problema: Tiene múltiples

condicionales que conducen al

mismo resultado o acción.

• Solución: Consolide todos estos

condicionales en una sola expresión.

double disabilityAmount() { if (seniority < 2) {

return 0; } if (monthsDisabled > 12) {

return 0; } if (isPartTime) {

return 0; } // Compute the disability amount.// ...

}

double disabilityAmount() { if (isNotEligibleForDisability()) {

return 0; } // Compute the disability amount.// ...

}



2) Consolidate Conditional Expression• Beneficios

– Elimina el código de flujo de control duplicado. La combinación devarios condicionales que tienen el mismo "destino" ayuda a demostrarque solo está haciendo una verificación complicada que conduce a unaacción.

– Al consolidar todos los operadores, ahora puede aislar esta expresióncompleja en un nuevo método con un nombre que explique el propósitodel condicional.

• ¿Cómo Refactorizar de esta forma?– Antes de refactorizar, asegúrese de que los condicionales no tengan

ningún "efecto secundario" o modifiquen algo, en lugar de simplementedevolver valores. Los efectos secundarios pueden estar ocultos en elcódigo ejecutado dentro del propio operador, como cuando se agregaalgo a una variable en función de los resultados de un condicional.

– Consolide los condicionales en una sola expresión utilizando and y or.Como regla general a la hora de consolidar:

• Los condicionales anidados se unen mediante and.

• Los condicionales consecutivos se unen con or.

– Realice el Extract Method en las condiciones del operador y asigne almétodo un nombre que refleje el propósito de la expresión



3) Consolidate Duplicate Conditional Fragments


– El código duplicado se encuentra dentro de todas las ramas de un condicional, amenudo como resultado de la evolución del código dentro de las ramascondicionales. El desarrollo del equipo puede ser un factor que contribuya a ello.

• Beneficios

– Desduplicación de código.

• Problema: Se puede encontrar

un código idéntico en todas las

ramas de un condicional.

• Solución: Mueva el código fuera

del condicional.

if (isSpecialDeal()) { total = price * 0.95; send();

} else { total = price * 0.98; send();

}

if (isSpecialDeal()) { total = price * 0.95;

} else { total = price * 0.98;

} send();

También llamado Slide Statements



3) Consolidate Duplicate Conditional Fragments


– Si el código duplicado está al comienzo de las ramas

condicionales, mueva el código a un lugar antes del condicional.

– Si el código se ejecuta al final de las ramas, colóquelo después

del condicional.

– Si el código duplicado está situado aleatoriamente dentro de las

ramas, primero intente mover el código al principio o al final de

la rama, dependiendo de si cambia el resultado del código

posterior.

– Si es apropiado y el código duplicado tiene más de una línea,

intente usar Extract Method.



4) Remove Control Flag• Problema

– Tiene una variable booleana que actúa como un indicador

de control para múltiples expresiones booleanas.

• Solución.– En lugar de la variable, use break, continue y return.

for (const p of people) { if (! found) {

if ( p === "Don") { sendAlert(); found = true;

}// ...

for (const p of people) { if ( p === "Don") { sendAlert(); break;

}// ...



4) Remove Control Flag


– Los indicadores/banderas de control se remontan a los días de antaño,

cuando los programadores "adecuados" siempre tenían un punto de

entrada para sus funciones (la línea de declaración de función) y un

punto de salida (al final de la función).

– En los lenguajes de programación modernos este estilo está obsoleto,

ya que contamos con operadores especiales para modificar el flujo de

control en bucles y otras construcciones complejas:

• break: detiene el bucle

• continue: detiene la ejecución de la rama del ciclo actual y va a

comprobar las condiciones del ciclo en la siguiente iteración

• return: detiene la ejecución de toda la función y devuelve su

resultado si se da en el operador



4) Remove Control Flag• Beneficios

– El código de bandera de control suele ser mucho más pesado que el

código escrito con operadores de flujo de control.

• ¿Cómo Refactorizar de esta forma?– Encuentre la asignación de valor a la bandera de control que causa la

salida del ciclo o la iteración actual.

– Reemplácelo con break, si se trata de una salida de un bucle;

continue, si se trata de una salida de una iteración, o return, si

necesita devolver este valor de la función.

– Elimine el código restante y las comprobaciones asociadas con la

bandera de control.



5) Replace Nested Conditional with Guard Clauses

Problema: Tiene un grupo de

condicionales anidados y es difícil

determinar el flujo normal de

ejecución del código.Solución: Aísle todos los controles

especiales y casos extremos en

cláusulas separadas y colóquelos antes

de los controles principales. Idealmente,

debería tener una lista "plana" de

condicionales, uno tras otro.

public double getPayAmount() { double result; if (isDead){

result = deadAmount(); } else {

if (isSeparated){ result = separatedAmount();

} else { if (isRetired){

result = retiredAmount(); } else{

result = normalPayAmount(); }

} } return result;

}

public double getPayAmount() { if (isDead){

return deadAmount(); } if (isSeparated){

return separatedAmount(); } if (isRetired){

return retiredAmount();} return normalPayAmount();

}





– Detectar el "condicional del infierno" es bastante fácil. Las hendiduras de cada nivel de anidamiento forman una flecha que apunta hacia la derecha en la dirección del dolor y aflicción (ver ejemplo)

– Es difícil averiguar qué hace cada condicional y cómo, ya que el flujo "normal" de ejecución del código no es inmediatamente obvio. Estos condicionales indican una evolución vertiginosa, con cada condición añadida como medida provisional sin pensar en optimizar la estructura general.

– Para simplificar la situación, aísle los casos especiales en condiciones separadas que terminen inmediatamente la ejecución y devuelvan un valor nulo si las cláusulas de protección son verdaderas. En efecto, su misión aquí es hacer que la estructura sea plana.

if(){ if(){

do{if(){

if(){if(){

...}

} ...

} ...

} while(); ...

} else{

... }

}





– Intente eliminar los efectos secundarios del código: Separate Query from

Modifier puede ser útil para este propósito. Esta solución será necesaria

para la reorganización que se describe a continuación.

• Aísle todas las cláusulas de protección que lleven a llamar a una excepción

o al retorno inmediato de un valor del método. Coloque estas condiciones al

comienzo del método.

• Una vez que se completa la reordenación y todas las pruebas se completan

con éxito, vea si puede usar Consolidate Conditional Expression para

cláusulas de protección que conducen a las mismas excepciones o valores

devueltos.



6) Replace Conditional with Polymorphism

• Problema: Tiene un condicional que realiza varias

acciones según el tipo de objeto o las propiedades.

• Solución: Cree subclases que coincidan con las ramas del condicional. En

ellos, cree un método compartido y mueva el código de la rama

correspondiente del condicional a él. Luego reemplace el condicional con la

llamada al método relevante. El resultado es que se logrará la

implementación adecuada mediante polimorfismo dependiendo de la clase

de objeto.

class Bird { // ...double getSpeed() {

switch (type) { case EUROPEAN: return getBaseSpeed(); case AFRICAN: return getBaseSpeed() - getLoadFactor() * numberOfCoconuts; case NORWEGIAN_BLUE: return (isNailed) ? 0 : getBaseSpeed(voltage);

} throw new RuntimeException("Should be unreachable"); } }



abstract class Bird { // ...abstract double getSpeed();

} class European extends Bird { double getSpeed() {

return getBaseSpeed(); }

} class African extends Bird { double getSpeed() {

return getBaseSpeed() - getLoadFactor() * numberOfCoconuts; }

} class NorwegianBlue extends Bird { double getSpeed() {

return (isNailed) ? 0 : getBaseSpeed(voltage); }

}

// Somewhere in client codespeed = bird.getSpeed();




6) Replace Conditional with Polymorphism• ¿Por qué Refactorizar de esta forma?

– Esta técnica de refactorización puede ayudar si su código contieneoperadores que realizan varias tareas que varían según:

• Clase del objeto o interfaz que implementa

• Valor del campo de un objeto

• Resultado de llamar a uno de los métodos de un objeto

– Si aparece una nueva propiedad o tipo de objeto, deberá buscar yagregar código en todos los condicionales similares. Por lo tanto, elbeneficio de esta técnica se multiplica si hay múltiples condicionalesdispersos en todos los métodos de un objeto.

• Beneficios– Esta técnica se adhiere al principio de Tell-Don’t-Ask (decir-no

preguntar): en lugar de preguntarle a un objeto sobre su estado y luegorealizar acciones basadas en esto, es mucho más fácil simplementedecirle al objeto lo que necesita hacer y dejar que decida por sí mismocómo hacer eso.

– Elimina el código duplicado. Te deshaces de muchos condicionales casiidénticos.

– Si necesita agregar una nueva variante de ejecución, todo lo quenecesita hacer es agregar una nueva subclase sin tocar el códigoexistente (Principio Abierto / Cerrado).




• ¿Cómo Refactorizar de esta forma?Preparándose para refactorizar– Para esta técnica de refactorización, debe tener lista una

jerarquía de clases que contendrá comportamientosalternativos. Si no tiene una jerarquía como esta, creeuna. Otras técnicas ayudarán a que esto suceda:

• Replace Type Code with Subclasses. Se crearán subclasespara todos los valores de una propiedad de objeto en particular.Este enfoque es simple pero menos flexible, ya que no puedecrear subclases para las otras propiedades del objeto.

• Replace Type Code with State/Strategy. Se dedicará una clasea una propiedad de objeto en particular y se crearán subclasesa partir de ella para cada valor de la propiedad. La clase actualcontendrá referencias a los objetos de este tipo y les delegarála ejecución.

– Los siguientes pasos asumen que ya ha creado lajerarquía.




Pasos de refactorización

– Si el condicional está en un método que también realiza otras

acciones, ejecute Extract Method.

– Para cada subclase de jerarquía, redefina el método que

contiene el condicional y copie el código de la rama condicional

correspondiente a esa ubicación.

– Elimina esta rama del condicional.

– Repita el reemplazo hasta que el condicional esté vacío. Luego

elimine el condicional y declare el método abstracto..



7) Introduce Null Object

Problema: Dado que algunos

métodos devuelven null en lugar

de objetos reales, tiene muchas

comprobaciones de null en su

código.

Solución: En lugar de null, devuelve un

objeto nulo que muestre el comportamiento

predeterminado.

if (customer == null) { plan = BillingPlan.basic();

} else { plan = customer.getPlan();

}

class NullCustomer extends Customer { boolean isNull() {

return true; } Plan getPlan() {

return new NullPlan(); } // Some other NULL functionality.

}

// Replace null values with Null-object.customer = (order.customer != null) ?

order.customer : new NullCustomer();

// Use Null-object as if it's normal //subclass.plan = customer.getPlan();

También llamado Introduce Special Case



• Si confía en null para el comportamiento predeterminado, use la

herencia en su lugar

public class User

{

Plan getPlan()

{

return plan;

}

}

public class User

{

Plan getPlan()

{

return plan;

}

}

public class NullUser extends User

{

Plan getPlan()

{

return Plan.basic();

}

}

if (user == null)

plan = Plan.basic();

else

plan = user.getPlan();



– Docenas de comprobaciones de null hacen que su código sea más largo y feo.

• Inconvenientes

– El precio de deshacerse de los condicionales es crear otra clase nueva.




– A partir de la clase en cuestión, cree una subclase que desempeñará elpapel de objeto nulo.

– En ambas clases, cree el método isNull(), que devolverá true para unobjeto nulo y falso para una clase real.

– Encuentra todos los lugares donde el código puede devolver un valor nullen lugar de un objeto real. Cambie el código para que devuelva un objetonulo.

– Encuentre todos los lugares donde las variables de la clase real secomparan con null. Reemplace estas comprobaciones con una llamada aisNull().

– Si los métodos de la clase original se ejecutan en estos condicionalescuando un valor no es igual a null, redefina estos métodos en la clasenula e inserte allí el código de la parte else de la condición. Luego, puedeeliminar todo el comportamiento condicional y diferente se implementarámediante polimorfismo.

– Si las cosas no son tan simples y los métodos no se pueden redefinir, veasi puede simplemente extraer los operadores que se suponía que debíanrealizarse en el caso de un valor null a nuevos métodos del objeto nulo.Llame a estos métodos en lugar del código anterior en else como lasoperaciones por defecto.




8) Introduce Assertion

• Problema: Para que una parte del código funcione correctamente,

ciertas condiciones o valores deben ser verdaderos

• Solución: Reemplace estas suposiciones con verificaciones de

afirmaciones específicas.

double getExpenseLimit() { // Should have either expense limit or// a primary project.return (expenseLimit != NULL_EXPENSE) ? expenseLimit : primaryProject.getMemberExpenseLimit();

}

double getExpenseLimit() { Assert.isTrue(expenseLimit != NULL_EXPENSE || primaryProject != null);

return (expenseLimit != NULL_EXPENSE) ? expenseLimit: primaryProject.getMemberExpenseLimit();

}



• ¿Por qué Refactorizar de esta forma?– Supongamos que una parte del código asume algo sobre, por ejemplo, la

condición actual de un objeto o el valor de un parámetro o variable local. Por

lo general, esta suposición siempre será cierta, excepto en caso de error.

– Haga que estas suposiciones sean obvias agregando las afirmaciones

correspondientes. Al igual que con las sugerencias de tipo en los

parámetros del método, estas afirmaciones pueden actuar como

documentación en vivo para su código.

– Como guía para ver dónde su código necesita afirmaciones, busque

comentarios que describan las condiciones bajo las cuales funcionará un

método en particular.

• Beneficios– Si una suposición no es cierta y, por lo tanto, el código da un resultado

incorrecto, es mejor detener la ejecución antes de que esto cause

consecuencias fatales y corrupción de datos. Esto también significa que se

olvidó de escribir una prueba necesaria al idear formas de realizar las

pruebas del programa.




• Inconvenientes– A veces, una excepción es más apropiada que una simple afirmación.

Puede seleccionar la clase necesaria de la excepción y dejar que elcódigo restante la maneje correctamente.

– ¿Cuándo es mejor una excepción que una simple afirmación? Si laexcepción puede ser causada por acciones del usuario o del sistema yusted puede manejar la excepción. Por otro lado, las excepcionesordinarias sin nombre y no controladas son básicamente equivalentes aafirmaciones simples: no las maneja y son causadas exclusivamentecomo resultado de un error del programa que nunca debería haberocurrido.

• ¿Cómo Refactorizar de esta forma?– Cuando vea que se asume una condición, agregue una aserción para

esta condición para asegurarse.

– Agregar la afirmación no debería cambiar el comportamiento delprograma.

– No se exceda con el uso de aserciones para todo en su código.Compruebe solo las condiciones necesarias para el correctofuncionamiento del código. Si su código funciona normalmente inclusocuando una aserción en particular es falsa, puede eliminar la aserciónde manera segura.







• Organizing Data






Simplifying Method Calls(Simplificación de llamadas a métodos)

• Estas técnicas hacen que las llamadas a

métodos sean más simples y fáciles de entender.

Esto, a su vez, simplifica las interfaces para la

interacción entre clases.



1) Rename Method

• Quizás uno de los más simples, pero uno de los más útiles que vale

la pena repetir: si el nombre de un método no revela su propósito,

cambie el nombre del método.

public class Customer

{

public double getinvcdtlmt();

}


{

public double getInvoiceCreditLimit();

}

También llamado Rename Function, Change Signature



1) Rename Method• Problema

– El nombre de un método no explica qué hace el método.

• Solución.

– Cambie el nombre del método.


– Quizás un método fue nombrado mal desde el principio; por ejemplo,

alguien creó el método apresuradamente y no le dio la debida atención

a nombrarlo bien.

– O quizás el método estaba bien nombrado al principio, pero a medida

que su funcionalidad crecía, el nombre del método dejó de ser un buen

descriptor.

• Beneficios

– Legibilidad del código. Intente darle al nuevo método un nombre que

refleje lo que hace. Algo como createOrder(),

renderCustomerInfo(), etc.



1) Rename Method

• ¿Cómo Refactorizar de esta forma?– Vea si el método está definido en una superclase o

subclase. Si es así, también debe repetir todos los pasosde estas clases.

– El siguiente método es importante para mantener lafuncionalidad del programa durante el proceso derefactorización.

• Cree un método nuevo con un nombre nuevo. Copie el códigodel método anterior en él.

• Elimine todo el código del método anterior y, en lugar de ello,inserte una llamada para el nuevo método.

– Busque todas las referencias al método anterior yreemplácelas con referencias al nuevo.

– Elimina el método anterior. Si el método anterior es partede una interfaz pública, no realice este paso. En su lugar,marque el método antiguo como obsoleto.



2) Add Parameter


– Debe realizar cambios en un método y estos cambios requieren

agregar información o datos que anteriormente no estaban disponibles

para el método.

• Beneficios

– La elección aquí es entre agregar un nuevo parámetro o agregar un

nuevo campo privado que contiene los datos que necesita el método.

– Un parámetro es preferible cuando necesita algunos datos ocasionales

o que cambian con frecuencia para los que no tiene sentido

mantenerlos en un objeto todo el tiempo. En este caso, la

refactorización dará sus frutos.

– De lo contrario, agregue un campo privado y rellénelo con los datos

necesarios antes de llamar al método.

• Problema

– Un método no tiene suficientes datos para realizardeterminadas acciones.

• Solución.

– Cree un nuevo parámetro para pasar los datos necesarios.

inverso de Remove Parameter



2) Add Parameter

• Inconvenientes

– Agregar un nuevo parámetro siempre es más fácil que

eliminarlo, por lo que las listas de parámetros con frecuencia se

amplían a tamaños grotescos. Este code smell se conoce como

Long Parameter List.

– Si necesita agregar un nuevo parámetro, a veces esto significa

que su clase no contiene los datos necesarios o que los

parámetros existentes no contienen los datos relacionados

necesarios.

– En ambos casos, la mejor solución es considerar mover datos a

la clase principal o para otras clases cuyos objetos ya son

accesibles desde dentro del método.



2) Add Parameter

• ¿Cómo Refactorizar de esta forma?– Vea si el método está definido en una superclase o

subclase. Si el método está presente en ellos, tambiéndeberá repetir todos los pasos en estas clases.

– El siguiente paso es fundamental para mantener suprograma funcional durante el proceso de refactorización.Cree un nuevo método copiando el anterior y agregue elparámetro necesario. Reemplace el código del métodoantiguo con una llamada al método nuevo. Puede agregarcualquier valor al nuevo parámetro (como null paraobjetos o un cero para números).

– Busque todas las referencias al método anterior yreemplácelas con referencias al nuevo método.

– Elimina el método anterior. La eliminación no es posible siel método anterior es parte de la interfaz pública. Si ese esel caso, marque el método anterior como obsoleto.



3) Remove Parameter• Problema

– Un parámetro no se usa en el cuerpo de un método.

• Solución.– Elimina el parámetro no utilizado.

• ¿Por qué Refactorizar de esta forma?– Cada parámetro en una llamada a un método obliga al programador a

leerlo para averiguar qué información se encuentra en este parámetro. Y siun parámetro no se utiliza por completo en el cuerpo del método, escodificado en vano.

– Y en cualquier caso, los parámetros adicionales son código adicional quedebe ejecutarse.

– A veces agregamos parámetros con miras al futuro, anticipando cambios enel método para el cual el parámetro podría ser necesario. De todos modos,la experiencia demuestra que es mejor agregar un parámetro solo cuandoes realmente necesario. Después de todo, los cambios anticipados amenudo siguen siendo solo eso: anticipados.

• Beneficios– Un método contiene solo los parámetros que realmente requiere.

inverso de Add Parameter



3) Remove Parameter• ¿Cuándo no debo aplicarlo?

– Si el método se implementa de diferentes maneras en subclases oen una superclase, y su parámetro se usa en esasimplementaciones, deje el parámetro como está.

• ¿Cómo Refactorizar de esta forma?– Vea si el método está definido en una superclase o subclase. Si es

así, ¿se utiliza el parámetro allí? Si el parámetro se utiliza en unade estas implementaciones, espere con esta técnica derefactorización.

– El siguiente paso es importante para mantener el programafuncional durante el proceso de refactorización. Cree un nuevométodo copiando el anterior y elimine el parámetro relevante de él.Reemplace el código del método anterior con una llamada alnuevo.

– Busque todas las referencias al método anterior y reemplácelas conreferencias al nuevo método.

– Elimine el método anterior. No realice este paso si el métodoanterior es parte de una interfaz pública. En este caso, marque elmétodo antiguo como obsoleto.



4) Separate Query from Modifier

• Problema

– ¿Tiene un método que devuelve un valor pero también cambia algo dentro

de un objeto?

• Solución.

– Divida el método en dos métodos separados. Uno de ellos debe devolver el

valor y el otro modifica el objeto.

function getTotalOutstandingAndSendBill() { const result = customer.invoices.reduce((total, each) =>

each.amount + total, 0); sendBill(); return result;

}

function totalOutstanding() { return customer.invoices.reduce((total, each) =>

each.amount + total, 0); } function sendBill() {

emailGateway.send(formatBill(customer)); }



4) Separate Query from Modifier• ¿Por qué Refactorizar de esta forma?

– Esta técnica de factorización implementa la segregación de responsabilidad

de consultas y comandos. Este principio nos dice que separemos el código

responsable de obtener datos del código que cambia algo dentro de un

objeto.

– El código para obtener datos se denomina consulta (query). El código para

cambiar cosas en el estado visible de un objeto se denomina modificador

(modifier). Cuando se combinan una consulta y un modificador, no tiene

forma de obtener datos sin realizar cambios en su condición. En otras

palabras, haces una pregunta y puedes cambiar la respuesta incluso

mientras la recibes. Este problema se agrava aún más cuando la persona

que llama a la consulta puede no conocer los "efectos secundarios" del

método, lo que a menudo conduce a errores en tiempo de ejecución.

– Pero recuerde que los efectos secundarios son peligrosos solo en el caso

de modificadores que cambian el estado visible de un objeto. Estos podrían

ser, por ejemplo, campos accesibles desde la interfaz pública de un objeto,

entrada en una base de datos, en archivos, etc. Si un modificador solo

almacena en caché una operación compleja y la guarda dentro del campo

privado de una clase, difícilmente puede causar ningún lado efectos.



4) Separate Query from Modifier

• Beneficios– Si tiene una consulta que no cambia el estado de su programa, puede llamarlo

tantas veces como quiera sin tener que preocuparse por cambios nointencionales en el resultado causados por el mero hecho de que llame almétodo.

• Inconvenientes– En algunos casos, es conveniente obtener datos después de ejecutar un

comando. Por ejemplo, al eliminar algo de una base de datos, desea sabercuántas filas se eliminaron.

• ¿Cómo Refactorizar de esta forma?– Cree un nuevo método de consulta para devolver lo que hizo el método original.

– Cambie el método original para que devuelva solo el resultado de llamar alnuevo método de consulta.

– Reemplace todas las referencias al método original con una llamada al métodode consulta. Inmediatamente antes de esta línea, realice una llamada al métodomodificador. Esto le evitará efectos secundarios en caso de que el métodooriginal se haya utilizado en una condición de operador o bucle condicional.

– Deshágase del código que devuelve valor en el método original, que ahora se haconvertido en un método modificador adecuado.



5) Parameterize Method• Problema

– Múltiples métodos realizan acciones similares que son diferentes solo

en sus valores internos, números u operaciones.

• Solución

– Combine estos métodos utilizando un parámetro que pasará el valor

especial necesario.

function tenPercentRaise(aPerson) { aPerson.salary = aPerson.salary.multiply(1.1);

} function fivePercentRaise(aPerson) {

aPerson.salary = aPerson.salary.multiply(1.05); }

function raise(aPerson, factor) { aPerson.salary = aPerson.salary.multiply(1 + factor);

}



5) Parameterize Method


– Si tienes métodos similares, probablemente tengas códigoduplicado, con todas las consecuencias que esto conlleva.

– Es más, si necesita agregar otra versión de esta funcionalidad,tendrá que crear otro método. En su lugar, puede simplementeejecutar el método existente con un parámetro diferente.

• Inconvenientes

– A veces, esta técnica de refactorización puede llevarse demasiadolejos, lo que resulta en un método común largo y complicado enlugar de varios métodos más simples.

– También tenga cuidado al mover la activación / desactivación de lafuncionalidad a un parámetro. Eventualmente, esto puede conducira la creación de un gran operador condicional que deberá tratarsemediante Replace Parameter with Explicit Methods.



5) Parameterize Method


– Cree un nuevo método con un parámetro y muévalo al código

que es el mismo para todas las clases, aplicando Extract

Method. Tenga en cuenta que, a veces, solo una parte

determinada de los métodos es realmente la misma. En este

caso, la refactorización consiste en extraer solo la misma parte a

un nuevo método.

– En el código del nuevo método, reemplace el valor especial /

diferente con un parámetro.

– Para cada método antiguo, busque los lugares donde se llama,

reemplazando estas llamadas con llamadas al nuevo método

que incluyen un parámetro. Luego elimine el método anterior.



6) Replace Parameter with Explicit Methods

Problema: Un método se divide en partes, cada

una de las cuales se ejecuta según el valor de un

parámetro.Solución: Extraiga las partes individuales

del método en sus propios métodos y

llámelos en lugar del método original.void setValue(String name, int value) { if (name.equals("height")) {

height = value; return; } if (name.equals("width")) {

width = value; return; } Assert.shouldNeverReachHere();

}

void setHeight(int arg) { height = arg;

} void setWidth(int arg) {

width = arg; }

• ¿Por qué Refactorizar de esta forma?– Un método que contiene variantes dependientes de parámetros se ha vuelto

masivo. Se ejecuta código no trivial en cada rama y rara vez se agregan nuevasvariantes.

• Beneficios– Mejora la legibilidad del código. Es mucho más fácil entender el propósito de

startEngine() que setValue("engineEnabled", true).

También llamado Remove Flag Argument



6) Replace Parameter with Explicit Methods

• ¿Cuándo no debo aplicarlo?

– No reemplace un parámetro con métodos explícitos si un método rara vez se

cambia y no se agregan nuevas variantes dentro de él.


– Para cada variante del método, cree un método independiente. Ejecute estos

métodos según el valor de un parámetro en el método principal.

– Encuentra todos los lugares donde se llama al método original. En estos

lugares, realice una llamada para una de las nuevas variantes dependientes

de parámetros.

– Cuando no queden llamadas al método original, elimínelo.



7) Preserve Whole Object• Problema: Obtiene varios valores de un objeto y luego los pasa

como parámetros a un método.

• Solución: En su lugar, intente pasar todo el objeto.

int low = daysTempRange.getLow(); int high = daysTempRange.getHigh(); boolean withinPlan = plan.withinRange(low, high);

boolean withinPlan = plan.withinRange(daysTempRange);

• ¿Por qué Refactorizar de esta forma?– El problema es que cada vez que se llama a su método, se deben llamar a los

métodos del futuro objeto enviado como parámetro. Si se cambian estosmétodos o la cantidad de datos obtenidos para el método, deberá buscarcuidadosamente una docena de esos lugares en el programa e implementarestos cambios en cada uno de ellos.

– Después de aplicar esta técnica de refactorización, el código para obtener todoslos datos necesarios se almacenará en un lugar: el método en sí.

• Beneficios– En lugar de una mezcolanza de parámetros, verá un solo objeto con un nombre

comprensible.

– Si el método necesita más datos de un objeto, no necesitará reescribir todos loslugares donde se usa el método, simplemente dentro del método en sí.



7) Preserve Whole Object

• Inconvenientes– A veces, esta transformación hace que un método se vuelva menos flexible:

anteriormente, el método podía obtener datos de muchas fuentes diferentes,

pero ahora, debido a la refactorización, estamos limitando su uso a solo

objetos con una interfaz en particular.

• ¿Cómo Refactorizar de esta forma?– Cree un parámetro en el método para el objeto del que pueda obtener los

valores necesarios.

– Ahora comience a eliminar los parámetros antiguos del método uno por uno,

reemplazándolos con llamadas a los métodos relevantes del objeto de

parámetro. Pruebe el programa después de cada reemplazo de un

parámetro.

– Elimina el código get del objeto de parámetro que había precedido a la

llamada al método.



8) Replace Parameter with Method Call• Problema: Llamar a un método de consulta y pasar sus resultados como

parámetros de otro método, mientras que ese método podría llamar a la

consulta directamente.

• Solución: En lugar de pasar el valor a través de un parámetro, intente

realizar una llamada de consulta dentro del cuerpo del método.


– Es difícil comprender una lista larga de parámetros. Además, las

llamadas a tales métodos a menudo se asemejan a una serie de

cascadas, con cálculos de valor sinuosos y estimulantes que son

difíciles de navegar pero que deben pasarse al método. Entonces, si el

valor de un parámetro se puede calcular con la ayuda de un método,

hágalo dentro del método y elimine el parámetro.

int basePrice = quantity * itemPrice; double seasonDiscount = this.getSeasonalDiscount(); double fees = this.getFees(); double finalPrice = discountedPrice(basePrice, seasonDiscount, fees);

int basePrice = quantity * itemPrice; double finalPrice = discountedPrice(basePrice);



8) Replace Parameter with Method Call

• Beneficios– Eliminamos los parámetros innecesarios y simplificamos las llamadas a métodos.

Estos parámetros a menudo se crean no para el proyecto como es ahora, sinocon la vista puesta en necesidades futuras que quizás nunca lleguen.

• Inconvenientes– Es posible que necesite el parámetro en el futuro para otras necesidades ... lo

que le obligará a reescribir el método.

• ¿Cómo Refactorizar de esta forma?– Asegúrese de que el código de obtención de valor no utilice parámetros del

método actual, ya que no estarán disponibles desde otro método. Si es así, noes posible mover el código.

– Si el código relevante es más complicado que un solo método o llamada a unafunción, use Extract Method para aislar este código en un nuevo método ysimplificar la llamada.

– En el código del método principal, reemplace todas las referencias al parámetroque se reemplaza con llamadas al método que obtiene el valor.

– Utilice Remove Parameter para eliminar el parámetro que ahora no se utiliza.



9) Introduce Parameter Object

• ¿Por qué Refactorizar de esta forma?– A menudo se encuentran grupos idénticos de parámetros en múltiples

métodos. Esto provoca la duplicación de código tanto de los parámetroscomo de las operaciones relacionadas. Al consolidar los parámetros en unasola clase, también puede mover los métodos para manejar estos datosallí, liberando los otros métodos de este código.

• Problema

– Tus métodos contienen un grupo repetido de parámetros.

• Solución.

– Reemplace estos parámetros con un objeto.

Customer

amountInvoicedIn(from:Date,to:Date) amountReceivedIn(from:Date,to:Date) amountOverdueIn(from:Date,to:Date)

Customer

amountInvoicedIn(r:DateRange) amountReceivedIn(r:DateRange) amountOverdueIn(r:DateRange)

DataRange

from: Date to: Date



9) Introduce Parameter Object• Beneficios

– Código más legible. En lugar de una mezcolanza de parámetros, verá un soloobjeto con un nombre comprensible.

– Grupos idénticos de parámetros dispersos aquí y allá crean su propio tipo deduplicación de código: mientras no se llama a código idéntico, constantementese encuentran grupos idénticos de parámetros y argumentos.

• Inconvenientes– Si mueve solo datos a una nueva clase y no planea mover ningún

comportamiento u operaciones relacionadas allí, esto comienza a oler (codesmell) a una data class.

• ¿Cómo Refactorizar de esta forma?– Cree una nueva clase que represente su grupo de parámetros. Haz que la clase

sea inmutable.

– En el método que desea refactorizar, use Add Parameter, que es donde sepasará su objeto de parámetro. En todas las llamadas a métodos, pase el objetocreado a partir de los parámetros del método antiguo a este parámetro.

– Ahora comience a eliminar los parámetros antiguos del método uno por uno,reemplazándolos en el código con campos del objeto de parámetro. Pruebe elprograma después de cada reemplazo de parámetro.

– Cuando termine, vea si tiene algún sentido mover una parte del método (o, aveces, incluso todo el método) a una clase de objeto de parámetro. Si es así,utilice el Move Method o Extract Method



10) Remove Setting MethodProblema: El valor de un

campo debe establecerse solo

cuando se crea y no cambiar

en ningún momento después

de eso.


– Para evitar cualquier cambio en el valor de un campo.


– El valor de un campo solo debe cambiarse en el constructor. Si el constructor

no contiene un parámetro para establecer el valor, agregue uno.

– Encuentra todas las llamadas a métodos set.

• Si una llamada al método set se encuentra justo después de una llamada al

constructor de la clase actual, mueva su argumento a la llamada al constructor y

elimine el método set.

• Reemplaza las llamadas del setter en el constructor con acceso directo al campo.

– Eliminar el método set.

Solución: Por lo tanto, elimine los

métodos que establecen el valor del

campo.class Person {

get name() {...} set name(aString) {...}

class Person { get name() {...}



11) Hide Method• Problema

– Un método no es usado por otras clases o solo se usa dentro desu propia jerarquía de clases.

• Solución.– Haga que el método sea privado o protegido.

• ¿Por qué Refactorizar de esta forma?– Muy a menudo, la necesidad de ocultar métodos para obtener y

establecer valores se debe al desarrollo de una interfaz más ricaque proporciona un comportamiento adicional, especialmente sicomenzó con una clase que agregó poco más allá de la meraencapsulación de datos.

– A medida que se incorpore un nuevo comportamiento a la clase,es posible que los métodos get y set públicos ya no seannecesarios y puedan ocultarse. Si hace que los métodos get oset sean privados y aplica acceso directo a las variables, puedeeliminar el método.



11) Hide Method

• Beneficios

– Los métodos de ocultación facilitan la evolución de su código.

Cuando cambia un método privado, solo debe preocuparse de

cómo no romper la clase actual, ya que sabe que el método no

se puede usar en ningún otro lugar.

– Al hacer que los métodos sean privados, se subraya la

importancia de la interfaz pública de la clase y de los métodos

que siguen siendo públicos.


– Trate regularmente de encontrar métodos que se puedan

convertir en privados. El análisis estático del código y una buena

cobertura de pruebas unitarias pueden ofrecer una gran ventaja.

– Haga que cada método sea lo más privado posible.



12) Replace Constructor with Factory Method

• Problema: Tiene un constructor complejo

que hace algo más que establecer valores

de parámetros en campos de objeto.

• Solución: Cree un método de fábrica

(factory method) y utilícelo para reemplazar

las llamadas al constructor.


– La razón más obvia para usar esta técnica de refactorización está relacionadacon Replace Type Code with Subclasses.

– Se tiene un código en el que se creó previamente un objeto y se le pasó el valordel tipo codificado. Después de usar el método de refactorización, han aparecidovarias subclases y a partir de ellas es necesario crear objetos según el valor deltipo codificado. Cambiar el constructor original para que devuelva objetos desubclase es imposible, por lo que creamos un método de fábrica estático quedevolverá objetos de las clases necesarias, después de lo cual reemplaza todaslas llamadas al constructor original.

class Employee { Employee(int type) { this.type = type;

} // ...

}

class Employee { static Employee create(int type) {

employee = new Employee(type); // do some heavy lifting.return employee;

} // ...

}



12) Replace Constructor with Factory Method– Los métodos de fábrica también se pueden usar en otras situaciones, cuando los

constructores no están a la altura de la tarea. Pueden ser importantes al intentar

cambiar el valor por referencia. También se pueden utilizar para establecer varios

modos de creación que van más allá del número y tipo de parámetros.

• Beneficios

– Un método de fábrica no necesariamente devuelve un objeto de la clase en la que

fue llamado. A menudo, estas podrían ser sus subclases, seleccionadas en

función de los argumentos dados al método.

– Un método de fábrica puede tener un nombre mejor que describa qué y cómodevuelve lo que hace, por ejemplo, Troops :: GetCrew (myTank).Un método

de fábrica puede devolver un objeto ya creado, a diferencia de un constructor, que

siempre crea una nueva instancia.


– Crea un método de fábrica. Realice una llamada al constructor actual en él.

– Reemplace todas las llamadas al constructor con llamadas al método de fábrica.

– Declare el constructor privado.

– Investigue el código del constructor e intente aislar el código que no esté

directamente relacionado con la construcción de un objeto de la clase actual,

moviendo dicho código al método de fábrica.



13) Replace Error Code with Exception• Problema: ¿Un

método devuelve un

valor especial que

indica un error?• Solución: Lanzar una excepción en su lugar.


– La devolución de códigos de error es un vestigio obsoleto de la

programación de procedimientos.

– En la programación moderna, el manejo de errores se realiza mediante

clases especiales, que se denominan excepciones. Si ocurre un problema,

“lanza (throw)" un error, que luego es "capturado" por uno de los

manejadores de excepciones. El código especial de manejo de errores, que

se ignora en condiciones normales, se activa para responder.

int withdraw(int amount) { if (amount > _balance) {

return -1; } else {

balance -= amount; return 0;

} }

void withdraw(int amount) throws BalanceException { if (amount > _balance) {

throw new BalanceException(); } balance -= amount;

}



13) Replace Error Code with Exception

• Beneficios– Permite separar claramente el procesamiento normal del

procesamiento de errores.

– Libera el código de una gran cantidad de condicionales para verificarvarios códigos de error. Los controladores de excepciones son unaforma mucho más sucinta de diferenciar las rutas de ejecuciónnormales de las anormales.

– Las clases de excepción pueden implementar sus propios métodos, porlo que contienen parte de la funcionalidad de manejo de errores (comopara enviar mensajes de error).

– A diferencia de las excepciones, los códigos de error no se pueden usaren un constructor, ya que un constructor debe devolver solo un nuevoobjeto.

• Inconvenientes– Un manejador de excepciones puede convertirse en una muleta tipo

goto. ¡Evita esto! No use excepciones para administrar la ejecución decódigo. Las excepciones deben lanzarse solo para informar de un erroro una situación crítica.



13) Replace Error Code with Exception


– Intente realizar estos pasos de refactorización solo para un código de

error a la vez. Esto hará que sea más fácil mantener toda la información

importante en su cabeza y evitar errores.

– Encuentre todas las llamadas a un método que devuelva códigos de

error y, en lugar de buscar un código de error, envuélvalo en bloques

try / catch.

– Dentro del método, en lugar de devolver un código de error, lanza una

excepción.

– Cambie la firma del método para que contenga información sobre la

excepción que se lanza (sección @throws).



14) Replace Exception with Test

• Problema: ¿Lanzas una excepción en un lugar donde una simple

comprobación haría el trabajo?

• Solución: Reemplace la excepción con una condición.

double getValueForPeriod(int periodNumber) { try {

return values[periodNumber]; } catch (ArrayIndexOutOfBoundsException e) {

return 0; }

}

double getValueForPeriod(int periodNumber) { if (periodNumber >= values.length) {

return 0; } return values[periodNumber];

}

También llamado Replace Exception with Precheck




• ¿Por qué Refactorizar de esta forma?– Las excepciones deben usarse para manejar el comportamiento

irregular relacionado con un error inesperado. No deberían servir como reemplazo de las pruebas. Si se puede evitar una excepción simplemente verificando una condición antes de ejecutarse, hágalo. Las excepciones deben reservarse para errores reales.

– Por ejemplo, ingresó a un campo minado y activó una mina allí, lo que resultó en una excepción; la excepción se manejó con éxito y usted fue elevado por el aire a un lugar seguro más allá del campo de minas. Pero podría haber evitado todo esto simplemente leyendo la señal de advertencia frente al campo minado para empezar.

• Beneficios– Un condicional simple a veces puede ser más obvio que el

código de manejo de excepciones.





– Cree un condicional para un caso relevante (edge case) y

muévalo antes del bloque try / catch.

– Mueva el código de la sección catch dentro de este condicional.

– En la sección catch, coloque el código para lanzar una

excepción sin nombre habitual y ejecute todas las pruebas.

– Si no se lanzaron excepciones durante las pruebas, elimine el

operador try / catch.






• Organizing Data






Dealing with Generalization(Lidiar con la generalización)

• La abstracción tiene su propio grupo

de técnicas de refactorización,

principalmente asociadas con mover

la funcionalidad a lo largo de la

jerarquía de herencia de clases,

crear nuevas clases e interfaces y

reemplazar la herencia por

delegación y viceversa.

Mamífero

Perro Gato

PoodlePastorAlemán

- colorOjo:String

+ getcolorOjo: String

- frecLadrido:int

+ ladrar::void

- frecMaullido:int

+maullar::void

+ esAleman::void + esFrances::void



1) Pull Up Field• Problema

– Dos clases tienen el mismo campo.

• Solución.– Elimine el campo de las subclases y muévalo a la superclase.

• ¿Por qué Refactorizar de esta forma?– Las subclases crecieron y se desarrollaron por separado, lo que provocó la

aparición de campos y métodos idénticos (o casi idénticos).

• Beneficios– Elimina la duplicación de campos en subclases.

– Facilita la reubicación posterior de métodos duplicados, si existen, desubclases a una superclase.

Mamífero

Perro Gato

- sexo:String

- frecLadrido:int - frecMaullido:int- colorOjo:String - colorOjo:String

Mamífero

Perro Gato

- sexo:String

- frecLadrido:int - frecMaullido:int

- colorOjo:String

Inverso de Push Down Field



1) Pull Up Field

• ¿Cómo Refactorizar de esta forma?– Asegúrese de que los campos se utilicen para las mismas

necesidades en las subclases.

– Si los campos tienen nombres diferentes, asígneles elmismo nombre y reemplace todas las referencias a loscampos en el código existente.

– Cree un campo con el mismo nombre en la superclase.Tenga en cuenta que si los campos fueran privados, elcampo de la superclase debería estar protegido.

– Elimine los campos de las subclases.

– Es posible que desee considerar el uso de SelfEncapsulate Field para el nuevo campo, con el fin deocultarlo detrás de los métodos de acceso.



2) Pull Up Method• Problema

– Sus subclases tienen métodos que realizan un trabajo similar.

• Solución.– Haga que los métodos sean idénticos y luego muévalos a la superclase correspondiente.

• ¿Por qué Refactorizar de esta forma?– Las subclases crecieron y se desarrollaron por separado, lo que provocó la aparición de

campos y métodos idénticos (o casi idénticos).

• Beneficios– Elimina el código duplicado. Si necesita realizar cambios en un método, es mejor hacerlo

en un solo lugar que tener que buscar todos los duplicados del método en subclases.

– Esta técnica de refactorización también se puede usar si, por alguna razón, unasubclase redefine un método de superclase pero realiza lo que es esencialmente elmismo trabajo.

Mamífero

+ ladrar::void +maullar::void

+ emitirSonido::void

Mamífero

Perro Gato

- sexo:String


Perro Gato

- sexo:String




2) Pull Up Method• ¿Cómo Refactorizar de esta forma?

– Investigar métodos similares en superclases. Si no son idénticos,formatéelos para que coincidan.

– Si los métodos usan un conjunto de parámetros diferente, coloquelos parámetros en la forma que desea ver en la superclase.

– Copie el método a la superclase. Aquí puede encontrar que elcódigo del método usa campos y métodos que existen solo ensubclases y, por lo tanto, no están disponibles en la superclase.Para solucionar esto, puede:

• Para campos: use Pull Up Field o Self-Encapsulate Field paracrear captadores y definidores en subclases; luego declareestos captadores de forma abstracta en la superclase.

• Para los métodos: use Pull Up Method o declare métodosabstractos para ellos en la superclase (tenga en cuenta que suclase se volverá abstracta si no lo era anteriormente).Eliminalos métodos de las subclases.

– Compruebe las ubicaciones en las que se llama al método. Enalgunos lugares, es posible que pueda reemplazar el uso de unasubclase con la superclase.



3) Pull Up Constructor Body

• Problema: Tus subclases tienen constructores

con código que en su mayoría es idéntico.

• Solución: Cree un constructor de superclase y mueva el código que es el

mismo en las subclases a él. Llame al constructor de superclase en los

constructores de subclase.

class Manager extends Employee { public Manager(String name, String id, int grade) {

this.name = name; this.id = id; this.grade = grade;

} // ...

}

class Manager extends Employee { public Manager(String name, String id, int grade) { super(name, id); this.grade = grade;

} // ...

}



3) Pull Up Constructor Body• ¿Por qué Refactorizar de esta forma? ¿En qué se diferencia esta

técnica de refactorización del Pull Up Method?– En Java, las subclases no pueden heredar un constructor, por lo que no

puede simplemente aplicar el Pull Up Method al constructor de la subclase y eliminarlo después de eliminar todo el código del constructor de la superclase. Además de crear un constructor en la superclase, es necesario tener constructores en las subclases con una simple delegación al constructor de la superclase.

– En C ++ y Java (si no se llamó explícitamente al constructor de la superclase), el constructor de la superclase se llama automáticamente antes que el constructor de la subclase, lo cual hace necesario mover el código común solo desde el principio de los constructores de la subclase (ya que no se será capaz de llamar al constructor de superclase desde un lugar arbitrario en un constructor de subclase).

– En la mayoría de los lenguajes de programación, un constructor de subclase puede tener su propia lista de parámetros diferentes de los parámetros de la superclase. Por lo tanto, debe crear un constructor de superclase solo con los parámetros que realmente necesita.



3) Pull Up Constructor Body


– Cree un constructor en una superclase.

– Extraiga el código común del principio del constructor de cada

subclase al constructor de la superclase. Antes de hacerlo,

intente mover tanto código común como sea posible al principio

del constructor.

– Coloque la llamada al constructor de superclase en la primera

línea de los constructores de subclase.



4) Push Down Method• Problema

– ¿Se implementa el comportamiento en una superclaseutilizada solo por una (o unas pocas) subclases?

• Solución.– Mueva este comportamiento a las subclases.

Employee

Salesman Engineer

Employee

Salesman Engineer

+ getQuota::double

+ getQuota::double

• ¿Cuándo aplicarlo?

– Cuando el comportamiento en una superclase es relevante solo para

algunas de sus subclases, muévalo a esas subclases.

• Beneficios

– Mejora la coherencia de clase. Un método está ubicado donde espera verlo



4) Push Down Method• ¿Por qué Refactorizar de esta forma?

– Al principio, un determinado método estaba destinado a seruniversal para todas las clases, pero en realidad se usa en una solasubclase. Esta situación puede ocurrir cuando las característicasplanificadas no se materializan.

– Estas situaciones también pueden ocurrir después de unaextracción (o eliminación) parcial de la funcionalidad de unajerarquía de clases, dejando un método que se usa en una solasubclase.

– Si ve que más de una subclase necesita un método, pero no todas,puede resultar útil crear una subclase intermedia y mover el métodoa ella. Esto permite evitar la duplicación de código que resultaría deenviar un método a todas las subclases.

• ¿Cómo Refactorizar de esta forma?– Declare el método en una subclase y copie su código de la

superclase.

– Elimina el método de la superclase.

– Encuentre todos los lugares donde se usa el método y verifique quese llame desde la subclase necesaria.



5) Push Down Field• Problema

– ¿Se usa un campo solo en algunas subclases?

• Solución.– Mueva el campo a estas subclases.

• ¿Por qué Refactorizar de esta forma?– Aunque se planeó usar un campo universalmente para todas las clases, en

realidad el campo se usa solo en algunas subclases. Esta situación puedeocurrir cuando las funciones planificadas no funcionan, por ejemplo.

– Esto también puede ocurrir debido a la extracción (o eliminación) de partede la funcionalidad de las jerarquías de clases.

Mamífero

Perro Gato

- peleaEnTecho:bool

Mamífero

Perro Gato- frecLadrido:int - frecMaullido:int- frecLadrido:int - frecMaullido:int

- peleaEnTecho:bool



5) Push Down Field

• Beneficios

– Mejora la coherencia de clase interna. Un campo está ubicado

donde realmente se usa.

– Al pasar a varias subclases simultáneamente, puede desarrollar

los campos de forma independiente entre sí. Esto crea

duplicación de código, sí, así que empuje los campos hacia

abajo solo cuando realmente tenga la intención de usar los

campos de diferentes maneras.


– Declare un campo en todas las subclases necesarias.

– Elimina el campo de la superclase.



6) Extract Subclass

• Cuando una clase tiene características (atributos y métodos) que solo

serían útiles en instancias especializadas, podemos crear una

especialización de esa clase y darle esas características. Esto hace

que la clase original sea menos especializada (es decir, más

abstracta), y un buen diseño se trata de vincularse a abstracciones

siempre que sea posible.

public class Person

{

private String name;

private String jobTitle;

}

public class Person

{

protected String name;

}

public class Employee extends Person

{


}



6) Extract Subclass• Problema

– Una clase tiene características que se usan solo en ciertos casos.

• Solución.– Cree una subclase y úsala en estos casos.

• ¿Por qué Refactorizar de esta forma?– Su clase principal tiene métodos y campos para implementar un

caso de uso poco común para la clase. Si bien el caso es raro, laclase es responsable de él y sería incorrecto mover todos loscampos y métodos asociados a una clase completamenteseparada. Pero podrían trasladarse a una subclase, que esexactamente lo que haremos con la ayuda de esta técnica derefactorización.

Car

ElectricCar

+ refuel::void

Car- isElectricCar:bool

+ refuel::void

+ refuel::void



6) Extract Subclass• Beneficios

– Crea una subclase rápida y fácilmente.

– Puede crear varias subclases separadas si su clase principal está

implementando actualmente más de uno de esos casos especiales.

• Inconvenientes

– A pesar de su aparente simplicidad, la herencia puede conducir a un callejón sin

salida si tiene que separar varias jerarquías de clases diferentes. Si, por

ejemplo, tuvieras la clase Perro con comportamiento diferente según el tamaño

y el pelaje de los perros, podrías desentrañar dos jerarquías:

• por tamaño: grande, mediano y pequeño

• por pelaje: liso y peludo

– Y todo parecería estar bien, excepto que los problemas surgirán tan pronto

como necesites crear un perro que sea tanto grande como liso, ya que puedes

crear un objeto a partir de una sola clase. Dicho esto, puede evitar este

problema utilizando Composición en lugar de Herencia (consulte el patrón

Strategy). En otras palabras, la clase Perro tendrá dos campos de

componentes, tamaño y pelaje. Conectará los objetos componentes de las

clases necesarias en estos campos. Entonces puedes crear un perro que tenga

tamaño grande y pelaje peludo.



6) Extract Subclass• ¿Cómo Refactorizar de esta forma?

– Cree una nueva subclase de la clase de interés.

– Si necesita datos adicionales para crear objetos a partir de una subclase, creeun constructor y agréguele los parámetros necesarios. No olvide llamar a laimplementación principal del constructor.

– Encuentra todas las llamadas al constructor de la clase padre. Cuando lafuncionalidad de una subclase sea necesaria, reemplace el constructor padrecon el constructor de subclase.

– Mueva los métodos y campos necesarios de la clase principal a la subclase.Haga esto a través del Push Down Method y Push Down Field. Es más sencilloempezar moviendo los métodos primero. De esta manera, los campospermanecen accesibles durante todo el proceso: desde la clase principal antesdel movimiento y desde la propia subclase después de que se completa elmovimiento.

– Una vez que la subclase esté lista, busque todos los campos antiguos quecontrolaban la elección de la funcionalidad. Elimine estos campos utilizandopolimorfismo para reemplazar todos los operadores en los que se han utilizadolos campos. Un ejemplo simple: en la clase Car, tenía el campo isElectricCary, dependiendo de él, en el método refuel() el automóvil se alimenta con gas ose carga con electricidad. Después de la refactorización, se elimina el campoisElectricCar y las clases Car y ElectricCar tendrán sus propiasimplementaciones del método refuel().



7) Extract Superclass

• Cuando encuentre dos o más clases que comparten

características comunes, considere abstraer esas

características compartidas en una superclase.

• Nuevamente, esto facilita la vinculación de clientes a una

abstracción y elimina el código duplicado de las clases

originales.

public class Employee

{



}


{


private Course course;

}

public abstract class Person

{

protected String name;

}

public class Employee extends Person

{


}

public class Student extends Person

{

private Course course;

}



7) Extract Superclass• Problema

– Tiene dos clases con campos y métodos comunes o similares.

• Solución.– Cree una superclase compartida para ellos y mueva todos los campos y

métodos idénticos a ella.

• ¿Por qué Refactorizar de esta forma?– Un tipo de duplicación de código ocurre cuando dos clases realizan tareas

similares de la misma manera o realizan tareas similares de diferentesmaneras. Los objetos ofrecen un mecanismo integrado para simplificar estetipo de situaciones mediante la herencia. Pero a menudo, esta similitudpasa desapercibida hasta que se crean las clases, lo que requiere que secree una estructura de herencia más adelante.

PrintServer FileServer

Outputserver

PrintServer FileServer



7) Extract Superclass

• Beneficios– Desduplicación de código. Los campos y métodos comunes

ahora "viven" en un solo lugar.

• ¿Cuándo no aplicarlo?– No puedes aplicar esta técnica a clases que ya tienen una

superclase.

• ¿Cómo Refactorizar de esta forma?– Crea una superclase abstracta.

– Utilice Pull Up Field, Pull Up Method y Pull Up Constructor Bodypara mover la funcionalidad común a una superclase. Empiecepor los campos, ya que además de los campos comunesnecesitará mover los campos que se utilizan en los métodoscomunes.

– Busque lugares en el código del cliente donde el uso desubclases se pueda reemplazar con su nueva clase (como enlas declaraciones de tipos).



8) Extract Interface

• Problema

– Varios clientes utilizan la misma parte de una

interfaz de clase. Otro caso: parte de la interfaz en

dos clases es la misma.

• Solución.

– Mueva esta parte idéntica a su propia interfaz.

<<Interface>>Collection

.add()addAll()...

LinkedList• ¿Por qué Refactorizar de esta forma?

– Las interfaces son muy apropiadas cuando las clases juegan

roles especiales en diferentes situaciones. Utilice Extract

Interface para indicar explícitamente el rol.

– Otro caso conveniente surge cuando necesita describir las

operaciones que realiza una clase en su servidor. Si se planea

eventualmente permitir el uso de servidores de varios tipos,

todos los servidores deben implementar la interfaz.



8) Extract Interface• Extraiga una interfaz de una clase. Algunos clientes pueden necesitar saber

el nombre de un cliente, mientras que otros solo necesitan saber queciertos objetos se pueden serializar en XML. Tener toXml() como parte dela interfaz del Cliente rompe el principio de diseño de la Segregación deInterfaces que nos dice que es mejor tener interfaces más especializadasque tener una interfaz multipropósito.


{


public String getName(){ return name; }

public void setName(String string)

{ name = string; }

public String toXML()

{ return "<Customer><Name>" +

name + "</Name></Customer>";

}

}

public class Customer implements SerXML

{


public String getName(){ return name; }

public void setName(String string)

{ name = string; }

public String toXML()

{ return "<Customer><Name>" +

name + "</Name></Customer>";

}

}

public interface SerXml {

public abstract String toXML();

}



8) Extract Interface• Bueno saber

– Existe una cierta semejanza entre Extract Superclass y Extract Interface.

– La extracción de una interfaz permite aislar solo las interfaces comunes, no

el código común. En otras palabras, si las clases contienen código

duplicado, la extracción de la interfaz no le ayudará a deduplicar.

– De todos modos, este problema se puede mitigar aplicando Extract Class

para mover el comportamiento que contiene la duplicación a un

componente separado y delegarle todo el trabajo. Si el comportamiento

común es de gran tamaño, siempre puede utilizar Extract Superclass. Esto

es aún más fácil, por supuesto, pero recuerde que si toma este camino,

obtendrá solo una clase para padres.

• ¿Cómo Refactorizar de esta forma?– Crea una interfaz vacía.

– Declare operaciones comunes en la interfaz.

– Declare las clases necesarias como implementadoras de la interfaz.

– Cambie las declaraciones de tipo en el código del cliente para usar la

nueva interfaz.



9) Collapse Hierarchy• Problema

– Tiene una jerarquía de clases en la que una subclase es prácticamenteigual que su superclase.

• Solución.

– Fusionar la subclase y la superclase.


– Su programa ha crecido con el tiempo y una subclase y una superclasese han convertido prácticamente en lo mismo. Se eliminó unacaracterística de una subclase, se movió un método a la superclase ... yahora tiene dos clases similares.

• Beneficios

– Se reduce la complejidad del programa. Menos clases significan menoscosas que tener en cuenta y menos partes móviles frágiles de las quepreocuparse durante futuros cambios de código.

– Navegar por su código es más fácil cuando los métodos se definen enuna clase antes. No es necesario revisar toda la jerarquía paraencontrar un método en particular.

class Employee {...} class Salesman extends Employee {...}

class Employee {...}



9) Collapse Hierarchy• ¿Cuándo no aplicarlo?

– ¿La jerarquía de clases que está refactorizando tiene más de unasubclase? Si es así, una vez completada la refactorización, lassubclases restantes deberían convertirse en herederas de la clase en laque se colapsó la jerarquía.

– Pero tenga en cuenta que esto puede dar lugar a violaciones delprincipio de sustitución de Liskov. Por ejemplo, si su programa emulalas redes de transporte de la ciudad y accidentalmente colapsa lasuperclase Transporte en la subclase Coche, entonces la claseAvioneta puede convertirse en la heredera de Coche. ¡Oops!

• ¿Cómo Refactorizar de esta forma?– Seleccione qué clase es más fácil de eliminar: la superclase o su

subclase.

– Utilice Pull Up Field y Pull Up Method si decide deshacerse de lasubclase. Si eliges eliminar la superclase, opta por Push Down Field yPush Down Method.

– Reemplace todos los usos de la clase que está eliminando con la clasea la que se migrarán los campos y métodos. A menudo, esto serácódigo para crear clases, escritura de variables y parámetros, ydocumentación en comentarios de código.

– Elimina la clase vacía.



10) Form Template Method• Problema

– Sus subclases implementan algoritmos que contienen pasos similares en elmismo orden.

• Solución.– Mueva la estructura del algoritmo y los pasos idénticos a una superclase y

deje la implementación de los diferentes pasos en las subclases.

public abstract class Party { }

public class Person extends Party

{

private String firstName;

private String lastName;

private Date dob;

private String nationality;

public void printNameAndDetails()

{

System.out.println("Name: " + firstName + " " + lastName);

System.out.println("DOB: " + dob.toString() + ", Nationality: " + nationality);

}

}

public class Company extends Party

{


private String companyType;

private Date incorporated;

public void PrintNameAndDetails()

{

System.out.println("Name: " + name + " " + companyType);

System.out.println("Incorporated: " + incorporated.toString());

}

}



public abstract class Party

{

public void PrintNameAndDetails()

{

printName();

printDetails();

}

public abstract void printName();

public abstract void printDetails();

}

public class Person extends Party

{

private String firstName;

private String lastName;

private Date dob;

private String nationality;

public void printDetails()

{

System.out.println("DOB: " + dob.toString() + ", Nationality: " + nationality);

}

public void printName()

{

System.out.println("Name: " + firstName + " " + lastName);

}

}

public class Company extends Party

{


private String companyType;

private Date incorporated;

public void printDetails()

{

System.out.println("Incorporated: " + incorporated.toString());

}

public void printName()

{

System.out.println("Name: " + name + " " + companyType);

}

}

10) Form Template Methodimproved



10) Form Template Method• ¿Por qué Refactorizar de esta forma?

– Las subclases se desarrollan en paralelo, a veces por diferentespersonas, lo que conduce a la duplicación de código, errores ydificultades en el mantenimiento del código, ya que cada cambiodebe realizarse en todas las subclases.

• Beneficios

– La duplicación de código no siempre se refiere a simple casos decopiar / pegar. A menudo, la duplicación se produce en un nivelsuperior, como cuando tiene un método para ordenar números y unmétodo para ordenar colecciones de objetos que se diferenciansolo por la comparación de elementos. La aplciación de FormTemplate Method elimina esta duplicación al fusionar los pasos delalgoritmo compartido en una superclase y dejar solo las diferenciasen las subclases.

– Form Template Method es un ejemplo del principio abierto / cerradoen acción. Cuando aparece una nueva versión de algoritmo, solonecesita crear una nueva subclase; no se requieren cambios en elcódigo existente.



10) Form Template Method

• ¿Cómo Refactorizar de esta forma?– Divida los algoritmos en las subclases en sus partes

constituyentes descritas en métodos separados. Extract Methodpuede ayudar con esto.

– Los métodos resultantes que son idénticos para todas lassubclases se pueden mover a una superclase mediante Pull UpMethod.

– Los métodos no similares pueden recibir nombres consistentesa través de Rename Method.

– Mueva las firmas de métodos no similares a una superclasecomo abstractas utilizando Pull Up Method. Deje susimplementaciones en las subclases.

– Y finalmente, lleve el método principal del algoritmo a lasuperclase. Ahora debería funcionar con los pasos del métododescritos en la superclase, tanto reales como abstractos.



11) Replace Inheritance with Delegation

• Problema

– Tiene una subclase que usa solo una parte de los métodos de su

superclase (o no es posible heredar datos de superclase).

• Solución.

– Cree un campo y coloque un objeto de superclase en él, delegue

métodos al objeto de superclase y elimine la herencia.

Inverso de Replace Superclass with Delegate

class List {...} class Stack extends List {...}

class Stack { constructor() {

this._storage = new List(); }

} class List {...}



11) Replace Inheritance with Delegation

• ¿Por qué Refactorizar de esta forma?– Reemplazar la herencia con la composición puede mejorar

sustancialmente el diseño de la clase si:

• Su subclase viola el principio de sustitución de Liskov, es decir,si la herencia se implementó solo para combinar código común,pero no porque la subclase sea una extensión de la superclase.

• La subclase usa solo una parte de los métodos de lasuperclase. En este caso, es solo cuestión de tiempo antes deque alguien llame a un método de superclase al que se suponíaque no debía llamar.

– En esencia, esta técnica de refactorización divide ambas clasesy hace que la superclase sea la ayudante de la subclase, no supadre. En lugar de heredar todos los métodos de superclase, lasubclase tendrá solo los métodos necesarios para delegar enlos métodos del objeto de superclase.



11) Replace Inheritance with Delegation• Beneficios

– Una clase no contiene ningún método innecesario heredado dela superclase.

– Se pueden colocar varios objetos con diversasimplementaciones en el campo delegado. En efecto, obtienes elpatrón de diseño Strategy .

• Inconvenientes– Tienes que escribir muchos métodos de delegación sencillos.

• ¿Cómo Refactorizar de esta forma?– Cree un campo en la subclase para contener la superclase.

Durante la etapa inicial, coloque el objeto actual en él.

– Cambie los métodos de subclase para que utilicen el objeto desuperclase en lugar de this.

– Para los métodos heredados de la superclase que se llaman enel código del cliente, cree métodos de delegación simples en lasubclase.

– Elimine la declaración de herencia de la subclase.

– Cambie el código de inicialización del campo en el que sealmacena la superclase anterior creando un nuevo objeto.



12) Replace Delegation with Inheritance• Problema

– Una clase contiene muchos métodos simples que se delegan atodos los métodos de otra clase.

• Solución– Haga que la clase sea un heredero delegado, lo que hace que los

métodos de delegación sean innecesarios.

• ¿Por qué Refactorizar de esta forma?– La delegación es un enfoque más flexible que la herencia, ya que

permite cambiar cómo se implementa la delegación y colocar otrasclases allí también. No obstante, la delegación deja de serbeneficiosa si delega acciones a una sola clase y todos susmétodos públicos.

– En tal caso, si reemplaza la delegación con la herencia, limpia laclase de una gran cantidad de métodos de delegación y evita lanecesidad de crearlos para cada nuevo método de clase delegada.

• Beneficios– Reduce la longitud del código. Todos estos métodos de delegación

ya no son necesarios.



• Beneficios– No use esta técnica si la clase contiene delegación a solo

una parte de los métodos públicos de la clase delegada.Al hacerlo, violaría el principio de sustitución de Liskov.

– Esta técnica solo se puede usar si la clase aún no tienepadres.

• ¿Cómo Refactorizar de esta forma?– Haga de la clase una subclase de la clase delegada.

– Coloque el objeto actual en un campo que contenga unareferencia al objeto delegado.

– Elimine los métodos con delegación simple uno por uno.Si sus nombres eran diferentes, use Rename Method paradar a todos los métodos un solo nombre.

– Reemplace todas las referencias al campo delegado conreferencias al objeto actual.

– Elimina el campo de delegado.

12) Replace Delegation with Inheritance






• Organizing Data




REFACTORING TOOLS



Herramientas de refacturación automática

de código

• Disponible para todos los principaleslenguajes de programación (y lenguajes deprogramación OO en particular)

– Java : IntelliJ IDEA, Eclipse, NetBeans,JDeveloper, …

– JavaScript : WebStorm, Eclipse, …

– C++ : VisualStudio, Eclipse, …

– ObjectiveC and SWIFT : XCode

– .NET : VisualStudio

– Smalltalk, PHP, Ruby, Python, C#, Delphi, …



Limitaciones de la mayoría de las

herramientas de refactorización

• Solo soporte para refactorizaciones primitivas

– refactorizaciones de clases• add (sub)class to hierarchy, rename class, remove

class

– refactorizaciones de métodos• add to class, rename, remove, push down, pull up, add

parameter, move to component, extract code

– refactorizaciones de variables• add to class, rename, remove, push down, pull up,

create accessors, abstract variable

• A menudo, no hay soporte pararefactorizaciones de alto nivel.



Refactorización en Eclipse

• La herramienta de refactorización en Eclipse

admite una serie de transformaciones

descritas en el libro de Martin Fowler

• Se puede acceder a la refactorización a

través del menú Refactorización.

• Los comandos de refactorización también

están disponibles en los menús contextuales

en muchas vistas o aparecen como ayudas

rápidas.



Refactorizaciones soportadas en

Eclipse• Rename, Move, Change Method Signature

• Extract Method, Extract Local Variable, Extract Constant

• Inline, Move Type to New File, Use Supertype Where Possible

• Convert Anonymous Class to Nested, Convert Local Variable to Field

• Extract Superclass, Extract Interface, Extract Class

• Push Down, Pull Up, Encapsulate Field

• Introduce Parameter Object, Introduce Indirection

• Introduce Factory, Introduce Parameter

• Generalize Declared Type , Infer Generic Type Arguments

• (and more)



¡Advertencia necesaria!• Sepa lo que esta haciendo

• Si no se aplica bien, la refactorización puede disminuir la calidad en lugar de mejorarla

• Los "malos olores" son síntomas de que algo anda mal– Se supone que la refactorización elimina los "malos

olores"



¡Advertencia necesaria!

• La refactorización no debe introducir

nuevos “malos olores”



Siguiente sección: “code smells”

• “Bad Smells”

– Indicadores de que su código necesita ser

refactorizado

• Refactorización

– se trata de cómo cambiar el código

• Los Bad Smells se tratan de

– cuando modificar el código










– Code smells

• Detección de errores.




Code smells

• Bloaters

• Object-Orientation Abusers

• Change Preventers

• Dispensables

• Couplers

• Otros smells



Bloaters

• Los bloaters son códigos, métodosy clases que han aumentado aproporciones tan gigantescas quees difícil trabajar con ellos.

• Por lo general, estos olores nosurgen de inmediato, sino que seacumulan con el tiempo a medidaque evoluciona el programa…especialmente cuando nadie haceun esfuerzo por erradicarlos.



1) Long Method



1) Long Method

• Signos y síntomas: Método que contiene demasiadaslíneas de código. Generalmente, cualquier método demás de diez líneas debería ser sospechoso.

• Razones del problema: Se agrega algo a un método,pero nunca se quita nada. Dado que es más fácilescribir código que leerlo, este "olor" pasadesapercibido hasta que el método se convierte en unabestia fea y de gran tamaño.



1) Long Method

• Tratamiento: Como regla general, si siente lanecesidad de comentar algo dentro de un método,debe tomar este código y ponerlo en un nuevométodo.– Incluso una sola línea puede y debe dividirse en un

método separado, si requiere explicaciones. Y si elmétodo tiene un nombre descriptivo, nadie necesitarámirar el código para ver qué hace.



1) Long Method

• Para reducir la longitud del cuerpo de un método,utilice Extract Method.

• Si las variables y los parámetros locales interfierencon la extracción de un método, use. Replace Tempwith Query, Introduce Parameter Object o PreserveWhole Object

• Si ninguna de las recetas anteriores ayuda, intentemover todo el método a un objeto separado a travésde Replace Method with Method Object.

• Los operadores condicionales y los bucles son unabuena pista de que el código se puede mover a unmétodo separado. Para condicionales, useDecompose Conditional. Si hay bucles en el camino,pruebe el Extract Method.



1) Long Method

• Motivación– Entre todos los tipos de código orientado a objetos,

las clases con métodos cortos viven más tiempo.

– Cuanto más largo sea un método o función, más difícil será comprenderlo y mantenerlo.

– Además, los métodos largos ofrecen el escondite perfecto para el código duplicado no deseado.



1) Long Method

• Rendimiento

– ¿Un aumento en el número de métodos perjudica el rendimiento, como afirman muchas personas? En casi todos los casos, el impacto es tan insignificante que ni siquiera vale la pena preocuparse.

– Además, ahora que tiene un código claro y comprensible, es más probable que encuentre métodos realmente efectivos para reestructurar el código y obtener ganancias reales de rendimiento si alguna vez surge la necesidad.



2) Large Class



2) Large Class

• Signos y síntomas: – Una clase contiene muchos campos / métodos /

líneas de código.

• Razones del problema: – Las clases suelen comenzar en pequeñas

cantidades. Pero con el tiempo, se hinchan a medida que crece el programa.

– Como también ocurre con los métodos largos, los programadores generalmente encuentran mentalmente menos agotador colocar una nueva característica en una clase existente que crear una nueva clase para la característica.



2) Large Class

• Tratamiento:

– Extract Class ayuda si parte del comportamiento de la clase grande se puede dividir en un componente separado.

– Extract Subclass ayuda si parte del comportamiento de la clase grande se puede implementar de diferentes maneras o se usa en casos excepcionales.

– Extract Interface ayuda si es necesario tener una lista de las operaciones y comportamientos que el cliente puede usar.

– Si una clase grande es responsable de la interfaz gráfica, puede intentar mover algunos de sus datos y comportamiento a un objeto de dominio separado. Al hacerlo, puede ser necesario almacenar copias de algunos datos en dos lugares y mantener la coherencia de los datos. Duplicate Observed Data ofrece una forma de hacer esto.



2) Large Class

• Recompensa:– La refactorización de este tipo evita que los

desarrolladores tengan que recordar una gran cantidad de atributos para una clase.

– En muchos casos, dividir clases grandes en partes evita la duplicación de código y funcionalidad.



3) Primitive Obsession




• Signos y síntomas:– Uso de variables primitivas en lugar de objetos pequeños

para tareas simples (como moneda, rangos, cadenas especiales para números de teléfono, etc.)

– Uso de constantes para codificar información (como una constante USER_ADMIN_ROLE = 1 para referirse a usuarios con derechos de administrador).

– Uso de constantes de cadena como nombres de campo para su uso en matrices de datos.



3) Primitive Obsession• Razones del problema:

– Como la mayoría de los otros olores, las obsesiones porvariables primitivas nacen en momentos de debilidad. "¡Solo unavariable para almacenar algunos datos!" dijo el programador.Crear una variable primitiva es mucho más fácil que crear unaclase completamente nueva, ¿verdad? Y así se hizo. Luego senecesitó otro dato y se agregó de la misma manera. Por ello, laclase se volvió enorme y difícil de manejar.

– Las variables primitivas se utilizan a menudo para "simular"tipos. Entonces, en lugar de un tipo de datos separado, tiene unconjunto de números o cadenas que forman la lista de valorespermitidos para alguna entidad. A continuación, se asignannombres fáciles de entender a estos números y cadenasespecíficos mediante constantes, razón por la cual sedistribuyen ampliamente.

– Otro ejemplo de uso deficiente de primitiva es la simulación decampo. La clase contiene una gran variedad de datos diversos ylas constantes de cadena (que se especifican en la clase) seutilizan como índices de matriz para obtener estos datos.




• Tratamiento:– Si tiene una gran variedad de variables primitivas, es posible

agrupar lógicamente algunas de ellas en su propia clase. Aún mejor, mueva el comportamiento asociado con estos datos a la clase también. Para esta tarea, use Replace Data Value with Object.

– Si los valores de las variables primitivas se utilizan en los parámetros del método, use Introduce Parameter Object o Preserve Whole Object.

– Cuando se codifican datos complicados en variables, utilice Replace Type Code with Class, Replace Type Code with Subclasses o Replace Type Code with State/Strategy.

– Si hay matrices entre las variables, use Replace Array withObject.




• Recompensa:

– El código se vuelve más flexible gracias al uso deobjetos en lugar de variables primitivas.

– Mejor comprensión y organización del código. Lasoperaciones sobre datos particulares están en elmismo lugar, en lugar de estar dispersas. No másconjeturas sobre la razón de todas estas extrañasconstantes y por qué están en una matriz.

– Búsqueda más fácil de código duplicado.



4) Long Parameter List




• Signos y síntomas: Más de tres o cuatro parámetros para un método.

• Razones del problema:– Es posible que se genere una larga lista de

parámetros después de que se combinen varios tipos de algoritmos en un solo método. Es posible que se haya creado una lista larga para controlar qué algoritmo se ejecutará y cómo.



4) Long Parameter List• Razones del problema:

– Las listas de parámetros largas también pueden ser elresultado de los esfuerzos para hacer que las clases sean másindependientes entre sí.

• Por ejemplo, el código para crear objetos específicos necesarios enun método se movió del método al código para llamar al método,pero los objetos creados se pasan al método como parámetros.

• Por lo tanto, la clase original ya no conoce las relaciones entre losobjetos y la dependencia ha disminuido. Pero si se crean varios deestos objetos, cada uno de ellos requerirá su propio parámetro, loque significa una lista de parámetros más larga.

– Es difícil entender estas listas, que se vuelven contradictorias ydifíciles de usar a medida que se hacen más largas. En lugarde una larga lista de parámetros, un método puede utilizar losdatos de su propio objeto. Si el objeto actual no contiene todoslos datos necesarios, se puede pasar otro objeto (que obtendrálos datos necesarios) como parámetro de método.




• Tratamiento– Compruebe qué valores se pasan a los parámetros.

Si algunos de los argumentos son solo el resultado de llamadas a métodos de otro objeto, use Replace Parameter with Method Call. Este objeto se puede colocar en el campo de su propia clase o pasar como parámetro de método.

– En lugar de pasar un grupo de datos recibidos de otro objeto como parámetros, pase el objeto en sí al método utilizando Preserve Whole Object.

– Si hay varios elementos de datos no relacionados, a veces puede fusionarlos en un solo objeto de parámetro a través de Introduce Parameter Object.




• Recompensa:– Código más breve y legible.

– La refactorización puede revelar código duplicado previamente inadvertido.

• ¿Cuando ignorar?:– No se deshaga de los parámetros si hacerlo causaría una

dependencia no deseada entre clases.



5) Data Clumps



5) Data Clumps

• Signos y síntomas: A veces, diferentes partes del código contienen grupos idénticos de variables (como parámetros para conectarse a una base de datos). Estos grupos deben convertirse en sus propias clases.

• Razones del problema: – A menudo, estos grupos de datos se deben a una

estructura deficiente del programa o una "programación copypaste (copiar y pegar)".

– Si desea asegurarse de si algunos datos son o no un grupo de datos, simplemente elimine uno de los valores de datos y vea si los otros valores todavía tienen sentido. Si este no es el caso, es una buena señal de que este grupo de variables debe combinarse en un objeto.



5) Data Clumps

• Tratamiento:– Si los datos repetidos comprenden los campos de

una clase, use Extract Class para mover los campos a su propia clase.

– Si se pasan los mismos grupos de datos en los parámetros de los métodos, utilice Introduce Parameter Object para establecerlos como una clase.

– Si algunos de los datos se pasan a otros métodos, piense en pasar el objeto de datos completo al método en lugar de solo los campos individuales. Preserve Whole Object ayudará con esto.

– Mire el código utilizado por estos campos. Puede ser una buena idea mover este código a una clase de datos.



5) Data Clumps

• Recompensa:– Mejora la comprensión y la

organización del código. Las operaciones sobre datos particulares ahora se recopilan en un solo lugar, en lugar de hacerlo al azar en todo el código.

– Reduce el tamaño del código.

• ¿Cuando ignorar?:– Pasar un objeto completo en los

parámetros de un método, en lugar de pasar solo sus valores (tipos primitivos), puede crear una dependencia no deseada entre las dos clases.



Code smells

• Bloaters



• Dispensables

• Couplers

• Otros smells



Object-Orientation Abusers

• Todos estos olores son una aplicación

incompleta o incorrecta de los principios

de programación orientada a objetos.



1) Switch Statements(sentencias switch)



1) Switch Statements

• Signos y síntomas: Presencia de un operador switchcomplejo o una secuencia de instrucciones if.

• Razones del problema: – El uso relativamente raro de operadores switch y case es

uno de los sellos distintivos del código orientado a objetos. A menudo, el código switch puede estar disperso en diferentes lugares del programa. Cuando se agrega una nueva condición, debe encontrar todo el código switch y modificarlo.

– Como regla general, cuando vea switch, debe pensar en el polimorfismo.




• Tratamiento:– Para aislar el interruptor y colocarlo en la clase correcta, es

posible que necesite Extract Method y luego Move Method.

– Si un switch se basa en tipos de código, como cuando se cambia el modo de ejecución del programa, use Replace Type Code with Subclasses o Replace Type Code with State/Strategy.

– Después de especificar la estructura de herencia, use ReplaceConditional with Polymorphism.

– Si no hay demasiadas condiciones en el operador y todos llaman al mismo método con diferentes parámetros, el polimorfismo será superfluo. En este caso, puede dividir ese método en varios métodos más pequeños con Replace Parameter with Explicit Methods y cambie el switch en consecuencia.

– Si una de las opciones condicionales es nula, utilice Introduce Null Object.




class Animal {final int MAMMAL = 0, BIRD = 1, REPTILE = 2;int myKind; // set in constructor...String getSkin() {

switch (myKind) {case MAMMAL: return "hair";case BIRD: return "feathers";case REPTILE: return "scales";default: return “skin";

}}

}




class Animal {String getSkin() { return “skin"; }

}

class Mammal extends Animal {String getSkin() { return "hair"; }

}

class Bird extends Animal {String getSkin() { return "feathers"; }

}

class Reptile extends Animal {String getSkin() { return "scales"; }

}

improved




• Agregar un nuevo tipo de animal, como Amphibian,no requiere revisar y recompilar el código existente.

• Es probable que los mamíferos, las aves y losreptiles se diferencien de otras formas, y ya loshemos separado (por lo que no necesitaremos másdeclaraciones de cambio)

• Nos hemos deshecho de las banderas quenecesitábamos para distinguir un tipo de animal deotro

• Ahora usamos los Objetos de la forma en quedeben usarse

improved




• Recompensa: Organización mejorada del código.

• ¿Cuando ignorar?: – Cuando un operador switch realiza acciones simples, no

hay razón para realizar cambios en el código.

– A menudo, los patrones de diseño de fábrica utilizan operadores switch (Factory Method o Abstract Factory) para seleccionar una clase creada.



2) Temporary Field(campos temporales)



2) Temporary Field• Signos y síntomas:

– Los campos temporales obtienen sus valores (y, por lo tanto, los objetos los necesitan) solo bajo determinadas circunstancias. Fuera de estas circunstancias, están vacías.

• Razones del problema: – A menudo, los campos temporales se crean

para su uso en un algoritmo que requiere una gran cantidad de entradas. Entonces, en lugar de crear una gran cantidad de parámetros en el método, el programador decide crear campos para estos datos en la clase. Estos campos se usan solo en el algoritmo y no se usan el resto del tiempo.

– Este tipo de código es difícil de entender. Uno esperaría ver datos en los campos de objeto, pero por alguna razón, casi siempre están vacíos.



2) Temporary Field

• Tratamiento: – Los campos temporales y todo el código que opera en ellos se

pueden colocar en una clase separada a través de ExtractClass. En otras palabras, está creando un objeto de método, logrando el mismo resultado que si realizara Replace Method with Method Object.

– Use Introduce Null Object e intégrelo en lugar del código condicional que se utilizó para verificar la existencia de los valores de campo temporal.

• Recompensa:– Mejor organización y claridad del código.



3) Refused Bequest(legado rechazado)



3) Refused Bequest

• Signos y síntomas: Si una subclase usa solo algunos de los métodos y propiedades heredados de sus padres, la jerarquía está fuera de lugar. Los métodos innecesarios pueden simplemente no utilizarse o redefinirse y dar lugar a excepciones.

• Razones del problema: Alguien estaba motivado a crear herencia entre clases solo por el deseo de reutilizar el código en una superclase. Pero la superclase y la subclase son completamente diferentes.



3) Refused Bequest

• Tratamiento:– Si la herencia no tiene sentido y la subclase realmente no

tiene nada en común con la superclase, elimine la herencia a favor de Replace Inheritance with Delegation.

– Si la herencia es apropiada, elimine los campos y métodos innecesarios en la subclase. Extraiga todos los campos y métodos necesarios para la subclase de la clase principal, colóquelos en una nueva subclase y configure ambas clases para heredar de ella (Extract Superclass).

• Recompensa:– Mejora la claridad y la organización del código. Ya no

tendrá que preguntarse por qué la clase Perro se hereda de la clase Silla (aunque ambas tienen 4 patas).



4) Alternative Classes with Different

Interfaces(Clases alternativas con diferentes interfaces)



4) Alternative Classes with Different Interfaces

• Signos y síntomas: Dos clases realizanfunciones idénticas pero tienen nombres demétodos diferentes.

• Razones del problema: El programador que creóuna de las clases probablemente no sabía que yaexistía una clase funcionalmente equivalente.




• Tratamiento: Intente poner la interfaz de clases en términos de un denominador común:– Cambie el nombre de los métodos para que sean

idénticos en todas las clases alternativas.

– Use Move Method, Add Parameter y ParameterizeMethod para hacer que la firma y la implementación de los métodos sean iguales.

– Si solo se duplica una parte de la funcionalidad de las clases, intente utilizar Extract Superclass. En este caso, las clases existentes se convertirán en subclases.

– Una vez que haya determinado qué método de tratamiento usar y lo haya implementado, es posible que pueda eliminar una de las clases.




• Recompensa:– Elimina el código duplicado innecesario, lo que hace que

el código resultante sea menos voluminoso.

– El código se vuelve más legible y comprensible (ya no tiene que adivinar el motivo de la creación de una segunda clase que realiza exactamente las mismas funciones que la primera).

• ¿Cuando ignorar?– A veces, fusionar clases es imposible o tan difícil que no

tiene sentido. • Un ejemplo es cuando las clases alternativas están en

diferentes bibliotecas y cada una tiene su propia versión de la clase.



Code smells

• Bloaters



• Dispensables

• Couplers

• Otros smells



Change Preventers

• Estos olores significan que si necesita cambiaralgo en un lugar de su código, también deberealizar muchos cambios en otros lugares.

• Como resultado, el desarrollo de programas sevuelve mucho más complicado y costoso.



1) Divergent Change(Cambio divergente)



1) Divergent Change

• Signos y síntomas: Te encuentras teniendo quecambiar muchos métodos no relacionados cuandorealizas cambios en una clase. Por ejemplo, alagregar un nuevo tipo de producto, debe cambiar losmétodos para buscar, mostrar y pedir productos.

• Razones del problema: A menudo, estasmodificaciones divergentes se deben a una estructuradeficiente del programa o una "programacióncopypaste".



1) Divergent Change

• Tratamiento:– Divida el comportamiento de la clase a través de Extract

Class.

– Si diferentes clases tienen el mismo comportamiento, esposible que desee combinar las clases a través de laherencia (Extract Superclass y Extract Subclass).

• Recompensa:– Mejora la organización del código.

– Reduce la duplicación de código.

– Simplifica el soporte.



2) Shotgun Surgery(Cirugía de escopeta)



2) Shotgun Surgery

• Signos y síntomas: Realizar modificaciones requiere que realice muchos cambios pequeños en muchas clases diferentes.

• Razones del problema: Se ha dividido una sola responsabilidad entre un gran número de clases. Esto puede suceder después de una aplicación excesiva de Divergent Change.



¡Aclaración!

Shotgun Surgery se asemeja a Divergent Change, pero en realidad es el olor opuesto. Divergent

Change es cuando se realizan muchos cambios en una sola clase. Shotgun Surgery se refiere a cuando

se realiza un solo cambio en varias clases simultáneamente.



2) Shotgun Surgery

• Tratamiento:– Utilice Move Method y Move Field para mover los

comportamientos de clase existentes a una solaclase. Si no hay una clase apropiada para esto, creeuna nueva.

– Si mover el código a la misma clase deja las clasesoriginales casi vacías, intente deshacerse de estasclases ahora redundantes a través de Inline Class.

• Recompensa:– Mejor organización.

– Menos duplicación de código.

– Mantenimiento más sencillo.



3) Parallel Inheritance Hierarchies(Herencia jerárquica paralela)



3) Parallel Inheritance Hierarchies

• Signos y síntomas: Siempre que crea una subclase para una clase, necesita crear una subclase para otra clase.

• Razones del problema: Todo iba bien mientras la jerarquía se mantuviera pequeña. Pero con la adición de nuevas clases, hacer cambios se ha vuelto cada vez más difícil.

• Tratamiento: Puede eliminar los duplicados de las jerarquías de clases paralelas en dos pasos. – Primero, haga que las instancias de una jerarquía se refieran a

instancias de otra jerarquía.

– Luego, elimine la jerarquía en la clase a la que se hace referencia, utilizando Move Method y Move Field.



3) Parallel Inheritance Hierarchies

• Recompensa:– Reduce la duplicación de código.

– Puede mejorar la organización del código.

• ¿Cuando ignorar? – A veces, tener jerarquías de clases paralelas es solo una forma

de evitar un lío aún mayor con la arquitectura del programa.

– Si encuentra que sus intentos de eliminar los duplicados de las jerarquías producen un código aún más feo, simplemente dé un paso hacia atrás, revierta todos sus cambios y acostúmbrese a ese código.



Code smells

• Bloaters



• Dispensables

• Couplers

• Otros smells



Dispensables

• Un prescindible (Dispensable) es algo

inútil e innecesario cuya ausencia haría el

código más limpio, más eficiente y más

fácil de entender.



1) Comments



1) Comments

• Signos y síntomas: – Un método está lleno de comentarios explicativos.

• Razones del problema: – Los comentarios generalmente se crean con la mejor de las

intenciones, cuando el autor se da cuenta de que su código no es intuitivo ni obvio. En tales casos, los comentarios son como un desodorante que enmascara el olor a código a pescado que podría mejorarse.

– El mejor comentario es un buen nombre para un método o una clase.

– Si cree que un fragmento de código no se puede entender sin comentarios, intente cambiar la estructura del código de manera que los comentarios sean innecesarios.



1) Comments

• Tratamiento:

– Si un comentario pretende explicar una expresión compleja, la expresión debe dividirse en subexpresiones comprensibles mediante Extract Variable.

– Si un comentario explica una sección de código, esta sección se puede convertir en un método separado a través del ExtractMethod. Lo más probable es que el nombre del nuevo método se pueda tomar del texto del comentario en sí.

– Si ya se ha extraído un método, pero aún son necesarios comentarios para explicar qué hace el método, utilice un nombre que se explique por sí mismo. Utilice el Rename Method para esto.

– Si necesita establecer reglas sobre un estado que sea necesario para que el sistema funcione, utilice Introduce Assertion.



1) Comments

• Recompensa:– El código se vuelve más intuitivo y obvio.

• ¿Cuando ignorar? Los comentarios a veces pueden serútiles:– Al explicar por qué se está implementando algo de una manera

particular.

– Al explicar algoritmos complejos (cuando todos los demás métodospara simplificar el algoritmo se han probado y se quedan cortos).



2) Código duplicado




• Signos y síntomas: Dos fragmentos de código parecen casi idénticos.

• Razones del problema:– La duplicación suele ocurrir cuando varios programadores

están trabajando en diferentes partes del mismo programa al mismo tiempo. Dado que están trabajando en diferentes tareas, es posible que no sepan que su colega ya ha escrito un código similar que podría reutilizarse para sus propias necesidades.




• Razones del problema:– También hay una duplicación más sutil, cuando

partes específicas del código se ven diferentes pero en realidad realizan el mismo trabajo. Este tipo de duplicación puede ser difícil de encontrar y corregir.

– A veces, la duplicación tiene un propósito. Cuando se apresura a cumplir con los plazos y el código existente es "casi adecuado" para el trabajo, es posible que los programadores novatos no puedan resistir la tentación de copiar y pegar el código relevante. Y en algunos casos, el programador es simplemente demasiado vago para despejar el desorden.




• Tratamiento:

– Si se encuentra el mismo código en dos o más métodos

de la misma clase: use Extract Method y realice llamadas

para el nuevo método en ambos lugares.

– Si el mismo código se encuentra en dos subclases del

mismo nivel:• Utilice Extract Method para ambas clases, seguido de Pull Up Field

para los campos utilizados en el método que está extrayendo.

• Si el código duplicado está dentro de un constructor, use Pull Up

Constructor Body.

• Si el código duplicado es similar pero no completamente idéntico, use

Form Template Method.

• Si dos métodos hacen lo mismo pero usan algoritmos diferentes,

seleccione el mejor algoritmo y aplique Substitute Algorithm.



2) Código duplicado• Tratamiento:

– Si se encuentra código duplicado en dos clases diferentes:

• Si las clases no forman parte de una jerarquía, utilice ExtractSuperclass para crear una sola superclase para estas clasesque mantenga toda la funcionalidad anterior.

• Si es difícil o imposible crear una superclase, use Extract Classen una clase y use el nuevo componente en la otra.

• Si una gran cantidad de expresiones condicionales estánpresentes y ejecutan el mismo código (diferenciándose solo ensus condiciones), combine estos operadores en una solacondición usando Consolidate Conditional Expression y useExtract Method para colocar la condición en un métodoseparado con un nombre que facilite su entendimiento.

– Si se realiza el mismo código en todas las ramas de unaexpresión condicional: coloque el código idéntico fuera delárbol de condiciones mediante Consolidate DuplicateConditional Fragments.




• Recompensa:– La combinación de código duplicado simplifica la

estructura de su código y lo hace más corto.

– Simplificación + brevedad = código que es más fácil desimplificar y más económico de soportar.

• ¿Cuando ignorar?– En casos muy raros, la combinación de dos fragmentos

idénticos de código puede hacer que el código sea menosintuitivo y obvio.



3) Lazy Class



3) Lazy Class

• Signos y síntomas: – Comprender y mantener las clases siempre cuesta tiempo

y dinero. Entonces, si una clase no hace lo suficiente para llamar su atención, debe eliminarse.

• Razones del problema: – Quizás una clase fue diseñada para ser completamente

funcional, pero después de algunas de las refactorizaciones, se ha vuelto ridículamente pequeña.

– O quizás fue diseñado para respaldar el trabajo de desarrollo futuro que nunca se llevó a cabo.



3) Lazy Class

• Tratamiento:– Los componentes que son casi inútiles deben recibir el

tratamiento de Inline Class.

– Para subclases con pocas funciones, pruebe CollapseHierarchy.

• Recompensa:– Tamaño de código reducido.

– Mantenimiento más sencillo.

• ¿Cuando ignorar? A veces, se crea una Lazy Classpara delinear intenciones para el desarrollo futuro. En este caso, intente mantener un equilibrio entre la claridad y la simplicidad en su código.



4) Data Class



4) Data Class

• Signos y síntomas:– Una Data Class se refiere a una clase que contiene solo campos

y métodos burdos para acceder a ellos (getters and setters).Estos son simplemente contenedores de datos utilizados porotras clases.

– Estas clases no contienen ninguna funcionalidad adicional y nopueden operar de forma independiente con los datos queposeen.

• Razones del problema:– Es algo normal cuando una clase recién creada contiene solo

unos pocos campos públicos (y tal vez incluso un puñado degetters / setters).

– Pero el verdadero poder de los objetos es que pueden contenertipos de comportamiento u operaciones en sus datos.



4) Data Class

• Tratamiento:– Si una clase contiene campos públicos, use Encapsulate Field

para ocultarlos del acceso directo y requiera que el acceso serealice solo a través de getters y setters.

– Utilice Encapsulate Collection para los datos almacenados encolecciones (como matrices).

– Revise el código de cliente que usa la clase. En él, puedeencontrar una funcionalidad que estaría mejor ubicada en laclase de datos en sí. Si este es el caso, utilice Move Method yExtract Method para migrar esta funcionalidad a la clase dedatos.

– Después de que la clase se haya llenado con métodos bienpensados, es posible que desee deshacerse de los métodosantiguos para el acceso a los datos que brindan un accesodemasiado amplio a los datos de la clase. Para ello, puedenresultar útiles Remove Setting Method y Hide Method.



4) Data Class

• Recompensa:

– Mejora la comprensión y la organización del código.

Las operaciones sobre datos particulares ahora se

recopilan en un solo lugar, en lugar de hacerlo al azar

en todo el código.

– Le ayuda a detectar la duplicación del código del

cliente.



5) Dead Code



5) Dead Code

• Signos y síntomas:– Ya no se usa una variable, parámetro, campo, método o

clase (generalmente porque es obsoleto).

• Razones del problema:– Cuando los requisitos del software han cambiado o se han

realizado correcciones, nadie ha tenido tiempo de limpiarel código antiguo.

– Dicho código también se puede encontrar encondicionales complejos, cuando una de las ramas sevuelve inalcanzable (debido a un error u otrascircunstancias).



5) Dead Code• Tratamiento: La forma más rápida de encontrar

código inactivo es utilizar un buen IDE.– Elimine el código no utilizado y los archivos innecesarios.

– En el caso de una clase innecesaria, se puede aplicar Inline Class o Collapse Hierarchy si se usa una subclase o superclase.

– Para eliminar parámetros innecesarios, utilice RemoveParameter.

• Recompensa:– Tamaño de código reducido.

– Soporte más sencillo.



6) Speculative Generality




• Signos y síntomas: – Hay una clase, método, campo o parámetro no utilizado.

• Razones del problema: – A veces, el código se crea "por si acaso" para admitir

características futuras anticipadas que nunca se implementan.

– Como resultado, el código se vuelve difícil de entender y soportar.




• Tratamiento:– Para eliminar clases abstractas no utilizadas, pruebe

Collapse Hierarchy.

– La delegación innecesaria de funcionalidad a otra clase sepuede eliminar a través de Inline Class.

– ¿Métodos no utilizados? Utilice Inline Method paradeshacerse de ellos.

– Los métodos con parámetros no utilizados debenrevisarse con la ayuda de Remove Parameter.

– Los campos no utilizados se pueden eliminarsimplemente.




• Recompensa:– Código más delgado.

– Soporte más sencillo.

• ¿Cuando ignorar?– Si está trabajando en un framework, es

eminentemente razonable crear una funcionalidad que no se use en el framework en sí, siempre que los usuarios de los framework necesiten la funcionalidad.

– Antes de eliminar elementos, asegúrese de que no son utilizados en pruebas unitarias. Esto sucede si las pruebas necesitan una forma de obtener cierta información interna de una clase o realizar acciones especiales relacionadas con las pruebas.



Code smells

• Bloaters



• Dispensables

• Couplers

• Otros smells



Couplers

• Todos los olores de este grupo contribuyen aun acoplamiento excesivo entre clases omuestran lo que sucede si el acoplamientose reemplaza por una delegación excesiva.

Modulo

A

Modulo

D

Modulo

B

Modulo

C

Area de Data Compartida

Alto Acoplamiento



1) Feature Envy



1) Feature Envy

• Signos y síntomas– Un método accede a los datos de otro objeto más

que a sus propios datos.

• Razones del problema– Este olor puede ocurrir después de que los campos

se muevan a una clase de datos. Si este es el caso, es posible que también desee mover las operaciones sobre datos a esta clase.



1) Feature Envy

• Tratamiento

– Como regla básica, si las cosas cambian al mismo tiempo, debes mantenerlas en el mismo lugar. Por lo general, los datos y las funciones que utilizan estos datos se cambian juntos (aunque es posible que existan excepciones).

– Si un método claramente debe trasladarse a otro lugar, utilice Move Method.

– Si solo una parte de un método accede a los datos de otro objeto, utilice Extract Method para mover la parte en cuestión.

– Si un método usa funciones de varias otras clases, primero determine qué clase contiene la mayoría de los datos usados. Luego, coloque el método en esta clase junto con los demás datos. Alternativamente, use ExtractMethod para dividir el método en varias partes que se pueden colocar en diferentes lugares en diferentes clases.



1) Feature Envy

• Recompensa:– Menos duplicación de código (si el código de manejo de

datos se coloca en un lugar central).

– Mejor organización del código (los métodos para manejardatos están al lado de los datos reales).

• ¿Cuando ignorar?– A veces, el comportamiento se mantiene a propósito

separado de la clase que contiene los datos. La ventajahabitual de esto es la capacidad de cambiardinámicamente el comportamiento (consulte Strategy,Visitor y otros patrones).



2) Inappropriate Intimacy




• Signos y síntomas– Una clase usa los campos y métodos internos de otra

clase.

• Razones del problema– Esté atento a las clases que pasan demasiado

tiempo juntas. Las buenas clases deben saber lomenos posible unas de otras. Estas clases son másfáciles de mantener y reutilizar.




• Tratamiento:– La solución más simple es usar Move

Method y Move Field para mover partes de una clase a la clase en la que se usan esas partes. Pero esto solo funciona si la primera clase realmente no necesita estas piezas.

– Otra solución es usar Extract Class y Hide Delegate en la clase para hacer que las relaciones de código sean “oficiales”.

– Si las clases son mutuamente interdependientes, debe usar Change Bidirectional Association toUnidirectional.

– Si esta "intimidad" está entre una subclase y la superclase, considere Replace Delegation with Inheritance.




• Recompensa:

– Mejora la organización del código.

– Simplifica el soporte y la reutilización del código.



3) Message Chains



3) Message Chains

• Signos y síntomas– En el código, ve una serie de llamadas que se asemejan a

$ a-> b () -> c () -> d ()

• Razones del problema– Una cadena de mensajes ocurre cuando un cliente solicita

otro objeto, ese objeto solicita otro, y así sucesivamente.

– Estas cadenas significan que el cliente depende de la navegación a lo largo de la estructura de clases.

– Cualquier cambio en estas relaciones requiere modificar al cliente.



3) Message Chains

• Tratamiento– Para eliminar una cadena de

mensajes, use Hide Delegate.

– A veces es mejor pensar en por qué se utiliza el objeto final. Quizás tenga sentido usar el ExtractMethod para esta funcionalidad y moverlo al principio de la cadena, utilizando Move Method.

• Recompensa:– Reduce las dependencias entre

clases de una cadena.

– Reduce la cantidad de código hinchado.



3) Message Chains

• ¿Cuando ignorar?

– La ocultación de delegados demasiado

agresiva puede provocar un código en el que

sea difícil ver dónde se está produciendo

realmente la funcionalidad. Dicho de otra

forma, hay que “evitar también el olor de

Middle Man”.



4) Middle Man



4) Middle Man

• Signos y síntomas– Si una clase realiza solo una acción, delegando el trabajo a otra

clase, ¿por qué existe?

• Razones del problema– Este olor puede ser el resultado de una eliminación excesiva de

las cadenas de mensajes.

– En otros casos, puede ser el resultado del trabajo útil de una clase que se traslada gradualmente a otras clases. La clase permanece como un caparazón vacío que no hace nada más que delegar.

• Tratamiento– Si la mayoría de las clases de un método se delegan en otra

clase, Remove Middle Man está en orden.



4) Middle Man

• Recompensa:– Código menos voluminoso.

• ¿Cuando ignorar?– No elimine al intermediario que se haya creado por

un motivo:• Es posible que se haya agregado un intermediario para

evitar dependencias entre clases.

• Algunos patrones de diseño crean intermediarios a propósito (como Proxy o Decorator).



Code smells

• Bloaters



• Dispensables

• Couplers

• Otros smells



Incomplete Library Class

• Signos y síntomas: Tarde o temprano, las bibliotecasdejan de satisfacer las necesidades de los usuarios.La única solución al problema, cambiar la biblioteca, amenudo es imposible, ya que la biblioteca es de sololectura.

• Razones del

problema: El autor de

la biblioteca no le ha

proporcionado las

funciones que necesita

o se ha negado a

implementarlas.



Incomplete Library Class

• Tratamiento– Para introducir algunos métodos en una clase de biblioteca,

utilice Introduce Foreign Method.

– Para grandes cambios en una biblioteca de clases, use Introduce Local Extension.

• Recompensa:– Reduce la duplicación de código (en lugar de crear su propia

biblioteca desde cero, aún puede aprovechar una existente).

• ¿Cuando ignorar?– La extensión de una biblioteca puede generar trabajo adicional

si los cambios en la biblioteca implican cambios en el código.









Unidad 1A



PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES

Unidad 1A

Final de la Unidad 1A

http://creativecommons.org/licenses/by-nc-sa/3.0/

CSO Unidad 1A PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES

Technology

Transcript of CSO Unidad 1A PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES