封装集合的核心是防止外部乱改而非隐藏，因直接返回可变集合会绕过宿主类的状态管控与业务逻辑，导致数据不一致、并发异常及调试困难；应返回只读视图并提供受控修改方法。
封装集合的核心不是“不让别人看到”，而是“不让别人乱改”。集合是引用类型，一旦直接返回原始集合（比如 List 或 ArrayList），调用方就能增删改查、排序清空——而宿主类完全不知情，业务逻辑（如总额更新、状态校验、日志记录）全部被绕过，bug 难定位、难复现。
为什么不能直接返回集合本身
直接暴露可变集合违背了封装的基本原则：对象应掌控自身状态。常见风险包括：
- 外部代码调用
list.add()或list.clear()，但宿主类的缓存字段（如_orderTotal）未同步更新 - 多线程环境下，未经同步的集合修改引发
ConcurrentModificationException或数据不一致 - 调试时发现集合内容异常，却无法追溯是谁、在何处修改的——因为修改点分散在各处，而非集中在宿主类内
正确做法：分离读与写权限
把“能看什么”和“能做什么”拆开设计：
- 取值函数返回只读视图：如 Java 中用
Collections.unmodifiableList(list)，C# 中用AsReadOnly()或IEnumerable<t></t> - 提供明确的修改入口：如
addOrderLine()、removeOrderLine()，所有变更必须流经这些方法 - 禁止设值函数（
setOrders()）——若需批量替换，改用replaceOrders(List<orderline> newOrders)</orderline>并在内部做完整重置与校验
关键细节：只读 ≠ 安全，还需配合初始化与校验
仅返回只读包装还不够。必须确保：
- 集合字段初始化即为空实例（如
new ArrayList()），避免null判断污染业务逻辑 - 添加/移除方法中嵌入必要逻辑：金额累加、状态检查、事件通知、审计日志等
- 若集合元素本身可变（如
OrderLine含公共 setter），需考虑是否也应封装其属性，否则“防外不防内”
如何识别该重构的时机
当出现以下任意情况，就该立即封装集合：
- 类中已有针对集合的操作方法（如
calculateTotal()），但外部仍可绕过它们直接操作集合 - 测试中频繁出现“集合内容意外改变”类问题，且修改点不在宿主类内
- 集合被用于计算缓存值（如总数、平均值、最新时间），而缓存未随集合变化自动失效或更新
- 接口文档或团队约定说“请勿修改返回的集合”，但没人能强制执行——这说明设计依赖自觉，不可靠
