Patrones de diseño vistos desde el punto de vista de c# y de buenas prácticas de programación
Patrones de diseño vistos desde el punto de vista de c# y de buenas prácticas de programación
El patrón de diseño Decorator 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 Decorator al español sería Envoltorio, pero prefiero no traducirlo porque es el nombre con el que se conoce.
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.
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.
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:
Quizá este sea el patrón más utilizado en programación, no solo en C#, sino en la mayoría de lenguajes.
La implementación en C# es muy sencilla y cualquiera que haya realizado una aplicación en WebForms, WinForms o WPF habrá aplicado este patrón aunque sea sin haberse dado cuenta. ¿Cómo puedo estar tan seguro? Porque la implementación en C# de este patrón son los eventos y dudo que haya programadores que no los utilicen :-)
En este post voy a explicar los conceptos y las ideas que hay detrás del patrón, mostraré diferentes versiones del patrón y finalmente implementaré un ejemplo utilizando los eventos, que es como se debería utilizar C#.
Cuando conocí los patrones de diseño ya llevaba algunos años trabajando en el sector y hasta entonces no les había dado importancia. Estaban ahí pero era un tema distante. Incluso trabajando en equipos de grandes empresas con grandes proyectos, nadie los mencionaba.
Fue leer el primer capítulo del libro “Head First Dessign Patterns” y hacer “clic”: descubrí nuevos puntos de vista y nuevas maneras de programar. Hasta entonces utilizaba clases y objetos pero no estaba aprovechando todo el potencial de los conceptos de POO (Programación Orienteda a Objetos). Cuando un problema se complicaba, o cuando había un cambio en una especificación, lo resolvía utilizando la fuerza bruta: copy-paste y tira pa’lante.
Los patrones de diseño, y en especial el patrón estrategia, me llevó a comprender y aplicar mejor algunos de los conceptos de POO.
En este post voy a explicar el patrón de diseño estrategia con el mismo ejemplo que utiliza el libro “Head First Dessign Patterns”. Una vez explicado también mostraré un caso real donde lo he aplicado.
¿Qué hay de malo en utilizar “new”?
No hay nada malo en utilizar "new", pero en el momento que lo haces estás creando un acoplamiento entre tu clase y la clase que crea la instancia. Ambas quedan ligadas para siempre.
Los patrones de factoría están diseñados para contrarrestar este efecto. Encapsulan la creación de objetos.
Hay tres patrones factoría conocidos:
En este post escribiré sobre el patrón Factoría Simple y sobre dos niveles de abstracción previos a utilizar este patrón.
El patrón de diseño Singleton fue descrito en el libro Dessign Patterns, Elements of Reusable Object-Oriented Software escrito por cuatro autores también conocidos como GoF (“Gang of four”).
La primera implementación que apareció del patrón, la del libro de GoF, es una implementación no segura en aplicaciones multi-hilo (not thread safe).
Es por ello que a lo largo del tiempo han ido apareciendo sucesivas implementaciones “thread safe” con diferentes pros y contras. En este artículo sólo mostraré implementaciones “thread safe”.