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.