POODR. Notas del capítulo 3

2015-09-28
libros

CAPÍTULO 3

Este capítulo trata del manejo de dependencias. Se considera que hay una dependencia cuando una clase se ve forzada a cambiar debido a una modificación en una porción de código externa a sí misma. Al comienzo el libro nos aporta 4 maneras en las que un objeto depende de otro:

  • Conociendo el nombre de su clase.
  • Conociendo el nombre de alguno de sus métodos.
  • Conociendo los argumentos de alguno de sus métodos.
  • Conociendo el orden de dichos argumentos.
    Debemos mantener el foco en tener las mínimas dependencias posibles. Ya que cada modificación en una dependencia nos obligará cambiar y esto hará que los futuros cambios sean más difíciles y tediosos.

Se define también el acoplamiento. Entre menos conozcamos de una de nuestras dependencias menos acoplados estaremos a ellas. Un alto grado de acoplamiento dificulta la reutilización de código ya que no tienes los comportamientos bien separados. Obtienes objetos que son incapaces de ejercer su labor por sí solos. Como bien dice el libro “Terminas teniendo un conjunto de clases que trabajan como una unidad”.

Lo siguiente son una serie de técnicas con las que podemos hacer que nuestros objetos estén menos acoplados entre sí:

  • Dependency Injection: Con la inyección de la dependencia te desligas de la responsabilidad de crear objetos (desconoces cómo se crean). Simplemente los recibes. En lugar de acoplarte a un tipo de objeto concreto, aceptas aquellos objetos que cumplan el contrato que esperas. Como dice el libro “conociendo menos puedes hacer más”.
  • Isolate Dependencies: Aislar dependencias en métodos es una buena forma de posponer la extracción de un nuevo tipo de objeto. Probablemente estarás en situaciones en las que debes priorizar otras cosas. Teniendo las dependencias aisladas separa comportamientos y además mejora la comprensibilidad de nuestros métodos. Por lo que será más fácil detectar errores. Cuando podamos abordar el cambio será más sencillo e intuitivo.
  • Eliminar la dependencia del orden de los parámetros. Lo que se propone en este caso es recoger en un hash los parámetros que recibe un método (en nuestra opinión esto no es práctico en lenguajes del tipo Java, C++…). Estarás menos acoplado al método en cuestión. Además la llamada al método queda muy clara y legible. Tiene una pequeña pega. El IDE no te indicará los parámetros que el método espera recibir.
    Cuando usamos código del cuál no tenemos el control nosotros (librerías externas, API…), podemos hacer nuestros propios Wrappers. Lo cual nos permite incluso desacoplarnos de ese código externo. No debemos depender de código que no es nuestro.

Otro aspecto importante del que habla es de la dirección de la dependencia. Básicamente la regla que propone es que debes depender de cosas que cambien menos que tú. De esta manera reduces el coste de los cambios. La verdad que con esto me ha hecho reflexionar. Antes mis compañeros y yo pensábamos que debíamos intentar representar la realidad con la mayor exactitud posible en nuestro diseño. Pero ahora pienso que el principal objetivo es que nuestro software sea modificable. Seguir este tip hará que nuestra aplicación abrace la llegada de nuevos requisitos y cambios.

Con la inversión de la dependencia (Dependency Inversion) podemos redefinir la dirección de la dependencia. Aunque suene redundante es tan simple como darle la vuelta a la relación entre dos objetos.

Las abstracciones representan responsabilidades de alto nivel. Esto hace que cuando se modifiquen afecten a varias zonas, no obstante, la probabilidad de cambiar abstracciones es bastante baja. Lo ideal sería que acompañando a nuestras abstracciones tengamos clases que al cambiarlas no tengan un coste elevado. Por lo tanto, debemos evitar tener una clase que sufre cambios constantemente y, a consecuencia de esto, nuestra aplicación se vea afectada en numerosas partes.