POODR. Notas del capítulo 2

2015-09-27

La lectura de este libro (Practical Object Oriented Design with Ruby) me está pareciendo muy emocionante. Una de las habilidades en las que me gustaría mejorar mucho es en el diseño orientado a objetos. A pesar del título este libro presenta prácticas y explicaciones que no son válidas sólo para Ruby sino que puede cambiar tu forma de desarrollar software independientemente de la tecnología. Muchas de las cosas que se recogen en el libro las desconocía y muchas otras las conocía pero las aplicaba porque confié en la palabra de alguien cuando me dijo que era mejor de aquella manera. Ahora poco a poco mientras me leo el libro y me encuentro con los problemas que narra en el proyecto que estoy ahora, me doy cuenta que soy más capaz de identificar los problemas. Ya no busco un sitio donde aplicar una solución que conozco sino que ahora busco problemas y una vez encontrados aplico la solución que conozco.

El libro define el diseño de software como un arte, el arte de colocar cada porción de código donde haga que nuestro software sea modificable. Debemos asumir que un proyecto software no es algo estático sino que estará evolucionando constantemente y adaptándose a los nuevos requisitos y solicitudes de un mercado/cliente. Como bien nos enseñó José Juan Hernández (profesor de Ingeniería de Software de la ULPGC) Si tu software no evoluciona! Tu software muere!

En el libro se exponen muchos conceptos, problemas y soluciones a los mismos. En este post iré escribiendo todo aquello que quiero interiorizar y que considero que debo empezar a poner en práctica desde el momento que los escriba.

CAPÍTULO 2

En el libro se define fácil de modificar con los siguientes puntos:

  • “Los cambios no deben tener efectos inesperados”
  • “Un cambio pequeño en los requisitos debe serlo también en el código”
  • “El código existente es fácil de reutilizar”
  • “La mejor forma de hacer un cambio es añadir código que sea fácil de modificar”
    También se propone seguir digamos una regla a la que denomina TRUE. Básicamente recalca que tu código debe ser Transparente (las consecuencias de un cambio deben ser evidentes), Razonable (cambiar código debe aportarte un valor proporcional), Usable (también reusable) y Ejemplar.

Tener clases con una sola responsabilidad (Single Responsibility Principle) hace que nuestro código sea más reusable y por lo tanto esto favorece al cambio. Cuando no cumplimos con el SRP obtenemos duplicidad y esto hace que añadir nuevos cambios y/o mantener nuestro código sea mucho más costoso. Para determinar si una clase tiene una sola responsabilidad puedes hacer preguntas del tipo “Coche, ¿cuál es la dirección de la carretera?” En muchos casos te darás cuenta de lo raro que suena.

Destaca también la importancia de no precipitarse a hacer cambios. Hay decisiones de diseño las cuáles pueden esperar a que tengamos más información de negocio. A la hora de diseñar no debemos presuponer cómo evolucionará nuestra aplicación ni caer en la tentación de la sobre-ingeniería. Como nos explica el libro “Puedes posponer decisiones para más adelante siempre y cuando el coste su aplicación sea el mismo que el coste de aplicarla ahora”.

Para terminar el capítulo nos expone una serie de tips con los cuáles obtendremos un código mucho más modificable. No depender de datos sino de comportamiento (tanto datos como estructuras de datos), forzar el Single Responsibility Principle incluso en los métodos (todo debería tener una sola responsabilidad. Debemos ver un método de la misma forma que una clase. Además extraer responsabilidades a nivel de métodos en muchas ocasiones nos hará descubrir nuevos objetos.