企业应用架构笔记-设计模式-观察者模式

定义

定义对象间一种一对多的依赖关系,使得每当一个对象改变状态,则所有依赖于它的对象都会得到通知并被自动更新。

通用类图

企业应用架构笔记-设计模式-观察者模式_第1张图片

通用类图中几个角色:
Subject被观察者
定义被观察者必须实现的职责,它必须能够动态地增加、取消观察者。它一般是抽象类或者是实现类,仅仅完成作为被观察者必须实现的职责:管理观察者并通知观察者。
Observer观察者
观察者接收到消息后,即进行update(更新方法)操作,对接收到的信息进行处理。
ConcreteSubject具体的被观察者
定义被观察者自己的业务逻辑,同时定义对哪些事件进行通知。
ConcreteObserver具体的观察者
每个观察在接收到消息后的处理反应是不同,各个观察者有自己的处理逻辑。

观察者模式通用代码

被观察者

public abstract class Subject {
	//定义一个观察者数组
	private Vector<Observer> obsVector = new Vector<Observer>();
	//增加一个观察者
	public void addObserver(Observer o){ 
		this.obsVector.add(o);
	}
	//删除一个观察者
	public void delObserver(Observer o){ 
		this.obsVector.remove(o);
	}
	//通知所有观察者
	public void notifyObservers(){ 
		for(Observer o:this.obsVector){ 
			o.update();
		}
	}
}

被观察者的职责非常简单,就是定义谁能够观察,谁不能观察,程序中使用ArrayList和Vector没有太大的差别,ArrayList是线程异步,不安全;Vector是线程同步,安全——就这点区别。我们再来看具体的被观察者

具体被观察者

public class ConcreteSubject extends Subject {
	//具体的业务
	public void doSomething(){ 
		/*
		* 
		* do something */
		super.notifyObservers();
	}
}

我们现在看到的是一个纯净的观察者,在具体项目中该类有很多的变种。

观察者

public interface Observer {
	//更新方法
	public void update();
}

观察者一般是一个接口,每一个实现该接口的实现类都是具体观察者。

具体观察者

public class ConcreteObserver implements Observer {
	//实现更新方法
	public void update() { 
		System.out.println("接收到信息,并进行处理!");
	}
}

观察者一般是一个接口,每一个实现该接口的实现类都是具体观察者。

场景类的调用方法

public class Client { 
	public static void main(String[] args) 
	{
		//创建一个被观察者
		ConcreteSubject subject = new ConcreteSubject();
		//定义一个观察者
		Observer obs= new ConcreteObserver();
		//观察者观察被观察者
		subject.addObserver(obs);
		//观察者开始活动了
		subject.doSomething();
	}
}

优缺点

优点

1.观察者和被观察者之间是抽象耦合,如此设计,则不管是增加观察者还是被观察者都非常容易扩展,而且在Java中都已经实 现的抽象层级的定义,在系统扩展方面更是得心应手。

2.建立一套触发机制,这就是一个触发机制,形成了一个触发链。观察者
模式可以完美地实现这里的链条形式。

缺点

观察者模式需要考虑一下开发效率和运行效率问题,一个被观察者,多个观察者,开发和调试就会比较复杂,而且在Java中消息的通知默认是顺序执行,一个观察者卡壳,会影响 整体的执行效率。在这种情况下,一般考虑采用异步的方式。

多级触发时的效率更是让人担忧,大家在设计时注意考虑。

使用场景

1、关联行为场景。需要注意的是,关联行为是可拆分的,而不是“组合”关系。
2、事件多级触发场景。
3、跨系统的消息交换场景,如消息队列的处理机制。

注意

1、广播链的问题,我们的观察者模式一个观察者可以有双重身份,既是观察者,也是被观察者,这没什么问题呀,但是链一旦建立,这个逻辑就比较复杂,可维护性非常差,根据经验建议,在一个观察者模式中最多出现一个对象既是观察者也是被观察者,也就是说消息最多转发一次(传递两次),这还是比较好控制的。

2、异步处理问题,被观察者发生动作了,观察者要做出回应,如果观察者比较多,而且处理时间比较长怎么办?那就用异步呗,异步处理就要考虑线程安全和队列的问题,这个大家有时间看看Message Queue,就会有更深的了解。

与责任链模式区别

它和责任链模式的最大区别就是观察者广播链在传播的过程中消息是随时更改的,它是由相邻的两个节点协商的消息结构;而责任链模式在消息传递过程中基本上保持消息不可变,如果要改变,也只是在原有的消息上进行修正。

扩展

  1. Java世界中的观察者模式
    Java从一开始诞生就提供了一个可扩展的父类, 即java.util.Observable,这个类就是为那些“暴露狂”准备的,他们老是喜欢把自己的状态变更 让别人去欣赏,去触发,这正符合了我们现在的要求,要把所有活动都暴露出去,并且想暴露给谁就暴露给谁。我们打开Java的帮助文件看看,查找一下Observable是不是已经有这个类了?JDK中提供了:java.util.Observable实现类和java.util.Observer接口。
    具体被观察者接口
public interface ISubject {
	//具体的业务
	public void doSomething(){ 
	}
}

具体被观察者

public class ConcreteSubject extends Observable, ISubject {
	//具体的业务
	public void doSomething(){ 
		/*
		* 
		* do something */
		super.setChanged(); 
		super.notifyObservers();
	}
}

观察者

public class ConcreteObserver implements Observer {
	//实现更新方法
	public void update() { 
		System.out.println("接收到信息,并进行处理!");
	}
}

综上

观察者模式在实际项目和生活中非常常见。主要用来监听被观察者的变化,使得观察者相应变化。

如果你觉得小编总结笔记有所用处,请点点关注和粉丝,后续还会不断更新,让我们一起进步!!!

你可能感兴趣的:(架构专栏,架构,笔记,设计模式)