如何解决网站只收录首页的一些办法,青岛做外贸网站建设,做网站需要可信认证吗,中国化工网网站建设建议《Head First设计模式》读书笔记 相关代码#xff1a;Vks-Feng/HeadFirstDesignPatternNotes: Head First设计模式读书笔记及相关代码 让你的对象知悉现状#xff0c;不会错过对象感兴趣的事对象甚至在运行时可决定是否要继续被通知JDK中使用最多的模式之一 本节例子 系统三…《Head First设计模式》读书笔记相关代码Vks-Feng/HeadFirstDesignPatternNotes: Head First设计模式读书笔记及相关代码让你的对象知悉现状不会错过对象感兴趣的事对象甚至在运行时可决定是否要继续被通知JDK中使用最多的模式之一本节例子系统三部分气象站获取实际气象数据的物理装置WeatherData对象追踪来自气象站的数据并更新布告板布告板显示目前天气状况给用户看物理气象站→WeatherData对象(已完成)WeatherData对象→及时更新布告板我们的工作建立一个应用利用WeatherData对象取得数据并更新三个布告板(目前状况、气象统计、天气预报)|-----------------------| | WeatherData | |-----------------------| | getTemperature() | | getHumidity() | | getPressure() | | measure- | | mentsChanged() | | //其他方法 | |-----------------------|一旦气象测量更新mentsChanged会被调用错误示范public class WeatherData { public void measurementsChanged() { float temp getTemperature(); float humidity getHumidity(); float pressure getPressure(); currentConditionDisplay.update(temp, humidity, pressure); statisticsDisplay.update(temp, humidity, pressure); forecastDisplay.update(temp, humidity, pressure); } }认识观察者模式报纸类比报社的业务就是出版报纸向报社订阅报纸当有新报纸出版时就会送来。只要是订户就会一直收到报纸不再想看时取消订阅就不会再送只要报社还运行就会一直有人向他们订阅/取消订阅出版者订阅者观察者模式HeadFirst设计模式2-观察者模式出版者↔️主题(subject)订阅者↔️观察者(Observer)观察者模式使用对象告知主题想要成为观察者 —— 注册(订阅)对象成为观察者可以接收到通知对象要求从观察者把自己除名(取消订阅)主题接收到请求将其除名定义观察者模式观察者模式定义了对象之间的一对多依赖这样一来当一个对象改变状态时它的所有依赖者都会收到通知并自动更新。定义了一系列对象之间的一对多关系状态改变→依赖者都会接到通知类图QAQ这和一对多的关系有何关联A利用观察者模式主题是具有状态的对象并且可以控制这些状态也就是说有“一个”具有状态的主题。另一方面观察者使用这些状态虽然这些状态并不属于他们有许多的观察者以来主题来告诉他们状态何时改变了。这就产生了一个关系“一个”主题对“多个”观察者的关系。Q其间的依赖是如何产生的A主题是真正拥有数据的人观察者是主题的依赖者在数据变化时更新这样比起让许多对象控制同一份数据来可以得到更干净的OO设计。松耦合的威力当两个对象之间松耦合它们依然可以交互但是不太清楚彼此的细节。观察者模式提供了一种对象设计让主题和观察者之间松耦合。主题唯一依赖的东西就是一个实现Observer接口的对象列表所以我们怎么操作其中的观察者对象(增删改)不会影响到主题。当有新类型的观察者出现时不需要修改主题的代码只需要该类去实现观察者接口然后注册为观察者即可。主题不在乎别的只会发送给所有实现了观察者接口的对象。可以独立地复用主题或观察者其他地方需要使用时也可以轻易地复用因为二者并非紧耦合因为主题和观察者二者是松耦合的所以只要它们之间的接口仍被遵守就可以自由地改变它们设计原则4 为了交互对象之间的松耦合设计而努力松耦合的设计之所以能让我们建立有弹性的OO系统能够应对变化是因为对象之间的相互依赖降到了最低气象站设计“拉”与“推”之辩拉指观察者主动向主题获取数据推指主题将信息发给观察者“拉”拉的好处主题不可能事先料到各种观察者的需求拉可以让各种观察者去获取目标信息而非被动接收到一大坨信息(其中可能包含不需要的内容)当主题需要扩展功能时不用修改和更新对每位观察者的调用只需要改变自己的getter、setter即可拉的缺点主题必须门户大开封装性被打破面临被大肆挖掘数据的风险观察者可能会多次调用才能拼凑其所需信息“推”与“拉”的优缺相对应略Java内置的观察者模式( Java 9 及更高版本中Observable类被标记为Deprecated意味着它仍然可以使用但不推荐使用未来可能会被移除。)当然我们还是可以从中学到一些东西的使用java.util包中包含最基本的Observer接口和Observer类具备许多功能使用上更方便甚至可以使用“推”或“拉”的方式传送数据图中重点信息“主题”(Subject)也可称为“可观察者”(Observable)Observable是一个“类”而不是一个“接口”如何运作把对象变成观察者实现观察者接口(java.util.Observer)然后调用其addObserver()方法可观察者送出通知产生可观察类先调用setChange()方法标记状态已经改变的事实调用两种notifyObservers()方法中的一个(notifyObserver()或notifyObservers(Object arg))如何接收通知update(Observable o, Object arg)o主题本身是第一个变量从而让观察者知道是哪个主题发来的通知arg传入notifyObservers()的数据对象如果没有说明为空setChange()setChange()用来标记状态已经改变的事实好让notifyObservers()知道当它被调用时应该更新观察者。如果调用notifyObservers()之前没有调用setChange()观察者就不会通知被通知伪代码如下setChange() { changed true; } notifyObservers(Object arg) { if (changed) { for every observer on the list { call updata(this, arg); } changed false; } } notifyObservers() { notifyObservers(null); }为什么要设计setChange()setChange()可以让你在更新观察者时有更多的弹性可以更适当地通知观察者。例如气象站的测量十分敏锐过于微小的变动也会被捕捉这会造成主题不断地通知观察者。但是我们可以设置在温度变化超过半度才通知观察者(即超过半度再调用setChange())使得每次通知更有效黑暗面Observable是一个“类”而非“接口”其实现有很多问题限制了他的使用和复用由于java不支持多继承如果某类想具有Observable和另一个超类的行为会比较麻烦这限制了Observable的复用能力而增加复用能力正是使用模式最原始的动机setChange()方法被保护起来了(protect)这意味着除非继承自Observable否则无法创建Observable实例并组合到自己的对象中违反了第二个设计原则“多用组合少用继承”总结OO基础抽象OO原则封装变化多用组合少用继承针对接口编程不针对实现编程为交互对象之间的松耦合设计而努力松耦合设计更有弹性更能应对变化OO模式观察者模式——在对象之间定义一对多的依赖这样一来当一个对象改变状态依赖它的对象都会收到通知并自动更新观察者模式的代表人物——MVC要点观察者模式定义了对象之间一对多的关系主题(可观察者)用一个共同的接口来更新观察者观察者和可观察者之间用松耦合方式结合(loosecoupling)可观察者不知道观察者的细节只知道观察者实现了观察者接口使用此模式时你可从被观察者处推(push)或拉(pull)数据(然而推的方式被认为更“正确”)有多个观察者时不可以依赖特定的通知次序(即通知顺序不应该影响程序的正确性)一旦观察者/可观察者的实现有所改变通知次序就会改变很可能就会产生错误的结果这违背了松耦合