En esta entrada vamos a ver la séptima regla de Object Calisthenics que dice literalmente “Keep all entities small”, es decir “Mantén las entidades pequeñas.”,

¿Y esto que significa y por qué?

Esta regla se basa principalmente en cuatro premisas:

• No crear clases de mas de 50 líneas.
• No mas de 10 ficheros por paquete.
• 5 líneas por método o función.
• 2 argumentos por método o función.

No crear clases de mas de 50 líneas:

Como siempre hemos comentado, no es una regla que haya que seguir al pie de la letra, ni tomárnosla tan enserio, hasta el punto de ir quitando llaves por todo el código, o refactorizar con el único propósito que de que nos queden 50 líneas. Y tampoco quiere decir que si terminamos teniendo una clase de 60/70 líneas esté mal, o no sea funcional.

Lo que principalmente por un lado quiere expresar esta regla, es que una clase de mas de 50 líneas, es un claro Code Smell de que la misma tiene mas responsabilidad de la que debería tener, es decir, que hace mas cosas de las que debería hacer, y esto es algo que muchas veces confundimos algunos programadores, y algunas veces nos cuesta saber delimitar la responsabilidad de una clase ( al menos en mi caso ). Os pongo un ejemplo, como siempre con los Robots, aunque esta vez sin código de ejemplo asociado.

Supongamos que nuestros ya famosos Robots, los cuales van andando por el mundo, van recolectando basura tirada por el suelo donde la encuentran, y una vez recolectada la han de depositar en un contendor de un centro de reciclado. En este supuesto caso los Robots simplemente recogen basura, la transportan y la depositan en un contenedor del centro de reciclado, y esa sería su única responsabilidad, eso es lo único que se debería manejar en la clase Robot.

El Robot no debe comprobar si el contenedor está lleno o vacío, ni ha de vaciar el contenedor cuando esté lleno, no es su responsabilidad, eso es responsabilidad del centro de reciclado. Si le damos esa responsabilidad a los Robots en su clase, muy posiblemente habremos creado una clase de mas de 50 líneas, y muy posiblemente estaremos violando el famoso Principio de Responsabilidad Única de los principios SOLID, y digo posiblemente, pues podría ser que no.

¿ Y si tengo mas de 50 líneas violo el Principio de Responsabilidad Única?

Pues no, no necesariamente, pero si es un claro Code Smell de que probablemente tu clase haga mas de una cosa, y hemos de revisar la clase, tratar de refactorizar para llevarnos ciertas responsabilidades a otras clases, o tratar de dividir responsabilidades para no hacer una clase con muchos métodos, muchos parámetros pasados por valor a métodos muy extensos y que también tengan mas de una responsabilidad, por lo que tendremos una clase muy larga y difícil de entender.

No mas de 10 ficheros por paquete:

Para que una clase pequeña tenga mas significado hemos de crear diferentes ficheros dentro de un mismo paquete, y así el conjunto de clases tendrá un significado con mas sentido. Pero hemos de tener en cuenta no crear mas de 10 ficheros por paquete, lógicamente no pasa nada si tenemos 11, pero al realizar esta limitación, podremos ir viendo este grupo de paquetes como grupos de clases que juntas tiene un objetivo común a todos.

5 líneas por método o función:

Para los métodos, hemos de aplicar la premisa de tener 5 líneas por método o función, y es por el mismo motivo, un método de mas de 5 líneas, es un claro Code Smell de que hace mas de una cosa, y cada método debería tener una única responsabilidad dentro de su clase.

2 argumentos por método o función:

Creo que este punto lo he comentado en alguna ocasión, y al final si pasamos mas de 2 argumentos a un método o función, vamos a tener un Code Smell denominado Primitive Obsession, y deberíamos tratar de refactorizar esos primitivos a un Objeto o estructura de datos común, ya que esto muchas veces nos va a hacer que nos demos cuenta que a ese nuevo Objeto que hemos creado se le pueden dar responsabilidades que teníamos en nuestra clase.

De momento no voy a exponer ejemplo de código ya que sobre este Code Smell escribiré una entrada para poder plasmaros mejor esta solución, y veremos un ejemplo muy parecido en la siguiente entrada.

¿ Vosotros que opináis ? ¿ Veis práctica esta regla ?

Dejadme vuestra opinión en comentarios.