Catálogo de Refactorizaciones

Presentación del tema: "Catálogo de Refactorizaciones"— Transcripción de la presentación:

1 Catálogo de Refactorizaciones
M.C. Juan Carlos Olivares Rojas Marzo 2011

2 Agenda Composición de Métodos Moviendo Características entre objetos
Organización de datos Skype: juancarlosolivares Web:

3 Agenda Simplificación de expresiones condicionales
Simplificar llamadas a métodos Generalización* Refactorizaciones mayores* Skype: juancarlosolivares Web:

4 Competencia Específica
Investigará las técnicas de reestructuración necesarias para corregir los errores de código, y las aplicará en un caso práctico. Competencia Específica Nos auxiliamos de muchas competencias genéricas (ver programa de la materia) Genéricas Instrumentales: Capacidad de análisis y síntesis, Solución de problemas, Toma de decisiones. 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.

5 Criterios de Evaluación
70% Examen práctico 30% Desarrollo de portafolio de evidencias (trabajos, tareas y prácticas)

6 Composición de Métodos

7 Las categorías de refactoring de la presente unidad están basadas en (Fowler, 1999).
Esta categoría tiene como objetivo evitar los malos olores producidos por la duplicación de código (métodos grandes, clases envidiosas, etc.). Composición de Método

8 La clave para solucionar estos problemas es reescribir código, de tal forma que se pueda entender mucho mejor con la menor redundancia posible. El primer refactoring es “Extract Method“ visto con anterioridad. Composición de Método

9 Inline Method Problema: existe mucha indirección de código cuando un método llama a otro y este último es muy pequeño o poco representativo. Solución: El cuerpo de un método debe ser tan claro como el nombre del mismo.

10 Inline Method Para lograr esto, es necesario poner el cuerpo del método dentro de sus propias llamadas y posteriormente pueda ser eliminado el otro método. como a continuación se muestra. Lenguajes como C++ hacen uso de métodos y variables en línea.

11 Inline Method

12 Inline Temp Problema: cuando una variable es utilizada una sola vez o pocas veces. Solución: es conveniente substituirla por el valor de la asignación temporal

13 Inline Temp Se debe tener cuidado de que el manejo en valores en línea sea más simple y claro que el uso de una variable temporal.

14 Replace Temp with Query
Problema: una variable temporal se utiliza en diversas partes del programa provocando que se recalcule varias veces Solución: reemplazar dicha variable por la invocación de un método. Replace Temp with Query

15 Replace Temp with Query

16 Introduce Explaining Variable
Problema: si se tiene una expresión compleja que se desea reducir su complejidad Solución: introduce el resultado de la expresión (o partes de ella) en una variable temporal que explique el propósito.. Introduce Explaining Variable

17 Introduce Explainig Variable

18 Split Temporary Variable
Problema: cuando se asigna una variable temporal más de una vez, pero no es una variable de control (de ciclo) ni tampoco una variable de alguna colección (estructura). Split Temporary Variable Se repiten varias variables

19 Split Temporary Variable
Solución: se debe fraccionar la variable haciendo una variable diferente para cada asignación. ¿POR QUÉ? Utilizar variables temporales más de una vez (para mas de una cosa) es confuso. Split Temporary Variable

20 Split Temporary Variable

21 Remove Assigment to Parameters
Problema: se le asigna un valor a un parámetro y su forma de acceso no es por referencia. Solución: utilizar una variable temporal en su lugar Remove Assigment to Parameters

22 Remove Assigment to Parameters

23 Replace Method with Method Object
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.

