Qué bonito y al mismo tiempo qué sencillo, bonito y barato.
function string GetTipoMarca(int idMarca)
{
// acciones pertinentes para retorna el tipo de marca
// relacionado al id pasado por parámetro, los tipos se devuelven como
// strings “Mercedes”, “Seat”, “BMW”
}
vs
function TipoMarcaEnum GetTipoMarca(int idMarca)
{
// acciones pertinentes para retorna el tipo de marca
// relacionado al id pasado por parámetro, los tipos se devuelven como
// un tipo enumerado que tipifica los valores “Mercedes”, “Seat”, “BMW”
}
Es un pequeño detalle, pero mejoramos así la encapsulación, la abstracción, el mantenimiento, el coste del cambio… ¿Tanto esfuerzo cuesta entonces no olvidarse de estos detalles cuando se está construyendo?
Saludos.
Miguel.
Interesante. Ahora bien, tengo una duda. Normalmente, las aplicaciones de gestión se apoyan en una base de datos.
Sobre éste escenario de la base de datos, parece claro que habrá una tabla “Marcas” que estará relacionada con otras tablas (modelos, coche, …). Al ver el ejemplo que pones, que recibe como entrada un entero idMarca que, seguramente, sea la key de la tabla Marcas. Si mi tabla “Marcas” seguramente almacene como mínimo dos campos: “idMarca” y “NombreMarca”… de verdad me resulta interesante tener en el código un enumerado con todas los nombres de las marcas? ¿No resulta más interesante consultar la base de datos, que tendrías que consultarla igual, y devolver directamente el string almacenado en el campo “NombreMarca”?
¿el efecto sobre la encapsulación es el mismo?
Un saludo y gracias por el post, hace pensar 😉
luiX,
El mezclar el ejemplo con un típico contexto de base de datos la verdad es que como bien apuntas puede inducir a confusión, ya que representa una típica consulta a datos.
El artículo intentaba plasmar el uso de tipos enumerados para aumentar la abstracción y minimiza el coste del cambio, tal vez con un ejemplo que no supusiera un típico acceso a base de datos hubiera sido mucho más acertado.
Saludos y gracias por el apunte.
Miguel.