Practical Object Oriented Design in Ruby – Creando interfaces flexibles

Me tomó un tiempo exagerado escribir el resumen de este capítulo por diversas razones. Lo importante es que fue por una buena causa. Este capítulo me costó trabajo de digerir, muy probablemente por mi falta de conceptos sólidos en programación orientado objetos, pero sin duda ha cambiado ya la forma en que genero el código con el que trabajo todos los días.

Básicamente habla de interfaces, explicando con lo más básico a que se refiere el significado de la palabra y concretamente que clase de interfaces estaríamos hablando en Ruby para este capítulo. Un tipo de interfaz son aquellos métodos definidos en una clase para ser utilizados por otras clases. Otra alternativa es aquella que se define para que se pueda utilizar de manera independiente a cada clase. El primer tipo es al que refiere este capítulo.

El ejemplo de una interfaz de la vida real podría ser el switch de un vehículo, donde esta interfaz nos permite tomar el control del carro para maniobrar, mover o utilizarlo, sin saber necesariamente que es lo que pasa una vez que giras la llave y es encendido.

Otro ejemplo que si viene en el libro es el de una cocina de restaurant, en la que los comensales utilizan el menu como interfaz, a razón de que ellos no saben que pasa exactamente en la cocina cuando piden un platillo.

De la mano de esto, y enfocandonos en que una interfaz permite acceder a un recurso o a un servicio a través de un punto definido sin saber exactamente que sucede detrás. El exceso de conocimiento resulta en objetos que son fina y explicitamente ligados donde única y exclusivamente pueden hacer únicamente lo que esta definido actualmente.

Invocando nuevamente a los conceptos básicos de responsabilidad única y de baja dependencia entre objetos, nos habla además de que parámetros tenemos que pensar a la hora de diseñar nuestra aplicación para establecer si escogeremos una interfaz pública o privada.

La primera, la pública nos debe hacer pensar que es sólida es decir no tiene o no tendrá tantos cambios durante la vida del desarrollo y mantenimiento de la aplicación, es decir será la que menos cambie.

Por otro lado, las interfaces privadas, las tendremos que utilizar para aquellos métodos que de antemano podemos vislumbrar cambios constantes, esto claro a consideración de la información disponible al momento de definirse.

Este capítulo nos habla además de un recurso poco utilizado en Ruby, los diagramas de secuencia. Que no son otra cosa que una herramienta del conjunto de UML (Lenguaje Unificado de Modelado). Es decir nos regresa a las bases de diseño orientado a objetos.

Durante todo el capítulo pone énfasis en pensar acerca de los mensajes que los objetos intercambian, más incluso, que los objetos en si. Ya que estos nos permitiran visualizar de mejor manera y más importante de manera sencilla la mejor arquitectura alrededor de la construcción de nuestro código.

Estos diagramas de secuencia nos dan una idea simple de que intención tenemos con la interacción o intercambio de mensajes entre objetos. El contexto que un objeto espera tiene un efecto directo en que tan difícil será hacerlo reutilizable. Esto asumiendo claro que cada método o integrante de una clase debe ser pensado para tener una sola responsabilidad y vigilar además que no interactúe más allá de un objeto en si.

En otras palabras, buscar en la manera de lo posible respetar la Ley de Demeter, en la que es importante no hacer que un método sepa más de lo necesario o interactue con demasiados métodos de una sola vez.

Esto es aunque sea largo el resumén de este capítulo, sin duda inmediatamente te da acciones a tomar en el siguiente fix o requerimiento a desarrollar.

Bienvenidas sus experiencias y opiniones.