起床做饭（观察者模式）

//通知者
public class Boy {
	//状态
	private String state;
	//观察者列表
	public List<Girl> girls = new ArrayList<Girl>();
    
	//通知	
	public void notifyGirls(){
		
		for(Girl g : girls ){
			g.update();
		}
		
	}
	//增加
	public void attach(Girl g){
		girls.add(g);
	
	}
	//减少
	public void detach(Girl g){
		girls.remove(g);
	}
	
	
	public String getState() {
		return state;
	}
	public void setState(String state) {
		this.state = state;
	}
	
	public static void main(String[] args){
		Boy ysen = new Boy();
		Girl girlFriend = new Girl();
		girlFriend.setName("hyy");
		//下面两句 ，两个具体对象相互耦合了，违背了依赖倒转原则，应该让程序都依赖抽象，这里需要解耦
		//需要给Boy 和 Girl 各 添加一个基类，让它们依赖抽象
		girlFriend.setBoy(ysen);
		ysen.attach(girlFriend);
		
		ysen.setState("我回来了哦~~");
		ysen.notifyGirls();
	}
	
}

 

//观察者
public class Girl {
	
	private String name;
	private Boy boy;
	
	public void update(){
		System.out.println(boy.getState()+name+"起床做饭咯");
	}

	public Boy getBoy() {
		return boy;
	}
	public void setBoy(Boy boy) {
		this.boy = boy;
	}

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}
	

}

 

评论

12 楼 java_doc 2009-12-13  

Solstice 写道

没错，一个简单的事件通知没必要用设计模式来装X。

mock1234 写道

编写《设计模式》那本书的时候，java世界的水平还很低。现在已经有很多现成的回调（或者说事件通知）的简单语法，所以设计模式的恶心代码最好不要模仿，应该使用你的编译器直接支持的清晰干净的标准事件delegate代码。

设计模式容易让人死读书、读死书。为了走形式而故作抽象地去增加繁琐冗余的层次，一堆极其雷人的模式专用名词术语掩盖了真相，结果也还是没有能够解除通讯中的耦合和理清通讯时序。我对设计模式的态度是：虽然他是许多人入门时的必修的八股文，建议各位工作时尽早看透它的本质然后把它扫进垃圾堆。

事件通知的底层实现还不是使用的设计模式。

11 楼 ora92 2009-12-13  

设计模式这么好，为什么只有23种，太少了吧，呵呵

10 楼 wangdgsc 2009-12-12  

设计模式是一种思想，不是一段代码，它只是告诉你遇到某一种问题时下使用一种大家都认可的方式去处理，因为那是被很多人实践出来的，模式不是纸上谈兵，是从实践中出来的，学模式学的是思想，不是学代码，所以，模式不会害人，就像一支军队，在有的人手上是正义之师，而在有的人手上，则成了叛军，呵呵

9 楼 netfish 2009-12-12  

软件都是需要包装的，包装的目的是为了能更好的和别人进行交流，当然，每个人有每个人的理解；其实设计模式是一种思想，楼主只是用一种表现形式表现出来了而已，不过不是很好的表现形式，一开始看lz的题目倒是很吸引人，为何不沿着这个深入下去呢

8 楼 夜之son 2009-12-11  

lz把自己的项目贴出来分析设计模式呗。让我们都学习学习

7 楼 Solstice 2009-12-11  

没错，一个简单的事件通知没必要用设计模式来装X。

mock1234 写道

编写《设计模式》那本书的时候，java世界的水平还很低。现在已经有很多现成的回调（或者说事件通知）的简单语法，所以设计模式的恶心代码最好不要模仿，应该使用你的编译器直接支持的清晰干净的标准事件delegate代码。

设计模式容易让人死读书、读死书。为了走形式而故作抽象地去增加繁琐冗余的层次，一堆极其雷人的模式专用名词术语掩盖了真相，结果也还是没有能够解除通讯中的耦合和理清通讯时序。我对设计模式的态度是：虽然他是许多人入门时的必修的八股文，建议各位工作时尽早看透它的本质然后把它扫进垃圾堆。

6 楼 aoliwen521 2009-12-11  

我认为设计模式，还是应当了解一下的。
编程的时候思路还是比较开阔，总能有一些解决问题的好想法。

5 楼 berlou 2009-12-11  

mock1234 写道

