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 utilizas un entero, entonces el entero se comportara como debe comportarse en cualquier parte o cualquier momento. Por sí mismos no son un problema si se emplean dentro de las instrucciones de bajo nivel. El problema es conceptual más que físico.
Los tipos primitivos son anémicos.
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 utilizar 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 interactúan con esta «falsa entidad» deberán asumir que las propiedades están en un índice conocido, si es que están. El tamaño del arreglo puede ser conocido, o aún peor, ser de tamaño dinámico. Y el problema más 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, más 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 está 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 más 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 válido 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 está del todo completa, existen demasiadas propiedades referentes al Número del empleado que sugieren que este podría ser una entidad o un objeto de valor por sí 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 sí 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 más 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
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20