Desde hace aproximadamente 2 años los compañeros de la comunidad y yo, estamos predicando y divulgando la importancia de un código limpio, fácil de leer, fácil de mantener, con test y el gran reto: que sea comprensible para cualquier programador que tenga la fortuna/desgracia de recibir como legado nuestro trabajo.

Pero fue hace tan solo 2 semanas o algo así que nos topamos con la Calistenia de Objetos, aunque suene casi a chino, la realidad es que todas y cada unas de sus partes son puro sentido común, empecemos:

Calistenia:

1. f. Conjunto de ejercicios que conducen al desarrollo de la agilidad y fuerza física.

La Calistenia de objetos son ejercicios para el programador que se formalizan en nueve reglas, las cuales tienen como objetivo que se escriba un código Sostenible, legible, testeable y comprensible. Las reglas fueron acuñadas por Jeff Bay en el libro The ThoughWorks Anthology.

Antes de definir cada regla es importante entender que ante todo debemos ser pragmáticos y saber adoptar las reglas en su justa medida y en su justo momento, no son un dogma ni una solución Salomónica.

Sin más vamos a por la definición de la reglas:

Definiciones:

La realidad es que muchos de los casos en los que se necesita un if/else o un swich se pueden resolver aplicando el polimorfismo (Patrón Strategy) o usando estructuras de datos como un mapa o un array clave-valor.

Si tu variable primitiva tiene algún tipo de comportamiento entonces es obvio que debe ser encapsulada, por ejemplo, el dinero o el tiempo (horas, dia, etc)

Ahora, de esta manera, cada colección y su comportamiento quedan encapsulados en su propia clase.

Sin embargo, el hecho de poner más de un punto (flecha) por linea en muchas ocasiones es indicativo del antipatrón Message Chain.

Un ejemplo con una imagen que además tiene en cuenta la regla 3:

Yo aún no he conseguido averiguar por que el motivo de limitarlo a dos, lo que si estoy seguro es que cuando te propones hacer el refactor de un código para aplicar esta linea lo que optienes son clases mucho más claras, faciles de manejar y que normalmente también cumplen la regla 3. Dos pájaros de un tiro.

Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.

— Alec Sharp

Cuando un accesor se limita a contar el estado de un objeto, entonces es correcto por que ese es su propósito. Sin embargo y en muchas ocasiones lo que vemos es que se usa el accesor para consultar el estado y en función de eso tomar una decisión.

Por ejemplo:

No tiene sentido utilizar los accesores de esa forma si podemos hacer lo siguiente:

Desde mi punto de vista todas y cada una de las reglas son útiles y además aplicables en un entorno real desde el momento que se conocen, si bien es posible que la aplicación conjunta de todas las reglas pueda ser muy complicado, conviene recordar que el objetivo no es aplicarlas todas a la vez ni aplicarlas como si fueran un dogma o un mandamiento obligatorio. Es importante recordar que uno de los factores más importantes del desarrollo software es el contexto y la realidad es que el único que puede manejar el contexto y como lo mejoran estas reglas es el desarrollador que se encuentra sentado con el teclado tratando de crear buen código.

También añadir que desde mi experiencia personal todas y cada una de las reglas han mejorado mi habilidad como programador y han ayudado a que me comunique mejor con otros colegas de profesión.

Fuente: http://williamdurand.fr/2013/06/03/object-calisthenics/