2011-06-29 12 views
5

Las referencias (Patrones de diseño de GOF, patrones de diseño de Head First, http://www.dofactory.com/Patterns/PatternObserver.aspx) que he leído con respecto al patrón de diseño del observador estipulan que el sujeto concreto hace referencia al observador concreto. Al igual que esta:Patrón de diseño del observador: sujetos de hormigón y observadores

class ConcreteObserver : IObserver 
{ 
    ConcreteSubject concreteSubjectInstance; 
    //other code, etc. 
} 

Ahora, si el sujeto concreto es en sí implementa una interfaz sujeto (o se deriva de alguna clase de sujeto abstracto) por qué no hacer el tipo en el ConcreteObserver ser de que abstraen/interfaz? Es decir.

class ConcreteObserver : IObserver 
{ 
    ISubject concreteSubjectInstance; 
    //other code, etc. 
} 

Por otra parte, ¿por qué no lo convierten en un campo en el (por ejemplo) IObserver interfaz?

En última instancia, dado que el patrón en sí mismo parece aflojar el acoplamiento del sujeto a sus observadores, ¿por qué parece que esto no se promueve al acoplar un observador a su sujeto?

enter image description here

O es? Solo estoy basando esto en ejemplos que he leído.

+0

Indique sus 'referencias'. – Nix

+0

@Nix: Listo. Me pareció suficiente referirme a los libros por su nombre sin vincular, ya que son bastante conocidos. –

+0

Uno de los ejemplos que publicó DOFactory muestra el uso de una clase abstracta? – Nix

Respuesta

6

Utilizando su imagen, su "actualización()" método no recibe ninguna información sobre el estado del sujeto, por lo que, si el observador necesita información acerca de este estado (como es habitual en el patrón de observador), entonces debe recuperarlo de ConcreteSubject invocando al método "GetState()" (no presente en ISubject).

Una alternativa a este esquema sería pasar el estado (o una referencia a todo el objeto ConcreteSubject) como parámetro del método "update()".

Otras explicaciones generales a que tienen una referencia a ConcreteSubject en lugar de ISubject puede ser que es posible que desee interactuar con el ConcreteSubject para invocar la lógica de negocio (por supuesto no expuestas en la interfaz ISubject).

+0

'Pasando como un parámetro para el método de actualización': supongo que también podría ser un parámetro para el constructor del observador. –

+0

Sí, para establecer la referencia interna, debe hacerse en el constructor. Pero si no mantiene una referencia interna, aún puede recibir en cada invocación "update()". Esta es la forma en que funciona la implementación del patrón de observador integrado de Java. – edutesoy

2

El hecho de que la definición que lee declare subject holds a reference to the concrete observer no significa que tenga que leerlo literalmente.

Siempre que el sujeto tenga una referencia/enlace con el observador, ya sea concreto o mediante una interfaz/clase, la declaración permanece verdadera.

Es muy común ver una interfaz en ambos lados, IObserver e IObservable. Creo que el problema que vas a encontrar es que cuando hagas el resumen del tema realmente vas a tener que esforzarte y encontrar cómo para hacer que tu estado sea genérico.

0

Concrete Observer, y la implementación del tema concreto también tienen estado. Cuando el estado del sujeto cambia, el estado del observador concreto también se está actualizando. Pero a veces, es posible que necesite ver el estado del sujeto, que no tiene, para esto, es mejor que tenga referencia al tema. En otras palabras, para ver el estado del sujeto concreto.