El patrón de diseño Builder es uno de los veintitrés patrones descritos en el libro "Design Patterns: Elements of Reusable Object-Oriented Software" de los autores conocidos como Gang of Four (GoF).
En este post voy a explicar todo lo que hay que saber sobre el patrón desde un punto de vista c#.net.
La traducción de Builder al español sería Constructor, pero para no confundir con el constructor de una clase y para relacionarlo con el nombre por el cual se conoce, prefiero no traducirlo.
Aquí estan las lecturas que me han parecido interesantes este mes sobre el mundo de la programación en c#.net.
Hará unos 5 años que me uní a un equipo de programación para extender las funcionalidades de un CRM.
Uno de los compañeros me espetó:
Aquí programamos en español, si programas en inglés no se entiende nada.
Mi primera reacción fue de rechazo: toda la documentación en internet está en inglés, cualquier proyecto con el que te encuentres estará en inglés, hay multitud de palabras que no son traducibles, etc. Me parecía algo retrógrado.
Pero tras pensarlo detenidamente, tampoco era un idea tan descabellada, escribir código es como escribir en un lenguaje, ¿por qué no escribirlo en el propio?
En este post voy a explicar mi experiencia programando en español, ventajas y desventajas y cómo decido al final el idioma que utilizaré.
Aquí estan las lecturas que me han parecido interesantes este mes.
Esta es mi selección para este mes.
Muchas veces estoy trabajando y le pregunto a mi mujer (compartimos despacho): ¿tú cómo llamarías a algo que hace X en un contexto Y?
Poner un nombre en programación es un proceso que hay que tomarse seriamente y cualquier ayuda, punto de vista o idea es bienvenida para seleccionar el más adecuado.
"En software los nombres están en todas partes. Ponemos nombre a las variables, a las funciones, a los argumentos, a las clases y a los paquetes. Ponemos nombre a los archivos de código fuente y a las carpetas que los contienen. Ponemos nombre a nuestros ficheros jar, war y ear. Ponemos nombres y nombres y más nombres. Lo hacemos tantas veces que sería deseable hacerlo bien” Robert C. Martin
En este post voy a recordar la primera regla que Robert C.Martin propone para generar buenos nombres y comentar algunas de las experiencias que he tenido al aplicarla.
Inspirándome en el blog Variablenotfound de José M. Aguilar voy a iniciar una recopilación de enlaces que me han resultado interesantes.
En este post, que es una continuación de "El patrón Comuesto (Composite) en C#", voy a implementar un ejemplo del patrón a partir de un desarrollo que realicé para una empresa de producción industrial.
Consistía en crear un módulo para calcular los costes de productos formados por conjuntos de otros productos.
Inicié el desarrollo del módulo partiendo de la premisa Código Primero y apoyándome en el ejemplo canónico explicado en el post anterior.
Cuando nos encontramos frente a un problema de desarrollo podemos atacarlo de tres modos diferentes:
Históricamente la mayoría de problemas de desarrollo se han atacado utilizando el modo “Datos primero”. Me atrevería a decir que, aún a día de hoy, esta es la manera más utilizada.
Sin embargo la tendencia está cambiando y el modo “código primero” va adquiriendo cada vez más adeptos.
En este post voy a explicar algunas ventajas y desventajas de las diferentes maneras en las que podemos afrontar problemas de desarrollo.
Recientemente me encargaron desarrollar un módulo para calcular los costes de productos formados por conjuntos de otros productos. Lo primero que me vino a la cabeza cuando me explicaban los requisitos fue el patrón Compuesto (Composite).
El patrón me resultó útil con el planteamiento inicial, pero iba a tener que trabajar más allá de él para entregar una solución completa.
Este post forma parte de una serie de tres: