Patrones de diseño

1.1 Introducción a los patrones

Como se mencionó anteriormente, un programador comienza a trabajar en un programa diseñando su modelo: compilando una lista de entidades en las que operará el programa. Y cuantas más entidades haya en el programa, más complejo será el programa.

Por lo tanto, para reducir la complejidad del programa, intentan estandarizar las interacciones de los objetos. Y aquí es donde los patrones de diseño o patrones de diseño ayudan mucho al programador . Del patrón de diseño inglés .

¡Importante! En ruso, la palabra diseño generalmente significa diseño gráfico, en inglés este no es el caso. La palabra inglesa design tiene un significado más cercano a la palabra “design” y/o “device”. Por ejemplo, el diseño de un motor no es su apariencia, sino su estructura interna.

Por lo tanto, un patrón de diseño es exactamente un patrón/patrón de diseño. Le recomiendo que deje de usar la palabra diseño en el sentido de "apariencia" por completo. Eres el futuro ingeniero de software, y para ti el diseño es exactamente diseño.

Entonces, ¿qué es este patrón de diseño? En primer lugar, un patrón de diseño es una solución estándar para un problema estándar . Una solución buena, eficaz y probada en el tiempo.

Digamos que te piden que diseñes una bicicleta, puedes hacerla de dos ruedas, de tres o incluso de cinco. Así fue, por cierto, en los albores del diseño. Pero el enfoque probado en el tiempo es sobre dos ruedas. Pero el enfoque obvio actual pasó por el dolor y los errores:

Por lo general, una plantilla no es una solución completa que se pueda convertir directamente en código, es solo un ejemplo de una buena solución a un problema que se puede usar en varias situaciones.

Los patrones orientados a objetos muestran relaciones e interacciones entre clases u objetos , sin especificar qué clases finales u objetos de aplicación se utilizarán.

1.2 Historia de los patrones de diseño

Allá por los años 70, los programadores se enfrentaban a la necesidad de desarrollar grandes programas en los que tenían que trabajar equipos completos de desarrollo. Se probaron varios métodos de organización del trabajo, pero la industria de la construcción fue la que más influyó en el desarrollo.

Para organizar el trabajo de un gran grupo de personas, se utilizaron prácticas y enfoques de la industria de la construcción. Por cierto, fue a partir de ahí que términos como ensamblaje (construcción), desarrollador de software (constructor) y el concepto de arquitectura entraron en la programación.

Y como ya puedes adivinar, la idea del patrón de diseño también se tomó de la industria de la construcción. El concepto de patrones fue descrito por primera vez por Christopher Alexander en The Pattern Language. Ciudades. Edificio. Construcción". En este libro se ha utilizado un lenguaje especial, los patrones, para describir los procesos de diseño de ciudades.

Los patrones en la construcción describieron decisiones típicas probadas por el tiempo: qué tan altas deberían ser las ventanas, cuántos pisos debería tener el edificio, qué área del microdistrito debería asignarse para árboles y césped.

Por ello, no es de extrañar que en 1994 se publique el libro “Técnicas de Diseño Orientado a Objetos. Design Patterns”, que incluye 23 patrones que resuelven diversos problemas de diseño orientado a objetos.

El libro fue escrito por 4 autores: Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. El título del libro era demasiado largo para que nadie lo recordara. Por eso, pronto todo el mundo empezó a llamarlo “libro de la pandilla de los cuatro”, es decir, “un libro de una pandilla de cuatro” , y luego incluso “libro de GoF”.

Y desde entonces, se han descubierto otros patrones de diseño. El enfoque de "patrones" se ha vuelto popular en todas las áreas de la programación, por lo que ahora puede encontrar todo tipo de patrones fuera del diseño de objetos.

¡Importante! Los patrones no son soluciones súper originales, sino, por el contrario, soluciones típicas que se encuentran con frecuencia para el mismo problema. Buenas soluciones probadas.

1.3 Lista de patrones

Muchos programadores no han aprendido un solo patrón en toda su vida, lo que, sin embargo, no les impide usarlos. Como dijimos antes, los patrones son buenas soluciones probadas en el tiempo, y si el programador no es un tonto, con experiencia él mismo encuentra tales soluciones.