编写《设计模式》那本书的时候，java世界的水平还很低。现在已经有很多现成的回调（或者说事件通知）的简单语法，所以设计模式的恶心代码最好不要模仿，应该使用你的编译器直接支持的清晰干净的标准事件delegate代码。

说白了，假设一个小子要通知别人（不论是自己的女朋友还是别人）他回来了，那么这个事件不论是使用回调函数还是其它什么对象来实现，关键是，这个回调函数或者其它什么对象类的接口定义是这个小子主导的，这个小子不需要知道他自己的女朋友的接口，而女朋友则要知道他的接口，并且女朋友实例化一个回调函数或者通知对象在早上就安装到这个小子身上，这才能体现你的绿色的注释中所说的（抽象而非具体）原则。

设计模式容易让人死读书、读死书。为了走形式而故作抽象地去增加繁琐冗余的层次，一堆极其雷人的模式专用名词术语掩盖了真相，结果也还是没有能够解除通讯中的耦合和理清通讯时序。我对设计模式的态度是：虽然他是许多人入门时的必修的八股文，建议各位工作时尽早看透它的本质然后把它扫进垃圾堆。

被世界捧为经典的东西被你说成垃圾， 究竟是你垃圾还是世界都垃圾？
Java设计模式是在OO上扩展出来的， 是设计思想的总结和复用。 至于现在有人言必谈模式， 那只是误区， 不是设计模式本身的错误。 设计模式是设计的很基础的功底， 可以不必知道模式的名字， 但是不能不知道这里的思想。
好的设计和模式会让开发效率， 维护性扩展性得到很大的提升， 如果这个被你当作垃圾， 我只能说， 你是垃圾。

4 楼 mccxj 2009-12-11  

受不了接二连三的无聊模式～～投个新手

3 楼 ysen 2009-12-11  

虽然C#提供了回调事件delegate，但我们还是要了解本质的东西

2 楼 ysen 2009-12-11  

mock1234 写道

编写《设计模式》那本书的时候，java世界的水平还很低。现在已经有很多现成的回调（或者说事件通知）的简单语法，所以设计模式的恶心代码最好不要模仿，应该使用你的编译器直接支持的清晰干净的标准事件delegate代码。

说白了，假设一个小子要通知别人（不论是自己的女朋友还是别人）他回来了，那么这个事件不论是使用回调函数还是其它什么对象来实现，关键是，这个回调函数或者其它什么对象类的接口定义是这个小子主导的，这个小子不需要知道他自己的女朋友的接口，而女朋友则要知道他的接口，并且女朋友实例化一个回调函数或者通知对象在早上就安装到这个小子身上，这才能体现你的绿色的注释中所说的（抽象而非具体）原则。

设计模式容易让人死读书、读死书。为了走形式而故作抽象地去增加繁琐冗余的层次，一堆极其雷人的模式专用名词术语掩盖了真相，结果也还是没有能够解除通讯中的耦合和理清通讯时序。我对设计模式的态度是：虽然他是许多人入门时的必修的八股文，建议各位工作时尽早看透它的本质然后把它扫进垃圾堆。

还有这不是八股文，这是设计的基本思想

1 楼 ysen 2009-12-11  

mock1234 写道

编写《设计模式》那本书的时候，java世界的水平还很低。现在已经有很多现成的回调（或者说事件通知）的简单语法，所以设计模式的恶心代码最好不要模仿，应该使用你的编译器直接支持的清晰干净的标准事件delegate代码。

说白了，假设一个小子要通知别人（不论是自己的女朋友还是别人）他回来了，那么这个事件不论是使用回调函数还是其它什么对象来实现，关键是，这个回调函数或者其它什么对象类的接口定义是这个小子主导的，这个小子不需要知道他自己的女朋友的接口，而女朋友则要知道他的接口，并且女朋友实例化一个回调函数或者通知对象在早上就安装到这个小子身上，这才能体现你的绿色的注释中所说的（抽象而非具体）原则。

设计模式容易让人死读书、读死书。为了走形式而故作抽象地去增加繁琐冗余的层次，一堆极其雷人的模式专用名词术语掩盖了真相，结果也还是没有能够解除通讯中的耦合和理清通讯时序。我对设计模式的态度是：虽然他是许多人入门时的必修的八股文，建议各位工作时尽早看透它的本质然后把它扫进垃圾堆。

设计模式不管怎么说还是要了解并熟知才行，不然怎么走的高远了，相比ls应该比我更加烂熟于心