观察者模式很好理解,类似于邮件订阅和RSS订阅,当我们浏览一些博客或wiki时,经常会看到RSS图标,就这的意思是,当你订阅了该文章,如果后续有更新,会及时通知你。其实,简单来讲就一句话:当一个对象变化时,其它依赖该对象的对象都会收到通知,并且随着变化!对象之间是一种一对多的关系。
public interface Observer {
public void update();
}
public class Observer1 implements Observer {
@Override
public void update() {
System.out.println("observer1 has received!");
}
}
public class Observer2 implements Observer {
@Override
public void update() {
System.out.println("observer2 has received!");
}
}
public interface Subject {
/*增加观察者*/
public void add(Observer observer);
/*删除观察者*/
public void del(Observer observer);
/*通知所有的观察者*/
public void notifyObservers();
/*自身的操作*/
public void operation();
}
public abstract class AbstractSubject implements Subject {
private Vector<Observer> vector = new Vector<Observer>();
@Override
public void add(Observer observer) {
vector.add(observer);
}
@Override
public void del(Observer observer) {
vector.remove(observer);
}
@Override
public void notifyObservers() {
Enumeration<Observer> enumo = vector.elements();
while(enumo.hasMoreElements()){
enumo.nextElement().update();
}
}
}
public class MySubject extends AbstractSubject {
@Override
public void operation() {
System.out.println("update self!");
notifyObservers();
}
}
public class ObserverTest {
public static void main(String[] args) {
Subject sub = new MySubject();
sub.add(new Observer1());
sub.add(new Observer2());
sub.operation();
}
}
应用场景
以购票为核心业务(此模式不限于该业务),但围绕购票会产生不同的其他逻辑,如:
1、购票后记录文本日志
2、购票后记录数据库日志
3、购票后发送短信
4、购票送抵扣卷、兑换卷、积分
5、其他各类活动等
传统解决方案:
在购票逻辑等类内部增加相关代码,完成各种逻辑。
存在问题:
1、一旦某个业务逻辑发生改变,如购票业务中增加其他业务逻辑,需要修改购票核心文件、甚至购票流程。
2、日积月累后,文件冗长,导致后续维护困难。
存在问题原因主要是程序的"紧密耦合",使用观察模式将目前的业务逻辑优化成"松耦合",达到易维护、易修改的目的,同时也符合面向接口编程的思想。
观察者模式典型实现方式:
1、定义2个接口:观察者(通知)接口、被观察者(主题)接口
2、定义2个类,观察者对象实现观察者接口、主题类实现被观者接口
3、主题类注册自己需要通知的观察者
4、主题类某个业务逻辑发生时通知观察者对象,每个观察者执行自己的业务逻辑。
优点
采用该模式可以方便地更换算法或者增加新的算法。避免了较难维护的多重选择条件选择语句。
缺点
订阅后如果不进行取消订阅操作容易引起内存泄露
适应场景
事件分发管理器
游戏业务逻辑与游戏控制器