Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

PATRON DE DISEÑO REFACTORY

No description
by

Arturo Ramos

on 25 March 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of PATRON DE DISEÑO REFACTORY

Sintomas para refactorizar Universidad Tecnológica de Durango 0 + - = 9 8 7 1 2 3 4 5 6 c ¡ POR SU ATENCION GRACIAS ! REFACTORY Una refactorización es una transformación controlada del código fuente de un sistema que no altera su comportamiento observable, cuyo fin es hacerlo más comprensible y de más fácil mantenimiento. UNIVERSIDAD TECNOLÓGICA DE DURANGO

PROGRAMACIÓN DE APLICACIONES

PATRON DE DISEÑO REFACTORY

INTEGRANTES:

ARTURO RAMOS GONZÁLEZ
RAFAEL MARTINEZ SOTO
RENE DE LA PEÑA GALLEGOS
JUAN SOSA RODRIGUEZ
ALCADIO CORTES FLORES Proceso de refactorizar VENTAJAS El proceso de refactorización presenta algunas ventajas entre las que se encuentran:

-El mantenimiento del diseño del sistema
-Incremento de facilidad de lectura
-Domprensión del código fuente
-Detección temprana de fallos
-Aumento en la velocidad en la que se programa Momentos para refactorizar PATRON DE DISEÑO REFACTORY DESVENTAJAS Para poder refactorizar de forma satisfactoria es indispensable
contar con un buen lote de casos de prueba que validen el correcto funcionamiento del sistema. Estos casos de prueba deben cumplir con los siguientes requisitos:

- Deben ser automáticos de manera tal que se puedan ejecutar todos
a la vez con simplemente “hacer clic un botón”;

- Deben ser auto verificables de manera tal de no invertir tiempo en la
verificación de los resultados de los mismos. Estos errores deben ser
reportados por cada caso de prueba;

- Deben ejecutarse de manera independiente uno del otro, de manera
tal que los resultados de uno no afecten los resultados del resto. Tanto (Fowler et al, 1999) como (Piattini y García, 2003) coinciden en que las áreas conflictivas de la refactorización son las bases dedatos, y los cambios de interfaces.
El cambio de base de datos tiene dos problemas:
los sistemas están fuertemente acoplados a los esquemas de las bases de datos y el segundo de ellos radica en la migración tanto estructural como de datos.

Se deben aplicar los cambios necesarios y luego migrar los datos existentes en la base de datos, lo que es muy costoso. Piattini y García (2003) analizan los síntomas que indican la necesidad de refactorizar, a los que Fowler et al (1999) llamaron bad smells (malos olores). A continuación se describen brevemente:
1. Duplicated code (código duplicado): Es la principal razón para refactorizar. Si se detecta el mismo código en más de un lugar, se debe buscar la forma de extraerlo y unificarlo.

2. Long method (método largo). Legado de la programación estructurada. En la programación orientada a objetos cuando mas corto es un método más fácil de reutilizarlo es.

