Head first设计模式（2）

最新推荐文章于 2024-07-26 23:39:00 发布

weixin_34138056

最新推荐文章于 2024-07-26 23:39:00 发布

阅读量90

点赞数

文章标签：设计模式 java python

原文链接：https://my.oschina.net/u/814431/blog/361032

版权

2019独角兽企业重金招聘Python工程师标准>>>

认识观察者模式

我们看看报纸和杂志的订阅是怎么回事：

1、报社的业务就是出版报纸

2、向某家报社订阅报纸，只要他们有新报纸出版，就会给你送来。只要你是他们的订户，你就会一直收到新报纸

3、当你不想再看报纸的时候，取消订阅，他们就不会再送新报纸来

4、只要报社还在运营，就会一直有人（或单位）向他们订阅报纸或取消订阅报纸

出版者+订阅者=观察者模式

如果你了解报纸的订阅是怎么回事，其实就知道观察者模式是怎么回事，只是名称不太一样：出版者改称为“主题”(Subject)，订阅者改称为"观察者"(Observer)

1、主题对象管理某些数据

2、当主题内的数据改变就会通知观察者

3、一旦数据改变，新的数据会以某种形式送到观察者手上

4、观察者订阅（注册）主题以便在主题数据改变时能够收到更新

5、某个对象不是观察者，所以在主题数据改变使不会被通知

观察者的一天

1、鸭子对象过来告诉主题，它相当一个观察者

2、鸭子其实想说的是：我对你的数据改变感兴趣，一有变化请通知我

3、鸭子对象现在已经是正式的观察者了

4、鸭子静候通知，等待参与这项伟大的事情。一旦接获通知，就会得到一个整数

5、主题有了新的数据值

6、现在鸭子和其他所有观察者都会收到通知：主题已经改变了

7、老鼠对象要求从观察者中把自己除名

8、老鼠已经观察此主题太久，厌倦了，所以决定不再当个观察者

9、老鼠离开了

10、主题知道老鼠的请求之后，把它从观察者中除名

11、主题有一个新的整数

12、除了老鼠之外，每个观察者都会收到通知，因为它已经被除名了。嘘！不要告诉别人，老鼠其实心中暗暗地怀念这个整数，或许哪天又会再次注册，回来继续当观察者

定义观察者模式

1、当你试图勾勒观察者模式时，可以利用报纸订阅服务，以及出版者和订阅者比拟这一切

2、在真实的世界中，你通常会看到观察者模式被定义成

3、观察者模式——定义了对象之间的一对多依赖，这样依赖，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新

4、主题和观察者定义了一对多的关系，观察者依赖于此主题，只要主题状态一有变化，观察者就会被通知。根据通知的风格，观察者可能因此新值而更新

5、实现观察者模式的方法不只一种，但是以包含Subject与Observer接口的类设计的做法最常见

定义观察者模式：类图

1、这是主题接口，对象使用此接口注册为观察者，或者把自己从观察者中删除

2、每个主题可以有许多观察者

3、所有潜在的观察者必须实现观察者接口，这个接口只有update()一个方法，当主题状态改变时它被调用

4、一个具体主题总是实现主题接口，除了注册和撤销方法之外，具体主题还实现了notifyObservers()方法，此方法用于在状态改变时更新所有当前观察者

5、具体主题也可能有设置和获取状态的方法

6、具体的观察者可以是实现此接口的任意类。观察者必须注册具体主题，以便接收更新

这和一对多的关系有何关联？

利用观察者模式，主题是具有状态的对象，并且可以控制这些状态。也就是说，有“一个”具有状态的主题。另一方面，观察者使用这些状态，虽然这些状态并不属于它们。、有许多的观察者，依赖主题告诉它们状态何时改变了。这就产生一个关系："一个"主题对“多个”观察者的关系

其间的依赖是如何产生的？

