23 patrones de colaboración de componentes de diseño (TemplateMethod-Observer / Event-Strategy)

Colaboración componente

El primer resultado después de la división de las especialidades modernas de software es "la división de marcos y aplicaciones". El modelo de "colaboración de componentes" utiliza el enlace tardío para lograr un acoplamiento flexible entre marcos y aplicaciones. Se usa comúnmente en colaboración entre los dos. Modo.

Método de plantilla

Motivación

  • En el proceso de construcción de software, para una determinada tarea, a menudo tiene una estructura operativa general estable, pero cada subpaso tiene muchas necesidades cambiantes o debido a razones inherentes (como la relación entre el marco y la aplicación) La estructura general de la tarea se realiza simultáneamente.

  • ¿Cómo responder con flexibilidad a los cambios en varios subpasos o necesidades de realización tardía bajo la premisa de determinar una estructura operativa estable?

Proceso de diseño de software estructurado

Proceso de diseño de software orientado a objetos.

Unión temprana y unión tardía

Definición del patrón

  • Definir el esqueleto (estabilidad) del algoritmo en una operación y retrasar (cambiar) algunos pasos en subclases. El Método de plantilla permite a las subclases redefinir (anular) ciertos pasos del algoritmo sin cambiar (multiplexar) la estructura de un algoritmo. - "Design Patterns" GoF

Estructura

Resumen de puntos principales

  • El patrón de Método de plantilla es un patrón de diseño muy básico que tiene una gran cantidad de aplicaciones en sistemas orientados a objetos. Utiliza el mecanismo más conciso (polimorfismo de funciones virtuales) para proporcionar puntos de extensión flexibles para muchos marcos de aplicaciones, y es la estructura de implementación básica de la reutilización de código.

  • Además de poder responder con flexibilidad a los cambios en los subpasos, la estructura de control inverso de "No me llames, déjame llamarte" es una aplicación típica del Método de plantilla.

  • En términos de implementación específica, los métodos virtuales llamados por Template Method pueden tener o no implementación (métodos abstractos, métodos virtuales puros), pero generalmente se recomienda establecerlos como métodos protegidos.

Observador / Evento

Fácil de violar el principio de inversión de dependencia (DIP)

Motivación

  • En el proceso de construcción de software, necesitamos establecer una "dependencia de notificación" para algunos objetos: el estado de un objeto (objeto de destino) cambia, y todos los objetos dependientes (objetos de observación) serán notificados. Si tales dependencias son demasiado cercanas, el software no podrá resistir bien los cambios.

  • Usando tecnología orientada a objetos, puede debilitar esta dependencia y formar una dependencia estable. Para lograr un acoplamiento flexible de la arquitectura de software.

Definición del patrón

Defina una 一对多(变化)relación de dependencia entre los objetos, de modo que cuando el estado de un objeto (Asunto) cambie, todos los objetos que dependen de él se notifiquen y se actualicen automáticamente.

- "Modo de diseño" GoF

Estructura

Resumen de puntos principales

  • Usando la abstracción orientada a objetos, el patrón del Observador nos permite cambiar de forma independiente el objetivo y el observador, de modo que la dependencia entre los dos esté débilmente acoplada.

  • Cuando el objetivo envía una notificación, no es necesario especificar un observador, y la notificación (que puede llevar información de notificación como parámetro) se propaga automáticamente.

  • El observador decide si se suscribe a la notificación, y el público objetivo no sabe nada al respecto.

  • El patrón Observer es un patrón de diseño muy común en el marco de la interfaz de usuario basado en eventos y una parte importante del patrón MVC.

Estrategia

El mal olor de If-else puede considerar el modo de estrategia para el 80% del juicio de condición

Motivación

  • En el proceso de construcción del software, los algoritmos utilizados por algunos objetos pueden variar y, a menudo, cambian. Si estos algoritmos se codifican en los objetos, los objetos se volverán muy complicados y, a veces, es un rendimiento admitir algoritmos que no se utilizan. Carga

  • ¿Cómo cambiar de forma transparente el algoritmo de un objeto según sea necesario en tiempo de ejecución? ¿Desacoplar el algoritmo del objeto mismo para evitar los problemas anteriores?

Definición del patrón

Definir una serie de algoritmos, encapsularlos uno por uno y hacerlos compatibles entre sí.Reemplazar (cambiar). Este modo permite que el algoritmo cambie (expanda, subclase) independientemente del programa cliente (estable) que lo usa.

- "Modo de diseño" GoF

Estructura

Resumen de puntos principales

  • Strategy y sus subclases proporcionan una serie de algoritmos reutilizables para componentes, de modo que el tipo se puede cambiar fácilmente entre los distintos algoritmos en tiempo de ejecución.

  • El modo Estrategia proporciona una alternativa al uso de sentencias de juicio condicionales: eliminar las sentencias de juicio condicionales es desacoplar. El código con muchas declaraciones de juicio condicional generalmente requiere el modo Estrategia.

  • Si el objeto Estrategia no tiene variables de instancia, entonces cada contexto puede compartir el mismo objeto Estrategia, ahorrando así la sobrecarga del objeto.

Supongo que te gusta

Origin www.cnblogs.com/coderzjz/p/12688305.html
Recomendado
Clasificación