首页 > 其他 > 详细

观察者模式

时间:2015-03-31 23:42:43      阅读:285      评论:0      收藏:0      [点我收藏+]

参考:http://www.cnblogs.com/wader2011/archive/2011/11/19/2254981.html

介绍

observer模式定义对象间的一对多的依赖关系 ,当一个对象(被观察者)的状态改变的时候 ,所有 的依赖于它的对象(观察者)

都 得到通知并被自动更新。

Observer是观察者,而Observable是被观察的目标。

 

相关类的介绍

1. observable类

继承它的类表示程序想要观察的对象 ,一个observable对象可以有一个or多个观察者。观察者是实现 Observer接口的任意对象 ,

一个Oberver实例改变后,调用 Observable的notifyObservers方法的应用程序 会通过调用观察者的update方法来通知观察者这个

实例发生了什么。

重要的几个方法

void addObserver(Observer o)

 如果观察者与集合中已有的观察者不同,则向对象的观察者集中添加此观察者。未指定向多个观察者发送通知的顺序。

clearChanged()

  指示对象不再改变,或者它已对其所有的观察者通知了最近的改变,所以 hasChanged 方法将返回 false。notifyObservers 方法自动调用此方法。

int countObservers ()

   返回 Observable 对象的观察者数目。

void deleteObserver (Observer o)

从对象的观察者集合中删除某个观察者。向此方法传递 null无效。

deleteObservers()

清除观察者列表,使此对象不再有任何观察者。

boolean hasChanged ()

 测试对象是否改变。当且仅当在此对象上最近调用了 setChanged 方法时才返回 true;否则返回 false。

notifyObservers(0

如果 hasChanged 方法指示对象已改变,则通知其所有观察者,并调用 clearChanged 方法来指示此对象不再改变。

每个观察者都有其 update 方法,其调用参数有两个:observable 对象和 null。换句话说,此方法等效于: notifyObservers(null)

notifyObservers(Object arg)

   如果 hasChanged 方法指示对象已改变,则通知其所有观察者,并调用 clearChanged 方法来指示此对象不再改变。

每个观察者都有其 update 方法,其调用参数有两个:observable 对象和 arg 参数。 arg 可以是任意对象

setChanged ()

标记此 Observable 对象为已改变的对象;现在 hasChanged 方法将返回 true

Observer类接口

这个接口只有一个未实现 的抽象接口 update ,实现这个接口的对象成为观察者同。注册了这个对象 (观察者)的对象(ers被观察者)实例调用 

notifyObservers()后,观察者会自动 执行update 方法.

void update(Observable o ,Object arg)

o--被观察者

arg--notifyObservers方法的参数 

实例

该实例模拟了烧水的过程,涉及三个对象,Heater(热水器),Display(显示器),Alarm(报警器).

模拟过程:为了便于运行,水的初始化温度为90,沸点为95,显示器依据热水器显示温度,显示器显示温度为95时,报警器开始报警。明显可以看出Heater是subject ,Display 是它的 Obsrver,同时Display亦是subject,因为它要被报警器观察,所以Alarm是Display的Observer.

 

package Observer;

import java.util.Observable;

public class Heater extends Observable{
	private int temp ;

	public int getTemp() {
		return temp;
	}

	public void setTemp(int temp) {
		this.temp = temp;
	}
	
	public void boilWater (){
		for (int i =90; i<110; i++){
			temp = i;
			setChanged() ;
			notifyObservers() ;
		}
	}
}

  然后

package Observer;

import java.time.temporal.Temporal;
import java.util.Observer;

import java.util.Observable;

public class Display extends Observable implements Observer{
	private String status = "未开" ;
	
	public String getStatus() {
		return status;
	}

	public void setStatus(String status) {
		this.status = status;
	}
	
	public void update(Observable arg0, Object arg1) {
		displayTemp(((Heater)arg0).getTemp()) ;
		
	}
	private void displayTemp(int temp ){
		if (temp >100){
			setStatus("沸腾");
			setChanged() ;
			notifyObservers(Integer.valueOf(temp)) ;
		} 

		System.out.println("状态: " + status + "  现在温度: " + temp);
	}

	

}

  然后

package Observer;

import java.util.Observable;
import java.util.Observer;

public class Alarm  implements Observer{
	
	private void makeAlarm(Integer temp ){
		System.out.println("temp:"+ temp);
		System.out.println("滴滴,水开了");
	}
	
	public void update(Observable arg0, Object arg1) {
		makeAlarm((Integer)arg1) ;
	}

}

  测试类中

package Observer;

public class TestObserver {
	public static void main (String [] args){
		Heater heater = new Heater() ;
		Display display = new Display() ;
		Alarm alarm = new Alarm() ;
		heater.addObserver(display) ;
		display.addObserver(alarm) ;
		heater.boilWater() ;
	}
}

  

优点

  • 支持松耦合和减少依赖性。客户端不再依赖于观察器,因为通过使用主体和 Observer 接口对客户端进行了隔离。许多框架具有此优点,在这些框架中的应用程序组件可以注册为当(低级)框架事件发生时得到通知。结果,框架将调用应用程序组件,但不会依赖于它。
  • 观察器数目可变。观察器可以在运行时附加和分离,因为主体对于观察器数目没有任何假定。此功能在这样的情况下是很有用的:观察器数在设计时是未知的。例如,如果用户在应用程序中打开的每个窗口都需要一个观察器。

缺点

  • 性能降低。在许多实现中,观察器的 update() 方法可能与主体在同一线程中执行。如果观察器列表很长,则执行 Notify() 方法可能需要很长时间。抽取对象依赖性并不意味着添加观察器对应用程序没有任何影响。
  • 内存泄漏。在 Observer 中使用的回调机制(当对象注册为以后调用时)会产生一个常见的错误,从而导致内存泄漏,甚至是在托管的 C# 代码中。假定观察器超出作用范围,但忘记取消对主体的订阅,那么主体仍然保留对观察器的引用。此引用防止垃圾收集在主体对象也被破坏之前重新分配与观察器关联的内存。如果观察器的生存期比主体的生存期短得多(通常是这种情况),则会导致严重的内存泄漏。
  • 隐藏的依赖项。观察器的使用将显式依赖性(通过方法调用)转变为隐式依赖性(通过观察器)。如果在整个应用程序中广泛地使用观察器,则开发人员几乎不可能通过查看源代码来了解所发生的事情。这样,就使得了解代码更改的含意非常困难。此问题随传播级别急剧增大(例如,充当 Subject 的观察器)。因此,应该仅在少数定义良好的交互(如 Model-View-Controller 模式中模型和视图之间的交互)中使用观察器。最好不要在域对象之间使用观察器。
  • 测试 / 调试困难。尽管松耦合是一项重大的体系结构功能,但是它可以使开发更困难。将两个对象去耦的情况越多,在查看源代码或类的关系图时了解它们之间的依赖性就越难因此,仅当可以安全地忽略两个对象之间的关联时才应该将它们松耦合(例如,如果观察器没有副作用)。

观察者模式

原文:http://www.cnblogs.com/chuiyuan/p/4382116.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!