Las clases enormes son el diablo

 Cuando estamos dentro de un proyecto o nos incorporamos a un proyecto, en muy probable que nos encontremos con clases enormes de miles de líneas de código, con funciones que hacen de todo, lo que lleva a que la clase no tenga un uso único. 

Son esas clases "utilidades" o "comunes", donde se arrojan todas las funciones, porque se sigue la ley del mínimo esfuerzo, es más fácil agregar una función más a la enorme clase con doscientas o más funciones que crear una nueva clase.

Lo ideal sería dividir esa enorme clase en varias clases, cada una con un propósito, de tal vez una decena de funciones que se refieran a la misma entidad o flujo del negocio. Pero antes de empezar a diseccionar a la gigante e intentar crear miles de clases en su reemplazo, lo cual tampoco es recomendable, debemos tener en cuenta ciertos puntos:

1. Hacer pruebas y tener pruebas antes de tocar algo.

La clase puede tener muchas funciones, pero antes de mover algo, debemos tener una forma de probar que siguen funcionando antes y después de hacer modificaciones. Con eso entenderemos el comportamiento de la clase y de las funciones. Así, la refactorización se hará con confianza y servirá como documentación hasta que se tenga algo mejor.

2. Diseñar la clase dirigiendose por los datos

Los métodos que operan en la misma información deberían estar en la misma clase, para crear una nueva clase las funciones se deben agrupar por datos y comportamiento.

3. Si es dificil ponerle un nombre significativo, es una llamada de alerta

Si tenemos una clase y la única idea para bautizarla es "común" o "utilidades", definitivamente es candidata para ser dividida en clases más pequeñas.

Una clase debe ser pequeña, tener una única razón de cambio y lograr una funcionalidad.

Una clase grande y que hace mucho, indica que debe ser dividida en clases enfocadas.

4. Encapsulación a través de la composición

Lo que nos de mejor practicidad debe ser elegido, por ejemplo composición sobre herencia.

Deben usarse objetos para representar comportamientos o estados de modo que se puedan componer otros más grandes, evitando en lo posible hacerlo vía herencia.

5. Validar las entradas de las interfaces públicas

Cuando tus métodos necesitan aceptar entradas de otras partes de tu código, nunca confiar en que se está recibiendo los parámetros de forma correcta.

Siempre hay que validar que cumple con los requerimientos del método.