En esta entrada me gustaría hacer una breve introducción a Object Calisthenics, y en las próximas iré introduciendo cada una de las 9 reglas que Jeff Bay presentó por primera vez en su libro The ThoughtWorks Anthology.
Object se refiere a la programación orientada a objetos y Calisthenics, se refiere a Calistenia, que según la RAE significa
Conjunto de ejercicios que conducen al desarrollo de la agilidad y fuerza física.
Por lo que ambas palabras unidas en el contexto de la programación orientada a objetos se podrían llegar a entender como “ejercicios de programación que te pueden ayudar a interiorizar las bases de un buen diseño orientado a objetos“, añadiendo a esto un buen sistema de práctica para poder desarrollar un código mas legible, limpio y entendible.
Personalmente aconsejo ir poniendo primero estas buenas prácticas en base a la refactorización de código mediante Katas, y una vez tengamos una soltura mínima pasemos ya a practicarlo en un proyecto real, pero tengamos en cuenta las siguientes premisas si vamos a refactorizar un código productivo:
Usar refactorizaciones seguras en base a una herramienta del estilo a ReSharper.
Tener en dicho proyecto una buena cobertura de Test, los cuales nos van a permitir en todo momento cerciorarnos que la refactorización que estamos realizando es totalmente segura.
De otro modo, si vamos a poner en práctica estos ejercicios en un proyecto o evolutivo nuevo se ha de tener en cuenta siempre realizar una buena Suite de Test.
Según Jeff Bay en su libro definió 9 reglas básicas a poner en práctica cuando se realizan estos ejercicios:
Un nivel de indentación por método
No usar la palabra clave Else.
Envolver todos las primitivos y Strings en clases.
Colecciones como clases de primer orden.
Aplica la Ley de Demeter
No abreviar.
Todas las clases deben tener menos de 50 líneas.
Evitar más de dos atributos de instancia
Evitar getters/setters o atributos públicos
En mi experiencia personal, he ido poco a poco adquiriendo estas 9 reglas en mi día a día en mi ámbito laboral y he conseguido con el tiempo poder llegar a desarollar un código mas simple, limpio y entendible en todos los sentidos.
Hay que tener en cuenta que no siempre es posible al 100% seguir estas 9 reglas, pero al menos si saber identificarlas, y comento que no es posible seguirlas al pie de la letra, ya que muchas veces evitando un Code Smell generamos otro o bien por como esté implementado el negocio, o bien por como esté estructurado el código no es posible refactorizar de una forma rápida y limpia. Cada caso es distinto y hay que saber identificar el cuándo, el cómo y si realmente merece la pena aplicar cualquiera de estas 9 reglas en cada caso concreto.
En mi próxima entrada voy a ir haciendo una introducción de como identificar en una kata cada una de estas 9 reglas, ya que en proyectos de refactorización lo primero que recomiendo es identificar los Object Calisthenics existentes antes de refactorizar nada.