3. Large class (clase grande). Si una clase intenta resolver muchos problemas, usualmente suele tener varias variables de instancia… lo que suele conducir a código duplicado.
4. Long parameter list (lista de parámetros extensa): en la programación orientada a objetos no se suelen pasar muchos parámetros a los métodos, sino sólo aquellos mínimamente necesarios para que el objeto involucrado consiga lo necesario. Éste tipo de métodos, los que reciben muchos parámetros, suelen variar con frecuencia, se tornan difíciles de comprender e incrementan el acoplamiento.
5. Divergent change (cambio divergente): una clase es frecuentemente modificada por diversos motivos, los cuales no suelen estar relacionados entre sí. Este síntoma es el opuesto del siguiente. 6. Shotgun surgery: éste síntoma se presenta cuando luego de un cambio en un determinado lugar, se deben realizar varias modificaciones adicionales en diversos lugares para compatibilizar dicho cambio.
7. Feature envy (envidia de funcionalidad): un método que utiliza más cantidad de elementos de otra clase que de la propia. Se suele resolver el problema pasando el método a la clase cuyos componentes son más requeridos para usar.
8. Data class (clase de datos): Clases que sólo tienen atributos y métodos de acceso a ellos (“get” y “set”). Este tipo de clases deberían cuestionarse dado que no suelen tener comportamiento alguno.
9. Refused bequest (legado rechazado): Subclases que usan sólo pocas características de sus superclases. Si las subclases no necesitan o no requieren todo lo que sus superclases les proveen por herencia, esto suele indicar que como fue pensada la jerarquía de clases no es correcto. La delegación suele ser la solución a éste tipo de inconvenientes.
Cuadernos de la Facultad n. 4, 2009 La refactorización no es una actividad que suele planificarse como parte del proyecto, sino que ocurre bajo demanda, cuando se necesita.
Existe la llamada regla de los tres strikes† (Fowler et al, 1999) que sostiene que la tercera vez que se debe realizar un trabajo similar a uno ya efectuado deberá refactorizarse. La primera vez se realiza directamente, la segunda vez se realiza la duplicación y finalmente, a la tercera se refactoriza.

-Al momento de agregar funcionalidad. Es común refactorizar al momento de aplicar un cambio al software ya funcionando, a menudo realizar esto ayuda a comprender mejor el código sobre el que se
está trabajando, principalmente si el código no está correctamente estructurado.
• Al momento de resolver una falla. El reporte de una falla del software suele indicar que el código no estaba lo suficientemente claro como para evidenciar la misma.
• Al momento de realizar una revisión de código. Entre los beneficios de las revisiones de código se encuentra la distribución del conocimiento dentro del equipo de desarrollo, para lo cual la claridaden el código es fundamental. Es común que para el autor del código éste sea claro, pero suele ocurrir que para el resto no lo es. Momentos para no refactorizar Así como existen momentos que son propicios para las refactorizaciones, existen otros que no lo son:

Cuando se dispone de código que simplemente no funciona, cuando el esfuerzo necesario para hacerlo funcionar es demasiado grande por su estructura y la cantidad aparente de fallas que hacen que sea difícil de estabilizarlo, lo que ocasiona que se deba reescribir el código desde cero. Una solución factible sería refactorizar el software y dividirlo en varios componentes, y luego decidir si vale la pena refactorizar o reconstruir componente por componente.

El otro momento para no refactorizar es cuando se está próximo a una entrega. En este momento, la productividad obtenida por la refactorización misma será apreciable solo después de la fecha de entrega. Importancia de las pruebas en el desarrollo de software Es importante mencionar la relevancia de las pruebas unitarias para el desarrollo de software ya que realizan otros aportes al margen de “comprobar que el código funciona correctamente”:

• Previenen pruebas de regresión y limitan el debug de código. En primera instancia demuestran que el código fuente funciona correctamente y, también, aportan confianza a la hora de modificar el código ya que se pueden ejecutar nuevamente y verificar si la aplicación del cambio fue correcta. Un buen lote de casos de prueba
permite detectar fallas temprano, de manera tal de poder resolverlas con antelación, y reducir el tiempo invertido en la detección de fallas.

• Facilitan la refactorización. Tal como se mencionó con anterioridad, es importante tener casos de prueba que verifiquen el correcto funcionamiento del sistema. El riesgo de introducir una falla luego de una refactorización queda reducido, ya que se pueden detectar a tiempo. Las pruebas unitarias proveen la seguridad suficiente como para facilitar la refactorización.

• Mejoran el diseño de implementación. Es la primera prueba a la que
se somete el código fuente, por lo que necesitan que el sistema a
probar sea flexible y factible de probar de forma unitaria aislada. Si el
código no es fácil de probar de forma unitaria es una señal que indica
que debe ser refactorizado.
Full transcript