观察者模式的核心是通过Subject和Observer两个接口实现解耦：Subject提供attach、detach、notify方法，Observer定义update方法，双方仅依赖接口而非具体实现。

用接口实现观察者模式，核心不是写一堆类，而是靠两个契约接口把主题和观察者“隔开”——主题只认 Subject 接口，观察者只认 Observer 接口。只要双方遵守接口约定，谁改状态、谁响应更新、怎么通知、怎么处理，彼此完全不关心。解耦就落在这个“契约”上。

定义两个接口：一个管通知，一个管响应

必须先明确两个角色的最小能力边界：

• Subject 接口：只暴露三个动作——attach()（加观察者）、detach()（删观察者）、notify()（发通知）。它不暴露内部状态字段，也不指定通知内容格式，只保证“有变动就喊一声”。
• Observer 接口：只定义一个入口方法 update(Subject s)。参数传入的是 Subject 接口类型，不是具体实现类。这样观察者只能通过接口提供的 getter（如 s.getState()）获取数据，无法直接读私有字段，也避免强依赖。

主题实现要封装状态 + 自动触发通知

ConcreteSubject 不是简单存个值，而是把“状态变更”和“通知动作”绑死在 setter 里：

• 状态字段设为 private，比如 private String status;
• 提供 public setter，例如 public void setStatus(String s)，里面先赋值，再立刻调用 this.notify();
• notify() 方法遍历观察者列表，逐个调用 observer.update(this) —— 注意传的是 this（Subject 接口实例），不是 this.getClass()。
• 不提供“手动通知”或“批量设置后统一通知”的入口，防止业务代码绕过机制漏通知。

观察者实现要专注自身逻辑，不反向操作主题

每个 ConcreteObserver 的 update() 方法只做三件事：

• 从参数 Subject s 中安全取值，例如 String newState = s.getState();
• 基于新值执行本职工作：刷新 UI、写日志、发消息、更新缓存……
• 绝不调用 s.setState(...) 或任何可能触发二次通知的操作，否则容易形成循环调用。

如果某个观察者需要异步处理（比如网络请求），应在 update 内启动新线程或协程，而不是阻塞通知链。

注册与解绑必须严格配对，尤其注意生命周期

接口本身不解决内存泄漏，但接口设计强制你意识到“谁负责清理”：

• 注册发生在初始化阶段（如 Activity.onCreate、Vue.onMounted），调用 subject.attach(this)；
• 解绑必须在销毁前执行（如 Activity.onDestroy、Vue.onUnmounted），调用 subject.detach(this)；
• 若使用匿名内部类或 Lambda 做观察者，需确保能准确传入同一实例用于 detach，否则 remove 失效；
• 临时监听可封装成 AutoDetachObserver：update 执行完自动调用 detach，适合一次性的回调场景。