Embed Size (px)
Citation preview
Principios de Reestructuración
M.C. Juan Carlos Olivares [email protected]
http://antares.itmorelia.edu.mx/~jcolivar/[email protected]
@jcolivares
Febrero 2010
• Específica: conoce los términos básicos de la reestructuración de código e identifica el problema de código mal desarrollado en el contexto de desarrollo de software.
• Genéricas
• Instrumentales: Capacidad de análisis y síntesis, Solución de problemas, Toma de decisiones.
Competencias
• Interpersonales: Capacidad crítica y autocrítica, Capacidad de trabajar en equipo interdisciplinario, Habilidad para trabajar en un ambiente laboral, Compromiso ético.
• Sistémicas: Capacidad de aprender, Capacidad de adaptarse a nuevas situaciones, Capacidad de generar nuevas ideas (creatividad), Habilidad para trabajar en forma autónoma, Preocupación por la calidad.
Competencias
• Condiciones de la reestructuración
• Reestructuración y Diseño
• Reestructuración y desempeño
• Origen de la Reestructuración
Temario
• 30% Prácticas
• 10% Otras actividades en el aula
• 60% Actividad de Evaluación Integral (Teórico-Práctico)
Evidencias
• Descargar el código fuente de la página Web denominado Fecha.zip. Dicho archivo comprimido consta de dos clases: Fecha y validaFecha.
• Realizar un diagrama de clases de todo el sistema antes de modificar y uno después de haber cocnluído todas las reestructuraciones.
• Se enviará por correo todo el proyecto.
Actividad
• Esta práctica de laboratorio cuenta para la unidad 1.
• Refactoriza el nombre de todos los identificadores (paquetes, clases, atributos, métodos y variables) para que cumplan con el estándar de codificación “Camello Húngaro” visto en clase.
• En el caso de paquetes se sigue la convención de nombres de dominios al revés.
Laboratorio 3
• En nuestro caso el paquete deberá comenzar con mx.edu.itmorelia y el nombre actual del paquete.
• ¿Porqué se sigue esta convención en el nombre de paquetes?
• Para hacerlo realmente útil al momento de exportarlos a nivel de API.
• Si no existe la convección de notación se deberá indicar el prefijo utilizado.
Laboratorio 3
• Una vez realizado el renombrado de modificadores se proseguirá con la detección de “malos olores” en el código vistos y no vistos en clase.
• Se deberá documentar el por que hicieron los cambios y en donde se encontraban en forma de reporte indicando el antes y después así como el nombre de la refactorización utilizada.
Laboratorio 3
• Nombre de la Refactorización: Números mágicos
• Localización: Archivo.java líneas x-y• Código fuente: listado de código• Código reestructurado: cómo queda el
código modificado.
• Pueden utilizar un procesador de textos o bien indicarlo en el código fuente.
Laboratorio 3
• El software evoluciona constantemente…Condiciones reestructuración
EL PROBLEMAEL PROBLEMA
Ciclo de Ciclo de DesarrolloDesarrollo
20%
MantenimientoMantenimientoDepuración
+Extender
Funcionalidad
80%
Valor ($$) del Mantenimiento
Confiabilidad del Aplicativo
Tiempo de Vida útil
Nivel de Mantenibilidad
Buenas Prácticas de Diseño y Codificación
¿Cómo detectarlas?¿Cómo medirlas?
Detección de Malas Prácticas de Diseño o Codificación
• La refactorización es el arte de mejorar de manera segura, el diseño de código existente.
• Esto tiene algunas implicaciones:– La Refactorización no solo incluye hacer
cambios en un sistema. – Refactorización no es reescribir todo desde
cero.– Refactorización no es cualquier
reestructuración pensada para mejorar código.
Reestructuración y Diseño
• Los “smells” en el código son señales de alerta respecto a problemas potenciales en el código. No todos los smells indican un problema, pero la mayoría son dignas de un vistazo y una decisión.
• Los “smells” usualmente describen problemas localizados en algún lugar. Es cómo la analogía de un refrigerador… si algo huele mal posiblemente esté mal.
Reestructuración y desempeño
• El origen de la reestructuración se da una vez construido código, no se puede aplicar refactoring si previamente no hay código.
• Se pueden aplicar buenas prácticas de codificación desde el inicio, pero siendo puritanos realmente esto no es refactoring.
• Una vez detectado “malos olores”, se deben de priorizar y comenzar por aquel olor que es el más fuerte.
Origen de la Reestructuración
• Se detecta una refactroización apropiada para el smell, se aplica y se observa que los cambios realizados sigan cumpliendo con las restricciones del software.
• Se sugiere que se realicen transformaciones seguras. A continuación se verá el proceso de aplicar una reestructuración ya conocida por nostros: “Encpasulate Field”.
Origen de la Reestructuración
• El objetivo de esta reestructuración es hacer que los objetos no puedan acceder a los atributos de una clase de manera directa sino a través de métodos para acceder a los campos.
• Los pasos a seguir son:
• Crear los méodos get y set para cada atributo que se desea acceder.
Encapsulate Field
• Localizar todas las referencias y reemplazar todos los accesos a los campos con los métodos get y todas las asignaciones con set.
• Compilar y cambiar después de cada referencia.
• Declarar el campo como privado.
• Compilar y probar.
Encapsulate Field
• Las herramientas automatizadas de refactoring como la incluida en NetBeans realizan estos pasos de manera segura.
• Inicialmente se tiene el código:public class Persona { public String name}
• En el caso de prueba unitaria se tiene:
Encapsulate Field
Person person;person.name = “Juan Pérez”;assertEquals(“Juan Pérez”, person.name);• Después se aplica el paso 1 (crear
métodos get y set):public class Person {public String name;public String getName() {return name;}public String setName(String NewName){ name=NewName;}
Encapsulate Field
• Ahora se aplica el paso 2: Encontrar todos los clientes; reemplazar referencias con llamadas. Se modifica la primera referencia.
• Antes: person.name = “Juan Pérez”;• Después: person.setName(“Juan Pérez”);
• Se compila y prueba. Ahora se sigue con la reestructuración de la siguiente referencia:
Encapsulate Field
• Antes: assertEquals( “Juan Pérez”, person.name);
• Después: assertEquals( “Juan Pérez”, person.getName());
• Se compila y vuelve a probar. Una vez que se ha probado que funciona se sigue el paso 4 de hacer privado el campo:
public class Person{ private String name;……}
Encapsulate Field
• Realiza las siguientes reestructuraciones en el código anterior:
• Empaqueta los códigos fuentes en el espacio de nombres llamado reestructuración.
• Sube todas las variables usadas en el método main() de la clase Fecha como atributos de las clase, las cuales serán privados y no deberán ser estáticos.
Actividad
• Realiza un constructor sin parámetros para inicializar los atributos del paso anterior (recuerda que para que se ejecute el constructor se debe crear el objeto).
• No se recomienda que el método main() lance excepciones por lo que habrá que modificar el método para que caché la excepción.
Actividad
• No se recomienda construir un objeto apartir de construir un objeto directamente como es el caso del objeto derivado de BufferedReader por lo que se recomienda separarlo en dos objetos diferentes.
• Sólo utilizar un objeto validaFecha en el método main().
Actividad
• Demasiada indirección es mala. Modificar el método valida() de la clase validaFecha para que su funcionalidad se encuentre en el constructor de la clase. Nótese que esta refactroización implica el cambio en la clase Fecha.
• Cambie todas los números mágicos de la clase valida Fecha por constantes.
Actividad
• En las condicionales del método valida() realizar el refactoring de introducir variables de explicación.
• En el método imprime, atrapar la posible excepción que puede ocasionar los métodos de conversión parseInt. No utilizar la clase genérica Exception.
Actividad
• Problema: el código de un método tiene una asignación a un parámetro.
• Solución: usar una variable temporal.
• Motivo: no tiene nada de malo, el problema es que causa mucha confusión para entender si un parámetro se pasa por valor o por referencia.
• Java utiliza solamente paso por valor.
Remover Asignación Parámetros
Remover Asignación Parámetros
• Problema: hay un método largo que usa variables locales de tal forma que no es posible aplicar “Extraer Método”.
• Solución: convertir el método en un objeto, de modo que todas las variables locales sean a tributos de dicho objeto. A continuación se puede descomponer el método en varios métodos del mismo objeto.
Reemplazar Mét. por Obj. Mét.
Reemplazar Mét. por Obj. Mét.
• Problema: se quiere cambiar un algoritmo por otro que es más claro y/o eficiente.
• Solución: cambiar el cuerpo del método por el nuevo algoritmo.
Substitución de Algoritmo
Substitución de Algoritmo
• Las metodologías ágiles que basan el desarrollo en primero entregar soluciones que documentación recomiendan realizar reestructuración de códigos en todo momento.
• En estas metodologías primero se programa y se verifica que se cumpla con las pruebas unitarias. Una vez pasadas las pruebas se debe de refactorizar el código generado.
Refactoring Ágil
• Realizar una aplicación agenda de directorios en donde se pueden tener Amigos, Familia y Servicios.
• Cada categoría puede tener un arreglo de objetos donde cada objeto tiene un nombre y un teléfono. Esta clase tiene los métodos de capturar() para pedir datos a los usuarios y buscar() para encontrar los datos de los objetos.
• Su entregable no debe de tener malos olores.
Actividad
• Refactoring aplicables:
• En la clase Autobuses se puede aplicar el refactoring de extraer el método hay mucho código repetido (del switch no nos salvamos). Se tiene muchas depencias en cuestión de las líneas que son estáticas (4) y que quizás en un futuro pudieran ser variables (Aplicar Refactoring para mejora).
Práctica 3
• La clase boletos no tiene razón de ser.
• Están mezclado la lógica de aplicación y la presentación en cada una de las clases (Aplicar Modelo-Vista-Controlador).
• El refactoring de nombre de variables (que aplicaron) en las GUIs es de suma importancia. También se recomienda cambiar el nombre de los manejadores de eventos: ¿qué hace de la clase línea jButton15ActionPerformed()?
Práctica 3
• En algunas condicionales se puede aplicar el refactoring de introducir variable de explicación.
• No se tiene un sangrado adecuado de las líneas de código.
Práctica 3
• Una de las decisiones fundamentales en el diseño orientado a objetos es dónde poner las responsabilidades. Puesto que es casi imposible hacerlo bien a la primera, las siguientes refactorizaciones nos ayudarán a lidiar con este problema.
• La refactorización más básica es mover el método de una clase a otra. Esto se debe de hacer sólo cuando el método utiliza más funcionalidad de otra clase diferente a la que lo contiene
Mover Funcionalidad / Objetos
• El método de la clase original de preferencia debe desaparecer o bien hacer referencia al de la nueva clase.
• Una clase es responsable de una cosa
Mover Método
• ¿Qué tiene de malo este código?
• Lab 1: Ejercicio de Fowler
Ejemplo de Mover Método
• El método amountFor utiliza muchas referencias a métodos de la clase Rental.
• Haciendo un análisis a mayor profundidad se puede determinar quela clase cliente no debe de tener la responsabilidad de calcular el costo de una renta, que realmentele corresponde a la clase Renta.
• ¿Cómo debe de quedar la refactorización?
Ejemplo de Mover Método
• ¿Qué le hace falta?
Ejemplo de Mover Método
• Actualizar la referencia
• Nótese que el método no se eleminó de la clase original. Se escogió una mejor forma de llamarlo.
Ejemplo de Mover Método
• Del programa Agenda realizado en la clase anterior determine si todas las clases tienen asignadas de forma correcta su responsabilidad.
• Determine si se puede aplicar o no la refactorización de mover métodos. En caso de no poderse realizar deberá de argumentar de forma extensa su respuesta.
• ¿Qué es un walkthrough? Se pasará a hacer una prueba de recorrido.
Actividad
• Las pruebas de recorrido es una forma básica de las revisiones técnicas formales especializadas en la inspección del código.
• Un grupo de personas empiezan a detallar y explicar que hace cada línea del código del programa (aquellas que no quedan claro).
• En la programación por pares se realiza de forma casi automática
Walkthrough
• Un atributo es más utilizado por otra clase que por la clase que lo contiene.
• Se soluciona creando una nueva clase, colocando el atributo en esta nueva clase y cambiando todas las referencias hacia los clientes.
Move Field
• Hay un clase que está haciendo el trabajo de dos. Se soluciona creando una nueva clase colocando los métodos y atributos pertinentes en la nueva clase.
Extract Class
• Una clase no está haciendo nada. Se soluciona fusionando en una nueva clase los métodos y atributos de las dos clases anteriores.
• Cuando se tengan comportamientos diferentes, se deberán manejar clases aparte.
Inline Class
• Un cliente está llamando a la clase delegado de un objeto.
• Se soluciona creando métodos en la clase servidora que oculten dicha dependencia.
Hide Delegate
• Lo contrario de lo anterior. Una clase está haciendo demasiada delegación. Se soluciona dejando que el cliente se comunique directamente con el delegado.
Remove Middleman
• Dado el programa de la agenda que se realizó previamente se realizarán algunas mejoras propuestas.
• Se deberá aplicar técnicas de historia local y diferenciación de archivos.
Práctica 4
• La ofuscación es una técnica avanzada de refactorización que permite a un código mantenerle obscuro (es decir no muy legible) con diversos propósitos de optimización.
• ¿Para que se hace ofuscación?
• ¿No viola esto el principio de claridad en la implantación?
Ofuscación
• La ofuscación se realiza en muchas casos para hacer un código ilegible, también en muchos casos se puede reducir el tamaño del código fuente y del código binario realizado.
• Al realizar cualquier tipo de programa se puede aplicar técnicas de reingeniería como la ingeniería inversa para de un código binario tratar de obtener su código fuente.
Ofuscación
• En mucho tipos de aplicaciones como las aplicaciones móviles se ofusca el código objeto generado para obtener un código más pequeño.
• Un programa puede ser fácilmente decompilable, por este motivo se ofusca con la premisa de que si esto llegará ocurrir, el que lo hiciera le costaría mucho trabajo entender el programa y modificarlo.
Ofuscación
• En algunos casos la ofuscación se logra simplemente refactorizando el nombre de las variables pero en muchos casos esto no sirve.
• Para lograr la ofuscación se deberá modificar el flujo del programa de tal forma que menos instrucciones o en algunos casos más instrucciones deben de realizar el mismo programa.
Ofuscación
• En algunos casos resulta que ofuscar el código puede ser que el tamaño del código fuente y del programa aumente, debido a que es común que las variables tengan nombres muy grandes o bien se incluyan instrucciones extras, se descompongan ciclos, se cambien y mapeen estructuras, etc.
• Existen concursos de ofuscación de código
Ofuscación
Ofuscación
• Realizar la ofuscación del código de las clases del laboratorio 1 (ejemplo de Fowler) con las siguientes características:
• Refactoring de identificadores (métodos, clases, atributos) con nombres muy grandes y poco descriptivos.
• Agregando comentarios javadoc sin coherencia.
• Agregando funcionalidades no utilizadas así como código no útil.
Actividad
• Comparar su proyecto ofuscado con el original a través de diff y patch
• Determina el grado de legibilidad de la aplicación calculado a través de la siguiente fórmula:
• Líneas negras / líneas blancas * 100
• NÓTESE: LA OFUSCACIÓN NO HACE REUSABLE EL CÓDIGO PERO SI SEGURO
Actividad
• De la página principal del sitio Web de su profesor: http://antares.itmorelia.edu.mx/~jcolivar/
• Realizar ofuscación de códigos para obtener el archivo más pequeño posible. Por ejemplo si la página es de 10KB y se reduce en 8KB es buena la ofuscación. Trate de eliminar líneas en blanco. La página NO debe de cambiar. Se premiará al que logre el menor tamaño posible con 1 PUNTO EXTRA. En caso de empate se anula.
Tarea
• Reemplazar valores de datos con objetos:
• En algunas ocasiones se ocupa mejor la semántica de los datos.
Refac. de Organización de Datos
• En la práctica pasada se utilizó la clase Teléfono dado que es más fácil de ser extensible. ¿Qué hubiera sucedido si el teléfono fuera cadena y se necesitarán rutinas para formatear, extraer el prefijo, etc.?
• Problablemente estaríamos duplicando código y/o haciéndolo menos legible.
• Refactoring de números mágicos entra dentro de esta categoría.
Reemp. Val. datos con objetos
• Cuando se devuelvan colecciones (estructuras de datos) se debe de proteger la obtención de las mismas a través de un objeto no cambiante. Esto con la finalidad que a partir de un método get no se pueda modificar la colección.
Encapsular Colección
• ¿Cómo implementarla? • Sino se tiene alguna interfaz para no
modificar estructura de datos se deberá construir un objeto nuevo.
• Reemplazar códigos de tipo por clases
• Se da cuando una clase tiene atributos numéricos repetitivos que no afectan su comportamiento.
Encapsular Colección
• La solución es reemplazar los números por una clase.
Reemp. Cod. Tipos por clase
• Cuando se tiene atributos de código que afectan al comportamiento de la clase se deberá reemplazar por sublcases:
Reemp. Cod. Tipos por subclase
• Un síntoma frecuente de este malo olor es cuando se tienen varias condicionales anidadas (switches, ifs, etc.).
• De hecho las estructuras anidadas o con complejidades ciclomáticas muy altas son carácterísticas fundamentales de cualquier mal olor.
• Es recomendable que el polimorfismo encapsule esta complejidad.
Reemp. Cod. Tipo por subclase
• En algunas ocasiones no se puede realizar generalización al momento de reemplazar el atributo repetitivo por lo que se recomienda utilizar el patrón Strategy o un objeto Estado:
Reemp. Cod. Tipo por Estrategia
• Problema: se tienen subclases que sólo varían en los datos que devuelven los métodos que se consideran constantes. Aunque son muy útiles, no exhiben un comportamiento distinto, por lo que habrá que eliminar la generalización.
• Solución: subir tanto el atributo como el método a la clase padre y eliminar las subclases.
Reemp. Subclases con campos
Reemp. Subclases con campos
• Se dará un código el cual deberá reestructurarse en las cadenas de texto que forman parte de la interfaz, de tal forma que permita la internacionalización (se utilizará el asistente de internacionalización de NetBeans) de la aplicación.
• Se realizará reestructuración de datos de una aplicación legada que utiliza archivos para manejar base de datos relacionales.
Práctica 5
• Se deberá realizar un diseño e implementación de la base de datos así como la migración de los datos existentes.
• Se tendrá que instalar un manejador de base de datos y realizar conexiones a la misma.
• Se harán las modificaciones pertinentes para que la aplicación funcione con la base de datos y sea más extensible y segura.
Práctica 5
• Las expresiones condicionales son unas de las estructuras preferidas para vivir de los malos olores. A continuación se muestran algunos ejemplos de reestructuraciones.
• Descompose conditional: se tiene una condicional compleja. Se soluciona extrayendo métodos para la condición y para las acciones de falso y verdadero.
Simp. Expresiones Condicionales
Descomposición Condicionales
• Existe una serie de condicionales que se pueden unificar.
Consolidar Expresiones Cond.
• Problema: Se repite el mismo fragmento de código en todas las ramas.
• Solución: Sacarlo de la expresión
Consolidar Frag. Cond. Duplicado
• Problema: una variable está actuando como un indicador de control para una serie de expresiones lógicas.
• Solución: sustituir por breaks o returns
Remover Bandera de Control
¿Cómo debe de quedar este código reestructurado?
• El primer enfoque es utilizar break-continue que es la manera predeterminada de lenguajes como C y Java.
• Es más elegante el uso de returns. Aunque sólo aplica cuando son métodos.
• A continuación se detalla un ejemplo de reestructuración a través de return.
Remover Bandera de Control
Remover Bandera de Control
• En el código anterior found sirve de variable de control y además guarda el resultado.
• Se puede simplicar este método realizando la extracción de otro método:
void checkSecurity(String[ ] people){
String found = foundMiscreant(people); someLaterCode(found);
}
Remover Bandera de Control
Remover Bandera de Control
• Continuar con la práctica pasada.
• Revisión de algunos detalles
Actividad
• Problema: un método tiene un comportamiento condicional que obscurece el flujo del programa.
• Solución: implementar “clausulas guardianas” para los casos especiales.
• Las clausulas guardianas permiten el manejo de datos de forma más segura. Pueden ser elementos de control como break, return o bien alguna clase dada.
Reemp cond. Anidadas con guard
Reemp cond. Anidadas con guard
• Malor olor: cuando se tienen muchas comprobaciones de si un objeto es nulo.
• Desodorante: sustituir el valor null por un objeto null
Introducir Objeto Null
• Malor olor: un código hace un asunción sobre el estado del programa.
• Desodorante: hacer explícita la asunción
a través de un aserción.
• Por ejemplo en cierto tipo de validaciones como la raíz cuadrada asumimos que el dato introducido es positivo.
Introducir Aserción
• ¿Hay aserciones en java?Introducir Aserción
• Si. El código anterior es en C#
• Cuando una aserción falla se produce una excepción “unchecked”
• Indican errores de programación (que deben ser corregidos, no capturados).
• De hecho, normalmente las aserciones se desactivan en el código de producción.
Introducir Aserción
• Las aserciones sólo están disponibles a partir de JDK1.4, si se desea hacer una aserción se deberá de lanzar una excepción:
• if (! (estamos_como_queremos) ) throw new Error("fallo en tal zona del programa");
• Pero este esquema maneja banderas lo cual se acaba de ver que no es nada bueno.
Aserciones en Java
• En su lugar se puede manejar:
• assert estamos_como_queremos;
• El cual evaluará la expresión indicada para obtener un valor de verdad.
• Las aserciones han caído en desuso con la extensa proliferación de frameworks para pruebas unitarias donde se hacen aserciones: assertEquals() por ejemplo.
Aserciones en Java
• IMPORTANTE: las validaciones de datos no son aserciones!!!
• Las validaciones de datos se deben de hacer. Una aserción en teoría es para indicar una porción de código que no debiera de ejecutarse.
• Para indicar la versión de java al momento de compilar se deberá habilitar la opción –source seguido del numero de versión.
Aserciones en Java
• IMPORTANTE: el contenido colocado en assert no debe de ser vital para la ejecución del código.
• Suponga el siguiente código:
public int calcularSalario(int comisiones){ assert comisiones >=0; return 1000+(comisiones*20);}
Aserciones en Java
• Y el siguiente método para probarlo:
public static void main(String args[]){ int comisiones = 5; int sueldo = calcularSalario(comisiones); System.out.println(“Sueldo=”+ sueldo); }
• Si se corre tanto para valores de 5 y -5 para comisiones no sucede nada. ¿Por qué?
Aserciones en Java
• Se ocupa activar las directivas del manejo de aserciones:
• -ea: activa aserciones• -da: desactiva aserciones
• CONSEJO: en caso de duda siempre meter aserciones.
Aserciones en Java
• Realizar el programa (modificar si ya lo tienen) de la obtención de ecuaciones de segundo grado por fórmula general, para que maneje aserciones.
• Se deberá contar con un método main() y con interface de usuario
• ¿cuántas aserciones manejaste?
Actividad
• Cuando se está en fase de producción es muy común sustituir las aserciones y pruebas unitarias con bloques try-catch imprimiendo la traza del error en pantalla o un archivo.
• Realizar está acción de esta forma no es buena práctica de programación. El atrapar excepciones es para darles solución aunque en algunos casos como abrir o crear un archivo sean excepciones mortales.
Manejo de Errore con try-catch
• Cuando se está en fase de producción es muy común sustituir las aserciones y pruebas unitarias con bloques try-catch imprimiendo la traza del error en pantalla o un archivo.
• Realizar está acción de esta forma no es buena práctica de programación. El atrapar excepciones es para darles solución aunque en algunos casos como abrir o crear un archivo sean excepciones mortales.
Manejo de Errore con try-catch
• Otra mala práctica de programación es atrapar Excepciones genéricas (objeto de la clase Exception) si bien es cierto que nos permiten ahorrar en muchas ocasiones tiempo hacen que el software no sea predecible. Se pueden utilizar considerando las demás excepciones.
• Siempre hay que saber que tipos de errores se pueden presentar y darles un tratamiento.
Manejo de Errore con try-catch
• Parte de las malas prácticas del uso de try-catch en lenguajes con marcado de errores implícito como Java es el hecho que al forzarnos a atrapar el error solamente lo hacemos para que corra el programa y no en si por manejar el error. En algunas ocasiones no siempre es obligatorio.
• Se recomienda lanzar errores en métodos que implementen el modelo, mientras que en la interfaz se deben atrapar.
Manejo de Errore con try-catch
• Por cada excepción que se lance debe de haber una parte donde se atrape. Por tal motivo es una mala práctica de programación poner una excepción en el método main().
• Se recomienda crear nuestros propios manejadores de errores extendiendo de la clase Exception y colocando aquellos métodos y atributos para procesar el error.
Manejo de Errore con try-catch
• Modificar el programa anterior (raíces de una ecuación cuadrática) para que maneje excepciones y haga las validaciones respectivas.
• Se contará con una interfaz con JOptionPane.
• Las entradas se validarán para que al encontrarse un error se marque una excepción creada por nosotros.
Actividades
• Para posteriormente procesarlas en la interfaz.
• Al introducir un valor incorrecto se deberá quedar en donde está el error para volver a introducir la entrada.
• Las clases Excepciones a Generar son: NoPolinomioCuadrado cuando a=0 y RaizImaginaria cuando el discriminante es <0.
Actividades
• Rename Method: cambiar el nombre de un método por otro más indiciativo. En muchas ocasiones no se puede a la primera vez pero no hay que caer en la tentación de dejarlo tal cual.
Ref. mejorar Simplicidad Método
• Problema: El método necesita que se le pase más información.
• Solución: agregar un parámetro. Si se necesita el método anterior se necesitará realizar polimorfismo.
Add Parameter
• En la medida de lo posible hay que evitar el tener una lista de parámetros muy grande.
• Siempre hay que ver si la información se puede obtener a través de otros objetos.
• Cuando se quede una lista muy grande de parámetros se recomienda enmascarar la lista de argumentos en un objeto estructura.
Add Parameter
• Malor olor: un método devuelve un valor pero también cambia el estado de un objeto.
• Desodorante: crear dos métodos uno para la consulta y otro para el modificador.
Separate query from Modifier
• Malor olor: varios métodos hacen lo mismo pero con diferentes parámetros.
• Desodorante: crear un método que use un parámetro para los diferentes valores.
Parametizer Method
• Malor olor: un método ejecuta distinto código dependiendo de un valor enumerado.
• Desodorante: crear un método separado para cada valor del parámetro.
• Es más claro tener el método switch.turnOn() que switch.setOn(true)
Repl. Param. with Explicit Meth.
Repl. Param. with Explicit Meth.
• En la década de 1980’s los Sistemas de Información se desarrollaban con UI basadas en Texto.
• En la década de 1990’s los desarrollos fueron “visuales”.
• La década de 2000 se caracterizó por el desarrollo Web.
Patrón MVC
• En la década de 2010 se caracterizará probablemente por el desarrollo móvil y ubicuo.
• Si estas aplicaciones no se desarrollan de forma especial, se tendría que realizar la aplicación desde el inicio.
• Para solucionar este problema existe el patrón de diseño Modelo-Vista-Controlador.
Patrón MVC
Patrón MVC
• Modelo: lógica de datos. Si es java se trata de que sean beans.
• Vista: interfaz de usuario
• Controlador: liga tanto a la vista como al el controlador. Responde generalmente al manejo de eventos.
• Es mala recomendación dejar embebido en la interfaz código de lógica de programa.
Patrón MVC
• Dado un código fuente, refactorizarlo para que pueda ser convertido a una biblioteca dentro del paquete mx.edu.itmorelia.refactoring.
• Se deberá importarlo en otro proyecto donde se aplicará el patrón de diseño MVC. Donde el modelo está representado por nuestra biblioteca, el controlador contiene el método main() y construye tanto las vistas como el modelo.
Práctica 6.
• Se manejarán dos vistas: una en modo texto y otra en una GUI utilizando para ambas métodos de validación para la entrada de datos.
• El controlador encapsula la llamada a los métodos tanto del modelo como de la vista para que puedan trabajar de manera conjunta sin mucho acoplamiento.
Práctica 6
• Aplicación de Refactoring simples
• Del proyecto número uno (ejemplo de Fowler). Realizar las siguientes reestructuraciones:
• Extraer método dentro del método statement() de la clase customer en la parte del switch. Llamarlo amountFor para que recibe como argumento un objeto de la clase rental.
Práctica 7
• Cambiar las referencias necesarias en Customer.statement().
• Cambiar el tipo de datos de amountFor a double (para un mejor desemepeño) actualizando las referencias.
• Dentro del código de amountFor renombrar las variables each por aRental, thisAmount por result.
Práctica 7
• Aplicar el refactoring Move Method amountFor de la clase Customer a Rental.
• Renombrar el método amountFor de la clase Rental a getCharge. Ajustar los cambios al método amountFor de la clase customer.
• Del método statement se Extraerá el método Frecuent Renter Points (porción del código que incrementa variable frequentRenterPoints).
Práctica 7
• El nuevo método se llamará getFrequentRenterPoints() y se implementará dentro de la clase Rental.
• Ahora se remplazarán todas las variables temporales. Se aplicará el refactoring Replace Temp with query a las variables totalAmount y frecuentRentalPoints del método Custromer.statement().
• Primeramente todas las referencias a totalAmount se encapsularán en el método
Práctica 7
• getTotalCharge() contenido dentro de la clase Customer. Actualizar la referencia en la cadena result.
• Ahora realizar lo mismo con frequentRenterPoints con el método getTotalFrequentRenterPoints().
• Nótese que en ambos casos se deberá repetir la estructura cíclica que los contenía (esto aumenta el código pero mejora la legibilidad del mismo).
Práctica 7
• Agregar una nueva funcionalidad a la clase Customer denominada htmlStatement() que haga exactamente lo mismo que statement() agregando etiquetas de HTML a la cadea de resultado.
• Aquí puede observarse cómo se aplican los refactoring de sustituir temps que parecían imprácticos.
Práctica 7
• Agregar una nueva funcionalidad a la clase Customer denominada htmlStatement() que haga exactamente lo mismo que statement() agregando etiquetas de HTML a la cadea de resultado.
• Aquí puede observarse cómo se aplican los refactoring de sustituir temps que parecían imprácticos.
• Los refactorings de ahora serán más interesantes.
Práctica 7
• Una problemática del código en Rental.getCharge() es el manejo de switch en getPrice() esto puede mejorarse si se aplica el refactoring de reemplazar la lógica condicional de PriceCode con polimorfismo.
• Esto implica en primera instancia que el método getCharge() deba de ser movido a la clase Movie actualizando su referencia en Rental.getCharge().
Práctica 7
• Se deberá aplicar tambien mover método al método Rental.getFrequentRenterPoints() a la clase Movie actualizando las referencias.
• Ahora sí, podemos aplicar herencia. Definiendo tres subclases RegularMovie, ChildrensMovie y NewReleaseMovie todas ellas sobrecargando el método getCharge() de la clase padre (el demás funcionamiento no se modifica).
Práctica 7
• Esto parece una mejor opción. Al menos funciona para reemplazar la condicional con polimorfismo. Desafortunadamente esta implementación no es eficiente si una película cambia su clasificación durante el transcurso de su vida (no siempre será estreno por ejemplo, o podrá pasar de moda y aplicar algún descuento).
• Para hacer más extensible esto. Será necesario utilizar el patrón de diseño State (estado).
Práctica 7
• Para aplicar el patrón estado simplemente nuestra clase padre Movie delega funcionalidad a una nueva clase denomina Price que maneja la herencia de las clases RegularPrice, ChildrensPrice y NewReleasePrice.
• El primer cambio a aplicar es dentro del constructor de Movie el acceso al atributo _priceCode no puede realizarse de manera drecta (se está aplicando Replace TypeCode with State/Strategy).
Práctica 7
• Por lo que se deberá definir un método setPriceCode() y getPriceCode().
• La clase Price debe definir como abstracta al igual que el método getPriceCode().
• El método setPriceCode de la clase Movie debe definir en base a su argumento una estructura switch construyendo un objeto concreto de Price (RegularPrice, ChildrenPrice, NewReleasePrice).
Práctica 7
• Ahora se moverá la funcionalidad del método Movie.getCharge() a Price.getCharge() actualizando referencias respectivas.
• Ahora que se tiene el método Price.getCharge() se puede nuevamente reemplazar la condicional por polimorfismo, en este caso implementando la funcionalidad de cada switch dentro de las clases Price concretas. De esta forma Price.getCharge() pude ser manejada como abstracta.
Práctica 7
• Ahora se pude aplicar el refactoring anterior a Movie.getFrequentRenterPoints().
• Por lo que se deberá mover a Price y actualizar las referencias. Para despues pasar dicha funcionalidad a la clase NewReleasePrice. En la clase Price el método siempre devuelve uno de valor (1).
• De esta forma se tiene la siguiente estructura final del proyecto.
Práctica 7
• Definir para cada paso de refactoring aplicado las nuevas pruebas unitarias que ayuden a validar que el software es correcto.
• Nótese como un proceso aparentemente simple (código de la práctica 1) puede volverse complejo si el refactoring no se realiza paso por paso.
Práctica 7
• Fowler, M. (1999), Refactoring, Adison-Wesley.
• Sanchez, M., (2009), Material del Curso de Reestructuración de Códigos, Instituto Tecnológico de Morelia.
Referenicas
Dudas
