Refactoring, Reuso y Realidad M.C. Juan Carlos Olivares Rojas Mayo 2011.

Presentación del tema: "Refactoring, Reuso y Realidad M.C. Juan Carlos Olivares Rojas Mayo 2011."— Transcripción de la presentación:

1 Refactoring, Reuso y Realidad M.C. Juan Carlos Olivares Rojas Mayo 2011

2 Agenda Generalización* Refactorizaciones mayores* Rechazo a la reestructuración Implicaciones concernientes al reuso de software La realidad de la reestructuración

3 Competencia Específica conocerá el impacto de la reestructuración en el reuso de software, así como la realidad actual de la aplicación de la misma en el ámbito de desarrollo de software.

4 Criterios de Evaluación 100% Ensayo sobre refactoring en la realidad.

5 Generalización

6 Refactorizar para generalizar Categorías de Refactoring

7 Reestructurar para generalizar Categorías de Refactoring

8 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

9 ¿Hay aserciones en java? Introducir Aserción

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 La generalización es una herramienta muy potente que nos permite evitar mucha duplicación de código. Utilizándola correctamente podemos conseguir que nuestro código sea muy fácil de extender. En estas refactorización encontramos: Subir Atributo, Subir Metodo, Subir CodigoConstructor Bajar Atributo, Ref. en el manejo de Herencia

26 Bajar Metodo, Extraer Subclase Extraer Superclase, Extraer Interfaz, Agrupar Jerarquia, Sustituir Herencia Por Delegacion, Sustituir Delegacion Por Herencia En el caso de los refactorins de subir y bajar tanto campos como atributos ya se han comentado con anterioridad. Ref. en el manejo de Herencia

27 Problemática: se tiene constructores en las subclases donde prácticamente es el mismo código. Solución: crear un constrctor de la clase. Llamarlo desde las subclases. Pull Up Constructor Body class Manager extends Employee... public Manager (String name, String id, int grade) { _name = name; _id = id; _grade = grade; } public Manager (String name, String id, int grade) { super (name, id); _grade = grade; }

28 Motivación: Los constructores son engañosos. No son totalmente métodos, por lo que su uso es restringido y delicado. ¿Por qué es necesario definir primero el constructor de la superclase en la subclase? porque al crear una instancia de una clase, se ejecuta primero el constructor de su superclase, y después el de ella misma. Pull Up Constructor Body

29 Problemática: Una clase tiene características que son usadas sólo en algunas instancias. Solución: Crear una subclase para este subconjunto de características. Extract Subclass Trabajo getTotalPrice getUnitPrice getEmployee Trabajo getTotalPrice getUnitPrice Labor getUnitPrice getEmployee

30 Motivación: El principal motivo para utilizar esta refactorización, es que una clase tenga comportamiento que es usado por algunas instancias de la clase y no se use para el resto. La principal alternativa para esta refactorización es Extract Class. Esto significa seleccionar entre delegación y herencia. Extract subclass es usualmente simple para realizar, pero tiene sus limitaciones. Extract Subclass

31 Problema: se tienen dos clases con características similares Solución: crear una superclase y mover las características comunes a la superclase. Extract Superclass Department getTotalAnnualCost() getName() getHeadCount() Employee getTotalAnnualCost() getName() getld() Party getTotalAnnualCost( ) getName( ) Department getHeadCount( ) Employee getld( )

32 Motivación: el código duplicado es una de las principales cosas malas en los sistemas. Una forma de código duplicado es tener dos clases que hacen cosas similares de la misma manera o de distinta manera. Los objetos proporcionan mecanismos de ‘construcción’ para simplificar esta situación con herencia. Extract Superclass

33 Problema: Varios clientes usan el mismo subconjunto de una interface, o dos clases tienen parte de sus interfaces en común Solución: Extraer el subconjunto dentro de una interface Extract Interface

34 Extract Interface Employee getRate() hasSpecialSkill() getName() getDepartment() > Billable getRate( ) hasSpecialSkill( ) Employee getRate() hasSpecialSkill() getName() getDepartment()

35 Motivación: Las clases son usadas por otras en diferentes maneras, por lo que son implementadas de forma diferente para cada clase. Cuando una clase necesita comportamientos de más de una clase, se soporta con lo que se llama Herencia múltiple. Java tiene herencia simple, pero permite establecer e implementar esta clase de requerimientos usando interfaces. Extract Interface

36 Las clases abstractas como su nombre lo indica son clases que no pueden instanciar objetos. Por este motivo sólo se utilizan para definir taxonomía de clases. Las interfaces definen las carácterísticas de una clase pero no la implementan. Las interfaces sirven para manejar “herencia múltiple”. Interfaz vs Clase Abstracta

37 Un futbolista tiene ciertas carácterísticas que no necesariamente definen su personalidad. Una persona puede tener el comportamiento de un futbolista. Por este motivo no heredan sino que implementan una interfaz. Las clases abstractas pueden tener métodos abstractos o no. Cuando un método es abstracto debe ser redefinido en la subclase. Interfaz vs Clase Abstracta

38 Las interfaces todos sus métodos son abstractos. Una interface no encapsula datos. ¿Cómo se implementaría en Java? Interfaz vs Clase Abstracta

39 Problema: Una superclase y una subclase no son muy diferentes Solución: mezclar las clases Colapse Hierarchy Empleado Vendedor Empleado

40 Motivación: Refactorizar una jerarquía a menudo involucra subir métodos y campos, así como bajar la jerarquía en cuanto a niveles. Se tienen que encontrar las subclases que no están añadiendo algún valor, y es necesario mezclarlas con otra. Colapse Hierarchy

41 MECANISMO: Selecciona que clase será eliminada: la superclase o alguna subclase. Utilizar subir campo o método, bajar campo o método, para mover comportamientos y datos, de la clase eliminada a la clase con la que será mezclada. Colapse Hierarchy

42 Compilar y probar cada movimiento. Ajustar las referencias a la clase que será eliminada para usar la clase mezclada. Esto afectará declaraciones de variables, tipos de parámetros y constructores. Eliminar la clase vacía. Compilar y probar Colapse Hierarchy

43 Dudas