Code Smells: ¿Que es la obsesión con los tipos primitivos?.

Los tipos primitivos son los tipos de datos o estructuras de datos  de base con las que dispone un lenguaje de programación o plataforma. Texto, números, fechas, caracteres,  bytes, operadores lógicos, etc. En un bajo nivel te permiten llevar un flujo del programa adecuado y también representan un estándar mínimo para cualquier programador que usa el lenguaje. Si usas un entero, entonces el entero se comportara como debe comportarse en cualquier parte o cualquier momento. Por si mismos no son un problema si se usan dentro de las instrucciones de bajo nivel. El problema es conceptual mas que físico.

Los tipos primitivos son anemicos.

Los primitivos tienden a simular ser un concepto de alto nivel (en un mal modelado), sin llegar a serlo en ningún momento. Por ejemplo:

Se quiere usar un arreglo de strings para representar a un empleado. Es un modelo débil desde el principio. En todo momento los métodos y clases que interactuan con esta ” falsa entidad” deberán asumir que las propiedades están en un indice conocido, si es que están. El tamaño del arreglo puede ser conocido, o aun peor, ser de tamaño dinámico. Y el problema mas grave, el modelo no explica nada a un posible lector. Un método que trate con este primitivo podría lucir así:

En el ejemplo anterior se puede deducir cierto comportamiento, mas no se explica nada. La entidad debería de poder notificar sus estados internos sin necesidad de elementos externos. Tener métodos que verifiquen o procesen primitivos como entidades tienden a duplicar código o generar bugs dado que todo esta sujeto a interpretación, no hay certeza.

Promover un primitivo a entidad.

No siempre es obvio cuando un primitivo debe ser considerado como entidad o cuando es innecesario. En tu trabajo diario vas a notar conceptos que se repiten y están presentes con el mismo significado en varias zonas del sistema. Estos son candidatos a dejar la representación primitiva por una representación que aporte mas valor conceptual a las reglas de negocio. Como todo en la codificación, no hay una receta que te sirva para todos los casos y es valido tener primitivos que actúen como entidades en el modelo, siempre y cuando tengan poco o nulo peso en el mantenimiento de la solución.  Vamos a convertir el primitivo del ejemplo anterior en una entidad.

La refactorización anterior es truculenta a propósito. No esta del todo completa, existen demasiadas propiedades referentes al Numero del empleado que sugieren que este podría ser una entidad o un objeto de valor por si mismo. Que tan conveniente sea este nivel de detalle depende de las necesidades de negocio. No hay modelado perfecto, solo modelados funcionales o no funcionales.

Los conceptos de alto nivel y el lenguaje ubicuo.

Las reglas de negocio siempre deben buscar representarse a si mismas con conceptos de alto nivel, conceptos que existen en el mundo real y representan al negocio de la empresa. Al tener conceptos que se reflejan en el mundo real, con los términos que usan los expertos del dominio de problema cada cambio o ajuste requerido tiene mas posibilidades de éxito. Tanto el programador como el experto hablan el mismo lenguaje y expresan las mismas ideas, las posibilidades de éxito se incrementan y los costes de mantenimiento se reducen. Un gran productor de desperdicio de las áreas de desarrollo es la mala interpretación de los requerimientos. Hay que tener mecanismos que impidan ambigüedades en el conocimiento.

Autor imagen: Images & Culture

Gustavo Sánchez