En otra ocasión diseñamos una aplicación de gestión de un almacén de repuestos, donde nos encontramos con este diagrama de clases en una parte del diseño:
Se trata de dos estructuras muy similares, pero no es esto lo que nos sugiere la existencia de un patrón. Sino el papel que juegan estas estructuras en el diseño. Y, en efecto, dicho papel se repite en ambos casos:
- Factura es algo que se compone de varias Líneas de factura, y además, las líneas de factura no tienen sentido sin la existencia de la Factura.
- Almacén es algo que se compone de Repuestos, y además, los repuestos requieren la existencia de un Almacén.
Hemos dado con un patrón de diseño, se trata de una idea: un objeto que almacena otros objetos, y éstos últimos no tienen sentido sin su "almacén". Se trata del patrón "Continente-Contenido":
Pero no es el único patrón que podemos encontrar:
- Línea de Factura es un objeto que se compone necesariamente de Concepto, Cantidad y Precio..
- Repuesto es un objeto que se compone necesariamente de Pieza, Garantía y Precio.
Aquí hay otra idea que se puede generalizar: un objeto que se desglosa en otros objetos. Podríamos llamarlo el patrón "Objeto-componente":
Cuando nos enfrentamos a un nuevo problema intentaremos aplicar los patrones que conozcamos, y esto no es una sugerencia, sino el comportamiento natural de todo ser humano. Por otra parte, es muy importante tener en cuenta
que los patrones no sólo surgen y se aplican a diseños diferentes. Un mismo patrón puede aplicarse varias veces en un mismo diseño.