Pero, ¿por qué, a través de decenas de ensayos y errores, llegar a soluciones óptimas cuando hay personas que ya han recorrido este camino y han escrito libros con la quintaesencia de su experiencia y sabiduría de vida?

Puedes martillar un clavo con una llave inglesa, pero ¿por qué? Incluso puedes usar un taladro si te esfuerzas. Pero una buena posesión consciente del instrumento es precisamente lo que distingue a un profesional de un aficionado. Y el profesional sabe que la característica principal del taladro no está en absoluto en esto. Entonces, ¿por qué necesitas saber patrones?

• Soluciones probadas. Dedica menos tiempo a usar soluciones listas para usar en lugar de reinventar la rueda. Algunas decisiones las podrías pensar tú mismo, pero muchas pueden ser un descubrimiento para ti.
• Estandarización de código. Comete menos errores de cálculo al diseñar, utilizando soluciones unificadas típicas, ya que todos los problemas ocultos en ellos se han encontrado durante mucho tiempo.
• Diccionario general de programación. Dices el nombre del patrón en lugar de pasar una hora explicando a otros programadores qué diseño genial se te ocurrió y qué clases se necesitan para esto.

¿Cuáles son los patrones?

Los patrones difieren en el nivel de complejidad, detalle y cobertura del sistema que se está diseñando. Haciendo una analogía con la construcción, puede aumentar la seguridad de una intersección colocando un semáforo, o puede reemplazar la intersección con un intercambio de automóviles completo con pasos subterráneos.

Los patrones más simples y de bajo nivel son modismos. No son universales, ya que son aplicables solo dentro del marco de un lenguaje de programación.

Los más versátiles son los patrones arquitectónicos que se pueden implementar en casi cualquier idioma. Son necesarios para diseñar todo el programa, y ​​no sus elementos individuales.

Pero lo principal es que los patrones difieren en su propósito. Los patrones con los que nos familiarizaremos se pueden dividir en tres grupos principales:

• Los patrones de creación se encargan de la creación flexible de objetos sin introducir dependencias innecesarias en el programa.
• Los patrones estructurales muestran diferentes formas de construir relaciones entre objetos.
• Los patrones de comportamiento se ocupan de la comunicación eficiente entre los objetos.

1.4 Introducción a UML

Comencemos mirando los mismos 23 patrones que se describieron en el libro Gang of Four. Tanto los patrones en sí como sus nombres son cosas familiares incluso para un programador novato. Te los presentaré, pero te recomiendo encarecidamente que leas ese mismo libro sobre patrones.

Los patrones de diseño no están vinculados a un lenguaje de programación específico, por lo que generalmente se usa UML para describirlos. Fue muy popular hace 20 años, pero incluso ahora se usa a veces. Y por cierto, la descripción de patrones es justo el lugar donde el uso de UML es el estándar.

Con UML, puede describir relaciones entre diferentes entidades. En nuestro caso, estos son objetos y clases.

Las relaciones entre clases se describen mediante cuatro tipos de flechas:

	composición (composición) - una subespecie de agregación en la que las "partes" no pueden existir separadamente del "todo".
	agregación : describe la relación "parte" - "todo", en la que la "parte" puede existir por separado del "todo". El rombo se indica desde el lado "entero".
	dependencia : un cambio en una entidad (independiente) puede afectar el estado o el comportamiento de otra entidad (dependiente). Una entidad independiente se indica en el lado de la flecha.
	generalización - la relación de herencia o implementación de una interfaz. Del lado de la flecha está la superclase o interfaz.

De hecho, todo es muy simple aquí. La última flecha en realidad significa que una clase se hereda de otra clase. Y la primera y la segunda flecha son que un objeto almacena un enlace al segundo objeto. Y es todo

Si el rombo del enlace es negro, entonces el enlace es débil: los objetos pueden existir uno sin el otro. Si el rombo es blanco, los objetos están fuertemente relacionados, como una clase HttpRequesty su clase secundaria HttpRequest.Builder.

1.5 Lista de patrones

Los tipos de patrones se denotarán con diferentes colores y letras:

B- conductual (comportamental);

C- generar (creación);

S- estructural (estructural).

Y finalmente, una lista de 23 patrones de diseño: