网站做标题有用吗建设银行网站查询企业年金

网站做标题有用吗,建设银行网站查询企业年金,苏州网站建设点一点,做网站跟app需要多少钱1. 观察者模式是什么想象一下#xff0c;你是一个杂志社#xff08;我们叫它“主题”或“发布者”#xff09;。你有一批忠实的订阅用户#xff08;我们叫他们“观察者”或“订阅者”#xff09;。你的工作#xff08;发布者#xff09;#xff1a;专心做好内容#x…1. 观察者模式是什么想象一下你是一个杂志社我们叫它“主题”或“发布者”。你有一批忠实的订阅用户我们叫他们“观察者”或“订阅者”。你的工作发布者专心做好内容比如出版新一期的《架构师周刊》。你不需要知道具体是谁订阅了你只需要维护一个订阅名单。订阅者的工作观察者他们向杂志社登记订阅说“嘿出新刊了记得通知我。”然后他们该干嘛干嘛。关键动作通知当你这期杂志印刷好了状态改变你不会挨家挨户敲门。你会按照订阅名单把新杂志统一寄送通知给所有订阅者。订阅者的反应更新订阅者收到杂志后各自采取行动老王可能泡杯茶开始读小李可能转手送给朋友。映射到代码里就是这个意思 一个核心对象主题的状态发生了变化它自己不用操心要去通知谁、怎么通知。它只负责维护一个观察者列表并在变化发生时遍历这个列表对每个观察者说一句“喂我变了”调用一个定义好的方法比如update()。至于每个观察者听到这个消息后是去更新界面、刷新缓存、还是发个短信主题完全不知道也不关心。这就是观察者模式的核心定义对象间的一种一对多的依赖关系当一个对象的状态发生改变时所有依赖于它的对象都得到通知并被自动更新。它完美地将变化的发出者主题和变化的响应者观察者解耦了。2. 什么时候用2.1 使用信号当你看到以下场景时观察者模式就该出场了“牵一发而动全身”的时候这是最经典的场景。比如后台管理页面修改了某个核心的系统配置主题状态改变。这个改动需要立刻生效在前端的多个页面展示、缓存的刷新、相关服务的配置热更新、甚至要记录一条审计日志。如果你用一堆if-else或者硬编码调用代码会变成一坨乱麻加一个影响点就得改核心代码。用观察者模式配置服务就是主题前端组件、缓存服务、审计服务都是观察者。配置一变自动通知所有相关方干净利落。“不知道有多少人关心”的时候你的系统里有个事件比如“用户成功支付”。未来可能有无数个模块关心这个事件发优惠券、更新用户积分、通知物流系统、给运营发数据报表……你作为支付模块的开发者根本不可能预知未来所有需求。用观察者模式支付模块只管触发“支付成功”事件谁关心谁自己来订阅。未来加十个新功能支付模块的代码一行都不用动。“一个对象需要通知其他对象但又不想跟它们绑死”的时候这就是低耦合的诉求。比如你的数据模型Model变了需要更新多个UI视图View。你肯定不希望数据模型里塞满了更新UI的代码。用观察者模式UI视图作为观察者订阅数据模型的变化。模型变了通知视图更新模型完全不知道视图是怎么渲染的。2.2 实际项目中的高频用例事件驱动架构这是观察者模式的集大成者。消息队列如Kafka、RabbitMQ就是超级主题微服务就是观察者。GUI事件处理几乎所有的UI框架如Java Swing、Android底层都是观察者模式。按钮点击、鼠标移动都是事件主题事件监听器就是观察者。应用内消息总线比如Spring的ApplicationEvent机制就是一个标准的观察者模式实现用于解耦模块间的通信。实时数据同步配置中心、分布式缓存的一致性通知。3. 怎么实现概念懂了我们看看代码里长什么样。它通常包含四个角色主题Subject接口定规矩。必须能添加attach/addObserver、删除detach/removeObserver观察者并能通知notifyObservers所有观察者。具体主题ConcreteSubject干实活。实现接口内部维护一个观察者列表。它有自己的状态比如int state当状态改变时比如setState()被调用就遍历列表调用每个观察者的更新方法。观察者Observer接口也是定规矩。通常就一个方法比如update()用来接收主题的通知。具体观察者ConcreteObserver也是干实活。实现update()方法定义自己接到通知后要做什么。它通常会持有主题的引用以便在更新时获取主题的最新状态。一段极简的代码骨架帮你理解伪代码风格// 1. 主题接口 interface Subject { void addObserver(Observer o); void removeObserver(Observer o); void notifyObservers(); } // 2. 具体主题 class ConcreteSubject implements Subject { private ListObserver observers new ArrayList(); private int importantData; // 核心状态 public void setImportantData(int newValue) { this.importantData newValue; notifyObservers(); // 状态改变立刻通知 } Override public void notifyObservers() { for (Observer o : observers) { o.update(); // 调用每个观察者的更新方法 } } // ... 实现 add/remove 方法 } // 3. 观察者接口 interface Observer { void update(); } // 4. 具体观察者A class ConcreteObserverA implements Observer { private ConcreteSubject subject; // 持有主题引用以便获取数据 Override public void update() { // 主题通知我了我要做我的事了 int data subject.getImportantData(); System.out.println(Observer A: Data is now data); // 可能是更新UI也可能是刷新缓存... } }看到没ConcreteSubject在setImportantData里调用了notifyObservers这就是“出版杂志”。ConcreteObserverA的update方法就是“读杂志”。两者通过抽象的接口联系没有直接依赖具体实现。4. 优点与缺点4.1 优点解耦解耦还是解耦这是最大的价值。主题和观察者之间只依赖于抽象接口而不是具体类。主题不知道观察者是谁、有多少个、要干嘛。这符合“开放-封闭原则”新增观察者无需修改主题代码。支持广播通信主题一次状态改变能自动通知所有观察者非常适合一对多的通信场景。增强了系统的灵活性和可扩展性可以随时动态地增加或删除观察者系统行为可以很容易地改变。4.2 缺点通知链可能失控如果观察者的更新方法里又去修改了主题的状态可能会触发新一轮的通知形成循环调用严重时导致系统崩溃。设计时要特别注意避免这种循环依赖。性能隐患如果观察者数量巨大比如上万个并且每个观察者的更新操作都很耗时那么一次同步通知可能会阻塞主题很长时间导致响应变慢。解决方案是考虑异步通知比如将通知任务扔到线程池或消息队列里。观察者只知道“变了”不知道“怎么变”在基础的实现里主题的notifyObservers()方法只是简单调用o.update()。观察者需要自己通过持有的主题引用来拉取pull最新数据。这有时不够高效。改进方法是采用推模型在通知时把变化的数据或事件对象作为参数传递给update(Event event)方法。内存泄漏风险如果观察者被注册后没有被正确移除而观察者对象又因为被主题引用而无法被垃圾回收就会导致内存泄漏。尤其在Web应用中用户会话相关的观察者需要特别注意在会话结束时注销。5. 实战建议优先使用现成框架别自己从头撸轮子。在Java生态里java.util.Observable和java.util.Observer是内置实现但比较简陋且类而不是接口不推荐在新项目中使用。Spring的事件机制(ApplicationEventPublisher和EventListener) 是生产级别的首选它支持同步/异步、事件继承、条件过滤等高级特性。考虑事件对象Event Object不要只传一个空的通知。定义一个事件类如OrderPaidEvent里面包含事件相关的所有数据订单ID、金额、时间等。在通知时把这个事件对象传过去。这样观察者无需再回查主题效率更高信息也更完整。小心处理异常在主题的notifyObservers方法里如果直接循环调用观察者一个观察者抛出异常会导致后续的观察者收不到通知。通常需要做异常捕获和日志记录确保一个观察者的失败不影响整体。明确生命周期谁负责注册观察者谁负责销毁在Web应用中通常在Bean初始化时注册在上下文销毁时移除。清晰的生命周期管理能避免一堆诡异的问题。