因为主题是真正拥有数据的人，观察者是主题的依赖者，在数据变化时更新，这样比起让许多对象控制同一份数据来，可以得到更干净的OO设计

松耦合的威力

1、当两个对象之间松耦合，它们依赖可以交互，但是不太清楚彼此的细节

2、观察者模式提供了一种对象设计，让主题和观察者之间松耦合

为什么？

1、关于观察者的一切，主题只知道观察者实现了某一个接口(也就是Observer接口)。主题不需要知道观察者的具体类是谁，做了些什么或其他任何细节

2、任何时候我们都可以增加新的观察者。因为主题唯一依赖的东西是一个实现Observer接口的对象列表，所以我们可以随时增加观察者。事实上，在运行时我们可以用新的观察者取代现有的观察者，主题不会收到任何影响。同样的，也可以在任何时候删除某些观察者

3、有新类型的观察者出现时，主题的代码不需要修改。假如我们有个新的具体类需要当观察者，我们不需要为了兼容新类型而修改主题的代码，所有要做的就是在新的类里实现此观察者接口，然后注册为观察者即可。主题不在乎别的，它只会发送通知给所有实现了观察者接口的对象

4、我们可以独立地复用主题或观察者。如果我们在其他地方需要使用主题和观察者，可以轻易地复用，因为二者并非紧耦合

5、改变主题或观察者其中一方，并不会影响另一方。因为两者是松耦合的，所以只要他们之间的接口仍被遵循，我们就可以自由地改变他们

6、设计原则——为了交互对象之间得松耦合设计而努力

7、松耦合的设计之所以能让我们建立有弹性的OO系统，能够应对变化，是因为对象之间的互相依赖降到了最低

把观测值直接传入观察者中是更新状态的最直接的方法，你认为这样的做法明智吗？

这些观测值的种类和个数在未来有可能改变吗？如果以后会改变，这些变化是否被很好地封装？或者是需要修改许多代码才能办到？

关于将更新的状态传送给观察者，你能否想到更好的方法解决此问题？

围炉夜话：主题与观察者

主题：我很高兴，我们终于有机会面对面聊天了

观察者：是这样吗？我以为你根本不在乎我们这群观察者呢？

主题：哎呀！我把该做的事都做到了，不是吗？我总是会通知你们发生什么事了....我虽然不知道你们是谁，但这不意味着我不在乎你们。况且，我知道关于你们的一件重要的事：你们实现了Observer接口

观察者：是呀，但只是关于我的一小部分罢了！无论如何，我对你更了解

主题：是吗？说来听听！

观察者：嗯！你总是将你的状态传给我们，所以我们可以知道你内部的情况。有时候，这很烦人的.....

主题：拜托，我必须主动送出我的状态和通知给大家，好让你们这些懒惰的观察者知道发生什么事了

观察者：咳！等等，我说主题先生，首先，我们并不懒，在你那些"很重要"、通知的空档中，我们还有别的事要做。另外，为何由你主动送数据过来，而不是让我们主动去向你索取数据？

主题：嗯——这样或许也行，只是我必须因此门户大开，让你们全部都可以进来取得你们需要的状态，这样太危险了。我不能让你们进来里面大肆挖掘我的各种数据

观察者：你何不提供一些公开的getter方法，让我们“拉”走我们需要的状态？

主题：是的，我可以让你们“拉”走我的状态，但是你不觉得这样你们反而不方便吗？如果每次想要数据时都来找我，你可能要调用很多次才能收集齐全你所要的状态。这就是为什么我更喜欢"推的原因，你们可以在一次通知中一口气得到所有东西

观察者：死鸭子嘴硬！观察者种类这么多，你不可能事先料到我们每个人的需求，还是让我们直接去取得我们需要的状态比较恰当，这样一来，如果我们有人只需要一点点数据，就不会被强迫收到一堆数据。这么做同时也可以在以后比较容易修改。比方说，哪一天你决定扩展功能，新增更多的状态，如果采用我建议的方式，你就不用修改和更新对每位观察者的调用，只需改变自己来允许更多的getter方法来取得新增的状态