24 Replace Method with Method Object
public class orden{ public double precio(){ double primerPrecioBase; double segundoPrecioBase; double tercerPrecioBase; //CÁLCULO GRANDE …. }

25 Replace Method with Method Object

26 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. De preferencia se deben conservar las interfaces de los métodos Substitute Algorithm

27 Substitute Algorithm

28 Actividad: del programa criba substituir el algoritmo para mejorar la legibilidad del código.
Encontrar de manera individual cada número primo desde 1 hasta n Substitute Algorithm

29 Actividad: es importante que las interfaces del método (parámetros, tipo de retorno) queden igual al original. Corroborar con pruebas de regresión (pruebas unitarias). Substitute Algorithm

30 Un algoritmo puede medir su desempeño de diversas formas.
La medición depende de exactamente lo que se quiere medir. Si se trata de legibilidad de código no es tan sencilli Medición de Desempeño

31 La legibilidad puede darse en tener menos líneas de código o en estar más entendible. Esta es una métrica muy subjetiva. En general el desempeño de un algoritmo se mide por su complejidad. Medición de Desempeño

32 La complejidad generalmente se mide en tiempo de CPU consumido aunque también puede manejarse por otros factores como el espacio de almacenamiento. Respecto a la velocidad se puede tomar el tiempo de pared que tarda el algoritmo. Medición de Desempeño

33 El tiempo de pared no es una métrica muy exacta
El tiempo de pared no es una métrica muy exacta. Se puede mejorar si se usa el tiempo desde la computadora aunque sigue sin ser exacto. Bajo este tipo de métrica, las pruebas unitarias pueden auxiliarnos dado que registran tiempo. Medición de desempeño

34 Con la misma prueba unitaria, realiza la corrida de los dos algoritmos para generar números aleatorios, ¿cuál fue la más rápida? La estadística juega un papel fundamental, por ello, deberás realizar corridas más de cada una y sacar el promedio final Actividad

35 La forma más genérica de encontrar la complejidad de un algoritmo es a través de un análisis matemático. En general los programas de cómputo son lineales, en este caso se maneja una constante C que es el número de líneas totales. Medición de Desempeño

36 Entre programas lineales, es más eficiente el que tiene menos líneas de código.
En general, si se presentan ciclos se maneja un término lineal n. Se pueden tener polinomios más complejos y generalmente la constante C no es tomada en cuenta. Medición de Desempeño

37 Medición de Desempeño Por ejemplo: boolean perfecto = false; suma = 0;
for(int i=1;i<n-1;i++){ if(n%i==0) suma+=i; } if(suma==n) perfecto = true; Medición de Desempeño

38 Medición de Desempeño Este algoritmo tiene la siguiente complejidad:
Las primeras dos líneas son secuenciales por lo tanto C=2. Después se tiene un ciclo que se repite n-1 veces con una instrucción que siempre se repite Medición de Desempeño

39 Por lo tanto la complejidad es de (n-1) * 1 = n-1
Al final se tiene una decisicon incrementandose la constante C, quedando C=3 Se dice que C es constante por que independiente de los datos siempre se ejecuta. Medición de Desempeño

40 Medición de Complejidad
La variable n depede de los datos de entrada del algoritmo. La complejidad del algoritmo es (n-1)+3 = n+2. Generalmente se desprecia c por lo que la complejidad se maneja como n o simplemente lineal. Medición de Complejidad

41 En general en los polinomios de complejidad la parte más importante es el monomio con la mayor grado, así una complejidad de n2+2n+5 se reduce en n2, siendo cuadrático. Si se tienen dos algoritmos de n+10 y de 2n+1 se consideran prácticamente iguales. Medición de Desempeño

42 Es muy común en la determinación de complejidad manejar tres escenarios de como se comportan los algoritmos en el mejor de los casos, en el peor de los casos y en el caso promedio. En general se comparan las curvas de la complejidad de los algoritmos. Medición de Desempeño

43 Determina cual es la complejidad del primer algoritmo (recuerda que si se invocan métodos la complejidad es la suma de la complejidad de los métodos) Determina la complejidad del nuevo algoritmo y comparala con el anterior. Actividad

44 En cuestión de espacio simplemente se revisa la cantidad de variables y su tamaño.
En este caso hay que contabilizar el tamaño total en bytes de las estructuras de datos utilizadas de ambos algoritmos y compararlas. Medición de Desempeño

45 Moviendo Características entre Objetos

46 Moviendo características
Atacan principalmente el problema de que las responsabilidades de un clase realmente no le pertenecen. Se soluciona moviendo el código de una clase a otro. El refactoring más sencillo es el ya visto de Move Method.

47 Move Field Problema: un atributo es usado más en otra clase distinta a la que está. Solución: mover el atributo a la otra clase.

48 Problema: una clase está haciendo lo que deberían hacer dos clases (podría ser una clase grande).
Solución: crear una nueva clase y colocar la funcionalidad repartida entre las dos clases Extract Class

49 Extract Class

50 Inline Class Problema: Una clase no está haciendo mucho (perezosa)
Solución: mover todas sus características en otras clases y borrar dicha clase. Inline Class

51 Problema: una clase cliente llama a la clase delegada de otro objeto, situación que no debe de ocurrir. Solución: ocultar el método de la clase delegada así como el orden de las interacciones Hide Delegated

52 ¿Qué hay de malo en esto? Hide Delegate

53 Solución Hide Delegate

54 Remove Middleman Problema: se tiene una clase intermedia que hace más difiícil de entender la delegación de responsabilidades (lo contrario al problema anterior). Solución: quitar la clase intermedia y hacer la delegaciónde forma directa

55 Remove middleman

56 Problema: una clase servidora necesita de un método adicional, pero no podemos modificar la clase
Solución: crear un método en la clase cliente con una instancia de la clase servidora como primer argumento Introd. Foreign Method

57 Date newStart = new Date (previousEnd. getYear(), previousEnd
Date newStart = new Date (previousEnd.getYear(), previousEnd.getMonth(), previousEnd.getDate() + 1); Date newStart = nextDay(previousEnd); private static Date nextDay(Date arg) { return new Date (arg.getYear(),arg.getMonth(), arg.getDate() + 1);} Introd. Foreign Method

58 Introd. Local Extension
Problema: una clase servidora necesita de múltiples métodos pero no podemos modificar la clase. Solución: crear una nueva clase que contenga estos métodos. Hacer de esta una subclase, clase de extensión o Wrapper de la original. Introd. Local Extension

59 Introd. Local Extension

60 Organización de Datos

61 Se propone una serie de lineamientos enfocados al correcto uso de la información de un objeto, como puede ser el encapsulamiento de atributos, el reemplazo de referencias por valores, el reemplazo de estructuras por objetos, etc. Organización de Datos

62 Self Encapsulated Field
Problema: se accede directamente un campo, pero el acoplamiento con éste se torna poco manejable Solución: crear métodos de get y set para manipular los campos y utilizar solo ésos métodos para acceder a los campos.

63 Self Encapsulated Field

64 Repl. Data Val with Obj. Replace Data Value with Object
Problema: se necesita algún dato adicional o complementario Solución: el dato se vuelve un objeto. Repl. Data Val with Obj.

65 Repl. Data Val with Obj.

66 Change Value to Reference
Problema: se tiene una clase con muchas instancias iguales que se desea reemplazar con un objeto simple. Solución: cambiar el objeto por una referencia al objeto

67 Change Value to Reference

68 Change Value to Reference
class Customer { public Customer (String name) {}_name = name;} public String getName() {return _name;} private final String _name; }

69 Change Value to Reference
class Order... public Order (String customerName) {_customer = new Customer(customerName);} public void setCustomer(String customerName) {_customer = new Customer(customerName);} public String getCustomerName() {return _customer.getName(); private Customer _customer;}

70 Change Value to Reference
Y el siguiente código cliente: private static int numberOfOrdersFor(Collection orders, String customer) { int result = 0; Iterator iter = orders.iterator();

71 Change Value to Reference
while (iter.hasNext()) { Order each = (Order) iter.next(); if (each.getCustomerName().equals(customer)) result++; } return result;}

72 Change Value to Reference
¿qué hay de malo en el código? Siempre se crea un nuevo cliente cada vez que se usa el código. Se debe cambiar el código para devolver una referencia en caso de que exista. Ocupa de ver más refactorings.

73 Change Reference to Value
Problema: se tiene una referencia a objeto que es pequeña, inmutable y fácil de manejar Solución: cambiar la referencia por el valor de un objeto Change Reference to Value

74 Change Reference to Value

75 Sintactic Sugar

76 Azúcar Sintáctico Es una facilidad dada por los desarrolladores del lenguaje para escribir menos. El ejemplo más sencillo es el operador ++, C++ es equivalente a C=C+1 Ciclo for (implementación while)

77 Azúcar Sintáctico IF como operador ternario ?:
Goto en java, etiquetas: public  static  void  imprimir(String ...  cadenas) {      for (String  cadena : cadenas)         System.out.println(cadena);    }  }  

78 Azúcar Sintáctico Boxing automático de Datos Primitivos a Objetos: Integer a int Arreglos Triangulares Uso de objetos y métodos Thread-safe El uso de objetos sincronizados hace más lento el desempeño de las aplicaciones. Si la aplicación no maneja concurrencia no hay necesidad de utilizarlas (en java Vector y ArrayList hacen exactamente lo mismo sólo que Vector es sincronizada).

79 Replace Array with Object
Problema: se tiene un arreglo con valores de diferente elementos. Solución: crear un objeto con propiedades de cada valor. Replace Array with Object

80 Replace Array with Object
Ejemplo: String[] row = new String[3]; row [0] = "Liverpool"; row [1] = "15"; Performance row = new Performance(); row.setName("Liverpool"); row.setWins("15"); Replace Array with Object

81 Otros conocidos Replace Magic Number with symbolic Constant
Encapsulated Field Otros conocidos

82 Laboratorio Del código proporcionado realizar lo siguiente:
Determinar malas prácticas de programación. Indicar que refactoring de los vistos en el catálogo se aplicó en el código. Laboratorio

83 Es opcional pero ampliamente recomendable la utilización de pruebas unitarias.
El programa deberá realizar las mismas funciones que el original. Podrá realizarse en parejas. Laboratorio

84 Siete Pecados Capitales en el Diseño de Lenguajes
Tomadoen parte del artículo: “Seven Deadly Sins of Introductory Programming Language Design” de Linda McIver y Damian Conway. Department of Computer Science Monash University, Victoria, Australia

85 1. Menos es Más No se debe de abusar de la simplicidad.
Por ejemplo lenguajes como LISP solo tienen un tipo de datos: la lista. Esto hace que el lenguaje sea simple pero difícil de manejar para el programador. 1. Menos es Más

86 Este pecado se puede ver en los lenguajes interpretados donde sólo hay un tipo de datos genérico, el cual puede convertirse en múltiples tipos dependiendo del contexto. La estructura de un programa debe de ser simple. 1. Menos es Más

87 Los lenguajes deben de ser lo más versátiles y poderosos
Los lenguajes deben de ser lo más versátiles y poderosos. C es de propósito general con un enfoque hacia abajo nivel. En general los programas deben de ser funcionales y brindar “experiencias” a los usuarios. 2. Más es Más

88 Los lenguajes deben tener sinónimos semánticos para simplificar su uso (llamado Azúcar sintáctico). Por ejemplo para acceder al segundo valor de un arreglo en C se tienen las siguientes formas: array[1] *(array+1) 1[array] *++array Las aplicaciones deberán manejar formas alternas de utilizarse. 3. Trampa Gramatical

89 4. Dependencia del Hardware
Los lenguajes no deben de depender tanto del hardware para poder funcionar. Las aplicaciones deben de poder correr en cualquier tipo de arquitectura sin ningún problema. 4. Dependencia del Hardware

90 5. Compatibilidad hacia a traás
Los compiladores por razones de compatibilidad deben de soportar las versiones anteriores de los lenguajes, esto hace más pesado e ineficiente el proceso de compilación. Se recomienda que las aplicaciones nuevas no dependan de las anteriores. 5. Compatibilidad hacia a traás

91 6. Inteligencia Excesiva
El lenguaje debe ser simple de manejar. Las aplicaciones deben ser fácilmente manipulables por los usuarios. 6. Inteligencia Excesiva

92 7. Violación de Expectativas
Las instrucciones deben de realizar una sola cosa. En muchas ocasiones el comportamiento depende del contexto de la aplicación. Por ejemplo, algunos lenguajes utilizan el operador = para asignación y para igualdad. 7. Violación de Expectativas

93 7. Violación de Expectativas
En general las aplicaciones deben de realizar una acción en concreto. 7. Violación de Expectativas

94 Encapsular Colección 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.

95 Encapsular Colección ¿Cómo implementarla?
Sino se tiene alguna interfaz para no modificar estructura de datos se deberá construir un objeto nuevo.

96 Reemp. Cod. Tipos por clase
Problema: Se da cuando una clase tiene atributos numéricos repetitivos que no afectan su comportamiento. Solución: La solución es reemplazar los números por una clase Reemp. Cod. Tipos por clase

97 Reemp. Cod. Tipos por clase

98 Reemp. Cod. Tipos por subclase
Cuando se tiene atributos de código que afectan al comportamiento de la clase se deberá reemplazar por sublcases:

99 Reemp. Cod. Tipo por Estrategia
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:

100 Permite tener una interfaz común hacia diversas implementaciones de un problema.
Este patrón es útil cuando un problema puede resolverse por diversos algoritmos o estrategias. Patrón Estrategia

101 Patrón estrategia

102 Reemp. Subclases con campos
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.

103 Reemp. Subclases con campos
¿cómo queda la reestructuración?

104 Simplificación de Expresiones Condicionales

105 Descompose Conditional
Problema: se tiene una condicional compleja. Solución: se extraen métodos para la condición y para las acciones de falso y verdadero. Descompose Conditional

106 Descompose Conditional

107 Consolidate Conditional Expression
Existe una serie de condicionales que se pueden unificar. Consolidate Conditional Expression

108 Consolidate Duplicate Conditional Fragments
Problema: Se repite el mismo fragmento de código en todas las ramas. Solución: Sacarlo de la expresión Consolidate Duplicate Conditional Fragments

109 Consolidate Duplicate Conditional Fragments

110 Remove Control Flag ¿Cuál es el problema con el siguiente código?

111 Remove Control Flag Problema: una variable está actuando como un indicador de control para una serie de expresiones lógicas. Solución: sustituir por breaks o returns

112 Remove Control Flag

113 Remove Control Flag En el código anterior found sirve de variable de control y además guarda el resultado. Si se aplica el refactoring se obtiene: void checkSecurity(String[ ] people) { String found = foundMiscreant(people); someLaterCode(found); }

114 Remove Control Flag

115 Patrón MVC 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.

116 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.

117 Patrón MVC

118 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.

119 Patrón MVC Es una variante del principio de separación de interfaces.
En un desarrollo Web, la vista es la página en HTML, el modelo es la Base de Datos y el Controlador es el código que interactúa para hacer el manejo de entradas/salidas y manda llamar al proceso.

120 Patrón MVC Existen diversas implementaciones de este patrón, no hay ninguna estandarizada como tal. Puede haber un modelo con varias vistas y controladores. Existen muchos frameworks que trabajan con este principio de forma nativa (Struts, Codeigniter, Ruby on Rails).

121 Patrón MVC El Flujo de control es el siguiente:
1.El usuario realiza una acción en la interfaz 2.El controlador trata el evento de entrada. Previamente se ha registrado. Patrón MVC

122 3.El controlador notifica al modelo la acción del usuario, lo que puede implicar un cambio del estado del modelo (si no es una mera consulta) 4.Se genera una nueva vista. La vista toma los datos del modelo. El modelo no tiene conocimiento directo de la vista Patrón MVC

123 5.La interfaz de usuario espera otra interacción del usuario, que comenzará otro nuevo ciclo
Patrón MVC

124 Patrón MVC

125 public class ProgramaDeConversión { public static void main(String[] args) { ConversorEurosPesetas modelo = new ConversorEurosPesetas(); vista = new VentanaConversor(); Patrón MVC

126 ControlConversor control = new ControlConversor (vista, modelo); vistavista.setControlador(control); vista.arranca(); } Patrón MVC

127 Replace Conditional with Guard Clauses
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.

128 Replace Conditional with Guard Clauses

129 Replace Conditional with Polimorfism
Problema: Una sentencia condicional realiza una acción dependiendo del tipo de objeto instanciado. Solución: mover cada parte de la condicional a un método de una subclase. La clase padre debe de ser de preferencia abstracta. Replace Conditional with Polimorfism

130 Replace Conditional with Polimorfism

131 Patrón Estado State es un patrón que resuelve la problemática de que el comportamiento de un objeto depende de su estado, y sus métodos contienen la lógica de casos que reflejan las acciones condicionales dependiendo del estado. Solución: cree clases de estado para cada estado que implementan una interfaz común.

132 Patrón Estado Utiliza una superclase abstracta (clase de estado), la cual contiene métodos que describen los comportamientos para los estados de un objeto. Se maneja una clase de contexto que es la que sirve de interfaz al cliente.

133 Patrón Estado

134 Simplificar llamadas a métodos

135 Ref. mejorar Simplicidad Método
Estos refactorings tratan de mejorar la legibilidad del uso de los métodos. Algunos refactorings ya se han visto como Rename method 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.

136 Add Parameter 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. En la medida de lo posible hay que evitar el tener una lista de parámetros muy grande. También existe Remove Parameter 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.

137 Separate query from Modifier
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.

138 Parametizer Method 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.

139 De la biblioteca Vector utilizarla como modelo y desarrollar un programa aplicando el Patrón MVC.
Considerar dos vistas: una gráfica y una textual que deberán poderse seleccionar al inicio del programa como argumento en CLI. Actividad

140 Actividad java AppVector [text]
La aplicación debe de funcionar con los 5 métodos definidos en la biblioteca. El día de hoy se entrega el modelado arquitectónico de la aplicación. Actividad

141 Repl. Param. with Explicit Meth.
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)

142 Repl. Param. with Explicit Meth.

143 Replace Parameter with Method
Problema: si un objeto llama a un método que después pasa el resultado obtenido como parámetro para otro método y finalmente el método receptor puede también invocar al primer método, entonces se tiene que eliminar el parámetro y dejar que el receptor invoque directamente al otro método para así ahorrarnos pasos. Replace Parameter with Method

144 Replace Parameter with Method

145 Introduce Parameter Object
Problema: un grupo de parámetros que de manera natural van juntos, representan un problema Solución: hay que reemplazarlos con un objeto Introduce Parameter Object

146 Introduce Parameter Object

147 Problema: el tiempo de creación de un atributo debería estar fijo y nunca alterado.
Solución: remover los métodos set. Remove Setting Method

148 Remove Setting Method

149 Hide Method Problema: un método no está siendo utilizado por ninguna otra clase Solución: el método deberá ser privado.

150 Hide Method

151 Replace Error Code With Exception
Cuando un método devuelve un código especial para indicar un error, lo recomendable es hacer el uso de una excepción Replace Error Code With Exception

152 Replace Error Code With Exception

153 Dudas