Esperando en secreto: análisis del modo de observador

Todos deben conocer algunos patrones de diseño, que no solo pueden reflejar las habilidades básicas de diseño y escritura de código, sino también un sitio de prueba de alta frecuencia durante las entrevistas. Aprendiendo hoy a explicar el modo observador . Mientras explica el modo específico, este artículo también enumerará los lugares utilizados en jdk y marcos comunes para ayudarlo a profundizar su comprensión.

Para el estudio de patrones de diseño, mi sugerencia es comprender primero su significado y principios de diseño que han sido resumidos y establecidos por sus predecesores. Tenga en cuenta estos conceptos.Cuando encuentre el trabajo de desarrollo correspondiente en su trabajo, debe pensar cuidadosamente, diseñar e implementar de acuerdo con los principios.El resultado final que cumple con los requisitos es a menudo la realización específica de algunos patrones de diseño.

Ejemplos de escenarios

Primero enumere una escena de combate real, use esta escena para decir cuál es el modo de observador y por qué esta escena es aplicable.

Ahora hay un sistema de aplicación de la estación de observación meteorológica, que consta principalmente de tres partes, el dispositivo físico para obtener datos meteorológicos (incluida la temperatura, humedad, densidad, etc.), WeatherData (seguimiento de los datos de la estación meteorológica y actualización del tablero de anuncios) y tablero de anuncios (que muestra el cartel Los usuarios ven).

Primero mire un ejemplo de error:

public class WeatherData {
    
    
    // 实例变量声明

    // 气象数据变化时更新对应的布告板
    public void measurementsChanged() {
    
    
        float temp = getTemperature();
        float humidity = getHumidity();
        float pressure = getPressure();
        // 更新各种布告板
        currentConditionDisplay.update(temp,humidity,pressure);
        statsticConditionDisplay.update(temp,humidity,pressure);
    }
}

En primer lugar, varios tableros de anuncios deben ser una interfaz unificada y, en segundo lugar, la actualización de los tableros de anuncios no se puede programar para implementaciones específicas, lo que hará que el programa se modifique al agregar o eliminar tableros de anuncios en el futuro.

Pensando con principios de diseño

Según este escenario, primero pensamos de acuerdo con los principios de diseño:

  • Identifique los aspectos cambiantes del programa y luego sepárelo de las partes fijas.

Los datos meteorológicos observados por la estación meteorológica en la escena cambian de vez en cuando, y el número y los tipos de tableros de anuncios cambian.

  • Para programación de interfaz, no para programación de implementación.

Esto significa principalmente que nuestro tablero de anuncios debe ser una interfaz, y el objeto meteorológico WeatherData también debe ser una interfaz unificada, que se presentará más adelante.

  • Use más combinación, menos herencia

En este caso, la relación entre el tablón de anuncios y el objeto meteorológico debe ser el tablón de anuncios combinado del objeto meteorológico Esta relación no se deriva de la herencia, sino que se genera mediante la combinación en tiempo de ejecución.

En este escenario, podemos ver que mientras el objeto meteorológico tenga cambios en los datos, todos los tableros de anuncios deben ser notificados.Este es un modelo típico de suscripción a temas, que es el modelo de observador que vamos a aprender hoy.

Tratamos el objeto WeatherDta como el sujeto y el tablero de anuncios como un observador. Para obtener información, el tablero de anuncios debe registrarse con el objeto WeatherData.

Cada tablón de anuncios es diferente, por lo que necesitamos una interfaz común. Aunque las clases del tablero de anuncios son diferentes, deben implementar la misma interfaz para que el objeto WeatherData pueda saber cómo pasarles observaciones.

Diseño del maestro

Primero, defina las dependencias de uno a varios entre objetos, de modo que cuando un objeto cambie de estado, todos sus dependientes sean notificados y actualizados automáticamente. Corresponde al objeto de asunto WeatherData en nuestro ejemplo. Cuando cambia, todos los tableros de anuncios reciben la notificación de cambio de estado y realizan su propio procesamiento comercial.

El diagrama de clases es el siguiente:

A través del diagrama de clases del patrón de observador anterior, podemos ver que los dos objetos están débilmente acoplados, pero aún pueden interactuar entre sí, pero los detalles de cada uno no están claros. El patrón del observador proporciona este tipo de diseño de objeto, lo que permite un acoplamiento flexible entre el sujeto y el observador.

¿Podrías preguntar por qué?

Respecto a todo lo relacionado con el observador, el sujeto solo sabe que el observador implementa una determinada interfaz (la interfaz del Observador). El sujeto no necesita saber quién es la clase específica del observador, qué hace y cualquier detalle.

En cualquier momento podemos agregar nuevos observadores. Debido a que de lo único que depende un tema es de una lista de objetos que implementan la interfaz de Observer, puede agregar observadores en cualquier momento.

Cuando aparece un nuevo tipo de observador, no es necesario modificar el código del tema. Lo que tenemos que hacer es implementar la interfaz del observador en la nueva clase y luego registrarnos como observador. Al sujeto no le importa nada más, solo enviará notificaciones a todos los objetos registrados que implementen la interfaz del observador.

Cambiar uno de los sujetos o del observador no afectará al otro. Debido a que los dos están débilmente acoplados, podemos cambiarlos libremente siempre que se siga observando la interfaz entre ellos.

Entonces, esto resume los principios de diseño que hemos aprendido hoy:

Trabaja duro para diseñar un acoplamiento flexible entre objetos interactivos.

Aplicación práctica

  1. El modo de observador integrado en java. El paquete java.util contiene la interfaz básica de Observador y la clase Observable. Puede usar push o pull para transferir datos.

  2. Para el modo de observador en JavaBeans en jdk, consulte la interfaz PropertyChangeListener para obtener más detalles.

  3. Piense en las colas de mensajes que usamos habitualmente, como rocketMQ, etc., que básicamente utilizan la idea del modo de observador;

para resumir

Patrón de observador: defina dependencias de uno a muchos entre objetos, de modo que cuando un objeto cambie de estado, los objetos dependientes sean notificados y actualizados automáticamente.

El próximo artículo traerá una explicación de los patrones decorados, así que estad atentos.

No es fácil ser original. Espero que puedas hacerme un pequeño favor. Si crees que el contenido de este artículo es algo que has ganado, ayúdame a hacer clic en "Estoy mirando" o reenviarlo y compartirlo para que lo vean más amigos.


Supongo que te gusta

Origin blog.csdn.net/taurus_7c/article/details/106920978
Recomendado
Clasificación