主题：是的，两种做法都有各自的优点。我注意到Java内置的Observer模式两种做法都支持

观察者：真的吗？

主题:太好了，或许我会看到一个"拉"的好例子，因而改变我的想法

使用Java内置的观察者模式

到目前为止，我们已经从无到有地完成了观察者模式，但是，Java API有内置得观察者模式。java.util包（package）内包含最基本的Observer接口与Observable类，这和我们的Subject接口与Observer接口很相似Observer接口与Observalbe类使用上更方便，因为许多功能都已经事先准备好了。你甚至可以使用推(push)或拉（pull）的方式传送数据，稍后就会看到这样的例子。

有了Java内置的支持，你只需要扩展（继承）Observable，并告诉它何时该通知观察者，一切就完成了，剩下的事API会帮你做

setChanged()方法

setChanged()方法用来标记状态已经改变的事实，好让notifyObservers()知道当它被调用时应该更新观察者。如果调用notifyObservers()之前没有先调用setChanged()，观察者就“不会”被通知

1、setChanged()方法把changed标志设为true

2、notifyObservers()只会在changed标为"true"时通知观察者

3、在通知观察者之后，把changed标志社回false

这样做有其必要性，setChanged()方法可以让你在更新观察者时，有更多的弹性，你可以更适当地通知观察者。比方说，如果没有setChanged()方法，我们得气象站测试是如此敏锐，以至于温度计读书每十分之一度就会更新，这会造成WeatherData对象持续不断地通知观察者，我们并不希望看到这样的事情发生。如果我们希望半度以上才更新，就可以在温度差距到达半度时，调用setChanged()，进行有效的更新。

你也许不会经常用到此功能，但是把这样的功能准备好，当需要时马上就可以使用。总之，你需要调用setChanged()，以便通知开始运转。如果此功能在某些地方对你有帮助，你可能也需要clearChanged()方法，将changed状态设置回false。另外也有一个hasChanged()方法，告诉你changed标志的当前状态

不要依赖于观察者被通知的次序

1、java.util.Observable实现了它的notifyObservers()方法，这导致了通知观察者的次序不同于我们先前的次序。谁也没有错，只是双方选择不同的方式实现罢了

2、但是可以确定的是，如果我们的代码依赖这样的次序，就是错的。为什么呢？因为一旦观察者/可观察者的实现有所改变，通知次序就会改变，很可能就会产生错误的结果，这绝对不是我们所认为的松耦合

难道Java.util.Observable违反了我们的OO设计原则：针对接口编程，而非针对实现编程？

java.util.Observable的黑暗面

1、是的，可观察者是一个“类”而不是一个“接口”，更糟糕的是，它甚至没有实现一个接口。不幸的是，java.util.Observable的实现有许多问题，限制了它的使用和复用。这并不是说它没有提供有用的功能，我们只是想提醒大家注意一些事实

2、Observable是一个类，你已经从我们的原则得知这不是一件好事，但是，这到底会造成什么问题呢？

3、首先，因为Observable是一个“类”，你必须设计一个类继承它。如果某类想同时具有Observable类和另一个超类的行为，就会陷入两难，毕竟Java不支持多重继承，这限制了Observable的复用潜力（而增加复用潜力不正是我们使用模式最原始的动机吗？）

4、再者，因为Observable接口，所以你无法建立自己的实现，和Java内置的ObserverAPI搭配使用，也无法将java.util的实现换成另一套做法的实现（比方说，Observable将关键的方法保护起来，如果你看看ObservableAPI，你会发现setChanged()方法被保护起来了（被定义成protected），那又怎么样呢？这意味着：除非你继承自Observable，否则你无法创建Observable实例并组合到你自己的对象中来，这个设计违反了第二设计原则："多用组合，少用继承"）