“Bad Smells” en código

1. “Bad Smells” en código M.C. Juan Carlos Olivares Rojas Febrero 2011

2. Agenda • Código Duplicado • Métodos grandes • Clases grandes • Lista de Parámetros excesiva • Características de la “envidia”

3. Agenda • Sentencias Switch • Jerarquías de Herencia Paralelas • Campos Temporales • Encadenamientos de mensajes

4. Agenda • Clases alternativas con diferentes interfaces • Librerías de clases incompletas

5. aprenderá e identificará los malos hábitos de codificación (bad smells), conociendo así los errores que generalmente se cometen al desarrollar código. Competencia Específica

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

7. Código Duplicado

8. Un “bad smell” es una mala práctica de programación que debe de ser eliminada para que el código sea más legible y por ende más mantenible. • Los refactoring funcionan como desodorante permitiendo que sea mejor la programación. Bad Smells

9. Si algo huele mal… • Muy probablemente este mal. • La codificación deficiente trae consigo una serie de características que la evidencian rápidamente. Badsmell

10. Los “malos olores” son visto como signos de debilidad del código. • En general, para cada “mal olor” existe una serie de refactorings propuesto para solucionarlos. Badsmell

11. Malos Olores

12. Es el principal indicador de un malor olor. • ¿cómo detectamos código duplicado? Código Duplicado

13. Misma expresión en dos métodos de la misma clase. • Misma expresión en dos subclases hermanas. • Códigos que sean similares, pero no iguales. Código Duplicado

14. Métodos que hagan lo mismo con diferente algoritmo. • Duplicidad de código en dos clases independientes. • La gran mayoría de los “Bad Smells” se da por la “codificación excesiva” Código Duplicado

15. La codificación excesiva se da por muchas razones: malos hábitos de programación, presión del tiempo de desarrollo, etc. • La decisión de reestructurar código depende de los desarrolladores. Código Duplicado

16. Aunque no está enfocado directamente con la codificación, es el principal mal olor en la implementación del software. • Generalmente no se hace diseño y cuando llega a hacerse se hace muy superficial sólo por cumplir el requerimiento. Mal Diseño

17. En un diagrama de clases en UML es posible verificar algunos indicadores de malos olores y poder reestructurarlos antes de codificarlos. Mal Diseño

18. Existirán indicadores que no son muy visibles en el modelado como los métodos largos o el código duplicado. • Se pueden utilizar otros diagramas de UML como los de secuencia, actividades, estados, etc. Mal Diseño

19. Práctica 3

20. TDD (Test-Driven Development) es una metodología de diseño la cual consiste en codificar en principio las pruebas unitarias del código. • Se diseñan todos los posibles casos de prueba y se verifican sus resultados. Práctica 3

21. Se codifican las pruebas unitarias y hasta que no se pasen al 100% el programa no puede terminar. • Nótese que al inicio las pruebas no pueden correrse hasta que se ejecute el código. Práctica 3

22. Los malos olores también pueden ser determinados a través de herramientas automatizadas, generalmente conocidos como analizadores de códigos. • Una herramienta popular es PMD que puede analizar código escrito en Java Código Duplicado

23. ¿Si se codifica bien desde el principio no se tendría que reestructurar el software? • Sólo serían muchos menores los cambios • La solución para el buen desarrollo de software son los patrones de diseño. Patrones de Diseño

24. Es una solución bien documentada que los expertos aplican para solucionar nuevos problemas porque han sido utilizadas con éxito en el pasado. Patrones de Diseño

25. Los patrones suponen una evolución en abstracción y reutilización del software. • Los patrones de diseño están basados en esquemas que funcionan. ¿Cómo es una casa estilo americano? Patrones de Diseño

26. Realizar un programa que permita que un momento dado uno y solo un objeto pueda estar en ejecución (no se permiten dos o más ejemplares). • La utilización de patrones puede resolver este problema. Caso de ejemplo: Singleton Patrones de Diseño

27. Problema: se admite exactamente una instancia de una clase. Los objetos necesitan un único punto de acceso global. • Solución: Defina un método estático de la clase que devuelva el Singleton Singleton

28. Singleton

29. Singleton public class Singleton { private static Singleton INSTANCE = null; private Singleton() {} private synchronized static void createInstance() { if (INSTANCE == null){ INSTANCE = new Singleton(); } }

30. Patrón de Diseño de un Menú

31. Actividad • Realizar el análisis del programa Criba cn la herramienta PMD a nivel máximo y tratar de minimizar la mayor cantidad de errores posibles

32. Actividad • Modificar el patrón singleton para que permita que un objeto se pueda crear un número específico de veces (por ejemplo de 3 a 5) • ¿Cómo quedaría dicho patrón? • Tarea: traer un programa con orientación a objetos de más de 200 LOC. Mañana por e-mail antes de las 13:00 horas.

33. Métodos Grandes

34. El tener métodos grandes trae consigo muchas consecuencias como el hecho de que es menos reusable y más dificil de leer. • Se recomienda que los métodos no sean mayores a 24 líneas Métodos grandes

35. El número de líneas puede ser variable pero se recomienda que se pueda leer en una sola pantalla. • Es deseable que los métodos no sea tan cortos para evitar el seguir el flujo del programa Métodos grandes

36. Extract Method es el refactoring más popular para malos olores como código duplicado y métodos grandes (casi el 99% de la solución es este refactoring) Extract Method

37. El nuevo método que se ha extraído contiene el código seleccionado y el código seleccionado del miembro existente, se reemplaza por una llamada al nuevo método. Extract Method

38. Extract Method

39. Clases Grandes

40. Clases Grandes • En la gran mayoría de las ocasiones, una clase grande es sinónimo de código duplicado o que la clase está realizando más acciones de las debidas. • ¿cómo sabemos que una clase es grande?

41. Clases Grandes • Las clases no son grandes por el tamaño de su código ni por su número de elementos. • Se debe verificar que la clase realice solo las acciones necesarias. Por ejemplo que no mezcle E/S con la lógica de la aplicación.

42. Antipatrones de Diseño • Antipatrón es un patrón de diseño que invariablemente conduce a una mala solución para un problema. • Al documentarse tanto los antipatrones como los patrones de diseño, sirven de base para no escoger malos caminos, partiendo de documentación disponible en lugar de simplemente la intuición.

43. Antipatrón BLOB • Mejor conocido como “objeto todopoderoso”. Se presenta cuando una clase es muy grande tanto en atributos y/o en métodos.

44. Antipatrón BLOB • Entre más grande son las clases es más difíciles de mantener, reusar y probar. Su gran tamaño puede perjudicar el tiempo de carga. Generalmente son el resultado de un mal diseño o de sistemas legados.

45. Antipatrón BLOB

46. Antipatrón BLOB

47. Antipatrón BLOB

48. Antipatrón BLOB • Algunos autores consideran al Singleton (Simplicidad) un ejemplo de un antipatrón ¿por que?

49. Antipatrón BLOB • Dificulta las pruebas de código ya que promueve un alto acoplamiento. • La clase controla su propia creación cuando esta no debe de ser su responsabilidad.

50. Antipatrón BLOB • Se recomienda utilizar el patrón de diseño Factory para crear objetos. • En general su naturaleza estática y pública no son del todo bien vistas.