观察者模式：探讨如何实现一个具备变量变动监听功能的自定义集合

实现一个可监听的自定义集合，最核心的思路其实就一句话：**把所有的修改操作都收拢到明处的入口里，再在这些入口主动把变化“喊出来”。** 说白了，不是靠什么轮询或者监控内存地址，而是让集合本身知道什么时候变了，并且主动通知出去。观察者模式在这里起到的，正是“解耦”的作用——集合只管广播变化，不关心谁在听；监听器只管响应事件，不纠缠集合内部实现。 说得更直白一点，这套机制的关键在于：**修改操作走哪条路，必须由你把控；变化发生后，必须有人通知。** ### 定义清晰的监听契约 第一步，先设计一个干净、语义明确的回调接口。这个接口要聚焦于集合行为本身，不要掺杂其他逻辑。 - 用 `CollectionEvent` 封装关键信息：操作类型（ADD/REMOVE/SET/CLEAR）、被影响的元素、索引（如果适用）、旧值（比如 set 时） - 注意泛型擦除的问题，建议让接口带上泛型参数 `CollectionListener`，明确告诉监听器：你将要处理的是哪种类型的数据 - 接口的调用要轻量，不强制监听器抛异常或阻塞主线程 ### 在集合操作中嵌入通知点 拿 `ObservableArrayList` 来举例。继承 `ArrayList`，然后重写它那些会改变集合内容的 mutator 方法，在每一步操作里嵌进通知逻辑： - `add(E e)` → 先调用 `super.add(e)`，然后发出 `onAdded(e, size()-1)` 事件 - `set(int index, E e)` → 先取旧值 `get(index)`，再执行 `super.set(...)`，最后通知 `onSet(index, oldValue, e)` - `remove(Object o)` 和 `remove(int index)` 同理：先记录影响，再执行删除，再通知 - `clear()` 可以批量发一个 `onCleared()` 事件，避免一个一个通知造成性能浪费 ### 支持多监听器与生命周期管理 集合内部需要维护一个监听器列表 `List>`，并提供标准的注册与注销方法： - `addListener(CollectionListener listener)`：做非空检查，去重添加（可以用 `IdentityHashMap` 避免 equals 误判） - `removeListener(CollectionListener listener)`：安全移除，不抛异常 - 如果想支持更复杂的需求，比如按优先级通知，或者按条件过滤（比如只监听字符串长度大于5的元素），可以通过包装监听器或者增加注册参数来实现 ### 避免常见陷阱 实际生产环境里，有些细节容易翻车，值得特别留意： - **线程安全**：如果集合会被多线程修改，通知逻辑就必须同步处理。可以用 `synchronized(listeners)` 包裹迭代过程，或者干脆用 `CopyOnWriteArrayList` 来存储监听器，避免并发修改问题 - **内存泄漏**：监听器如果持有 Activity 或 Fragment 的引用，忘记注销就会造成泄漏。务必在 onDestroy 或 onDestroyView 中调用 `removeListener` - **递归通知**：监听器内部如果又去修改同一个集合，就可能引发栈溢出。为了避免这个麻烦，可以在通知前设置一个标志位临时屏蔽，或者在文档里明确写明：禁止在回调中修改源集合 - **不替代属性监听**：这里监听的只是集合本身的结构变化（增删改），而不是集合内对象的字段变化。如果想知道 `list.get(0).name` 变了，那需要在具体的对象上加观察者，不能指望集合来管