观察者模式

观察者模式（发布-订阅模式、模型-视图模式），属于对象行为方式： 解决场景： 当一个对象改变的时候，所有依赖它的对象都需要得到通知并且针对其改变而改变。 优缺点： 目标与观察者之间抽象耦合，使用了触发机制 但是依赖仍然有，如果目标的观察者（对象依赖）很多会影响效率 需要的对象： 目标：会发生改变的对象 观察者：依赖目标的对象 事件：发生的改变的抽象类 事件 - 观察者 目标 - 事件 java中有具体的观察者模式类： Observable和Observer 举例： 百变怪和武藏、小次郎 Ditto作为目标，WuZang和XiaoCiLang作为观察者（依赖）。当Ditto发生改变时，需要及时观察者及时做出改变 package com.zang.schema.observable.observer; import java.util.Observable; /** * java 原生观察者模式 * Ditto 百变怪 * 目标类 * @author Zhang Qiang * @Date 2019/8/29 17:44 */ public class Ditto extends Observable { private String transformation; public String getTransformation() { return transformation; }

1.观察者定义对象之间一对多关系。 2.主题（可观察者）用一个接口来通知所有的观察者。 3.观察者和可观察者之间是松耦合，可观察者不知道观察者细节，只知道观察者实现了观察者接口。 4.此模式可从被观察者哪里拉或者推数据，推更加合理。 5.多个观察者，无法预知顺序 6.java.utils.observeable 可观察者缺点，是个类，而不是接口，只能继承不能实现，而且将关键方法保护起来了，只有实现以后才能去修改 7.swing也是使用了观察者模式 来源： https://www.cnblogs.com/wakakCode/p/11429569.html

定义： 定义对象间一种一对多的依赖关系，使得当每一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。 类型： 行为类模式 类图： 在软件系统中经常会有这样的需求：如果一个对象的状态发生改变，某些与它相关的对象也要随之做出相应的变化。比如，我们要设计一个右键菜单的功能，只要在软件的有效区域内点击鼠标右键，就会弹出一个菜单；再比如，我们要设计一个自动部署的功能，就像eclipse开发时，只要修改了文件，eclipse就会自动将修改的文件部署到服务器中。这两个功能有一个相似的地方，那就是一个对象要时刻监听着另一个对象，只要它的状态一发生改变，自己随之要做出相应的行动。其实，能够实现这一点的方案很多，但是，无疑使用观察者模式是一个主流的选择。 观察者模式的结构 在最基础的观察者模式中，包括以下四个角色： 被观察者： 从类图中可以看到，类中有一个用来存放观察者对象的Vector容器（之所以使用Vector而不使用List，是因为多线程操作时，Vector在是安全的，而List则是不安全的），这个Vector容器是被观察者类的核心，另外还有三个方法：attach方法是向这个容器中添加观察者对象；detach方法是从容器中移除观察者对象；notify方法是依次调用观察者对象的对应方法。这个角色可以是接口，也可以是抽象类或者具体的类，因为很多情况下会与其他的模式混用

观察者<Observer>模式（有时又被称为发布-订阅<Publish/Subscribe>模式、模型-视图<Model/View>模式、源-收听者<Source/Listener>模式或从属者<Dependents>模式）是软件设计模式的一种。在此种模式中，一个目标物件管理所有相依于它的观察者物件，并且在它本身的状态改变时主动发出通知。这通常透过呼叫各观察者所提供的方法来实现。此种模式通常被用来实作事件处理系统 Subject （被观察的对象接口） 规定 ConcreteSubject 的统一接口； 每个 Subject 可以有多个 Observer ； ConcreteSubject （具体被观察对象） 维护对所有具体观察者的引用的列表； 状态发生变化时会发送通知给所有注册的观察者。 Observer （观察者接口） 规定 ConcreteObserver 的统一接口； 定义了一个 update() 方法，在被观察对象状态改变时会被调用。 ConcreteObserver （具体观察者） 维护一个对 ConcreteSubject 的引用； 特定状态与 ConcreteSubject 同步； 实现 Observer 接口，通过 update() 方法接收 ConcreteSubject 的通知。 模式的应用场景和优缺点： 观察者模式的应用场景： 1 、对一个对象状态的更新

第一章 策略模式 00设计原则： 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码放在一起。 把会变化的部分取出并封装起来，好让其它部分不会受到影响。结果如何？代码变化引起的不经意后果变少，系统变得更有弹性。 00设计原则： 针对接口编程，而不是针对实现编程。 “针对接口编程”真正的意思是“针对超类型编程”： 这里的接口有多个含义，接口是一个概念，也是一种java的interface构造。”针对接口编程“关键就在多态。利用多态，程序可以针对超类型编程，执行时会根据实际情况执行到真正的行为，不会被绑死在超类型的行为上。这句话可以更明确的说成”变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口。如此，只要是具体实现此超类型的类所产生的对象，都可以指定给这个变量。这也意味着声明类时不用理会以后执行的真正对象类型。 OO设计原则： 多用组合，少用继承 使用组合建立系统具有很大的弹性，不仅可以将算法族封装成类，更可以“在运行时动态地改变行为”，只要组合的行为对象符合正确的接口标准即可。 策略模式 定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。 类图 JDK java.util.Comparator#compare() javax.servlet.http.HttpServlet javax.servlet

// 主题，接收状态变化，触发每个观察者 class Subject { constructor() { this.state = 0 this.observers = [] } getState() { return this.state } setState(state) { this.state = state this.notifyAllObservers() } attach(observer) { this.observers.push(observer) } notifyAllObservers() { this.observers.forEach(observer => { observer.update() }) } } // 观察者，等待被触发 class Observer { constructor(name, subject) { this.name = name this.subject = subject this.subject.attach(this) } update() { console.log(`${this.name} update, state: ${this.subject.getState()}`) } } // 测试代码 let s = new Subject() let o1 = new Observer('o1', s) let

观察者模式 定义 对象之间定义一对多的依赖，当 一 这个对象状态发生变化，它所依赖的对象都能得到变化后的状态值。（简单的来说，就类似消息系统的发布订阅模式。其中消息系统中的 消费者 就是 观察者 ，消息系统中的 生产者 就是被观察者。当生产者的状态发生变化，那么订阅该消息的消费者就将全部接收到变化的信息） 类图 说明 由UML可以看出，该模式由四个对象组成： 抽象被观察者角色：也就是一个抽象主题，它把所有对观察者对象的引用保存在一个集合中，每个主题都可以有任意数量的观察者。抽象主题提供一个接口，可以增加和删除观察者角色。一般用一个抽象类和接口来实现。 抽象观察者角色：为所有的具体观察者定义一个接口，在得到主题通知时更新自己。 具体被观察者角色：也就是一个具体的主题，在集体主题的内部状态改变时，所有登记过的观察者发出通知。 具体观察者角色：实现抽象观察者角色所需要的更新接口，一边使本身的状态与制图的状态相协调。 代码实现 Subject public interface Subject { void initMsg(String msg); public void addObserver(Observer observer); public void removeObserver(Observer observer); public void notifyObserver(); }

1.从源头上理解和区别block和delegate delegate运行成本低，block的运行成本高。 block出栈需要将使用的数据从栈内存拷贝到堆内存，当然对象的话就是加计数，使用完或者block置nil后才消除。delegate只是保存了一个对象指针，直接回调，没有额外消耗。就像C的函数指针，只多做了一个查表动作。 2.从使用场景区别block和delegate 有多个相关方法。假如每个方法都设置一个 block, 这样会更麻烦。而 delegate 让多个方法分成一组，只需要设置一次，就可以多次回调。当多于 3 个方法时就应该优先采用 delegate。当1，2个回调时，则使用block。 delegate更安全些，比如: 避免循环引用。使用 block 时稍微不注意就形成循环引用，导致对象释放不了。这种循环引用，一旦出现就比较难检查出来。而 delegate 的方法是分离开的，并不会引用上下文，因此会更安全些。 delegate回调返回的参数被限制在了 NS 类的范围内，数量也很有限（当然可以用直接调用方法的形式在绕过，并不推荐；也可以用 Array 套着传， 不过这样需要有文档支持，不然不够清晰，回调方法也需要独立的验证，故也不推荐）。 效率 肯定是delegate比NSNotification高。 KVO提供一种机制,当指定的被观察的对像的属性被修改后

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。 常用应用场景： 工厂模式 ：IOC就是典型的工厂模式 代理模式 ：AOP就是代理实现的 Facade模式 ：shiro框架的核心 单例模式 Spring默认就是单例 不变模式 string 八大基本数据类型都是单例 Future 模式 异步调用。即请求时只拿到一个契约，约定以后可以获取这个东西 来源： https://www.cnblogs.com/duguangming/p/11407721.html

最近在研究tomcat，手上有一份尚硅谷的tomcat设计模式的资料，翻开看了看个人觉得写得还是很好的。设计模式一般都是在有一定的代理积累之后才能用到的相关的这种解决方案。常用的一共有23种设计模式，具体的可以去看看我老早自己整理的设计模式里面那些blog。 Tomcat 中运用的许多经典设计模式，如模版模式、工厂模式和单例模式等。通过学习它们的实践运用能给我们以后的软件设计起到一定的借鉴作用。这里主要整理4种： 1. 门面设计模式 门面设计模式在 Tomcat 中有多处使用，在 Request 和Response 对象封装中、 Standard Wrapper 到 ServletConfig 封装中、 ApplicationContext 到 ServletContext 封装中等都用到了这种设计模式。 门面设计模式的原理 这么多场合都用到了这种设计模式，那这种设计模式究竟能有什么作用呢？顾名思义，就是将一个东西封装成一个门面好与人家更容易进行交流，就像一个国家的外交部一样。这种设计模式主要用在一个大的系统中有多个子系统组成时，这多个子系统肯定要涉及到相互通信，但是每个子系统又不能将自己的内部数据过多的暴露给其它系统，不然就没有必要划分子系统了。每个子系统都会设计一个门面，把别的系统感兴趣的数据封装起来，通过这个门面来进行访问。这就是门面设计模式存在的意义。