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?
O es? Solo estoy basando esto en ejemplos que he leído.
Indique sus 'referencias'. – Nix
@Nix: Listo. Me pareció suficiente referirme a los libros por su nombre sin vincular, ya que son bastante conocidos. –
Uno de los ejemplos que publicó DOFactory muestra el uso de una clase abstracta? – Nix