面向对象重构：封装集合（Encapsulate Collection）保护对象私有变量

文章小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《面向对象重构：封装集合（Encapsulate Collection）保护对象私有变量》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

封装集合的核心是防止外部乱改而非隐藏，因直接返回可变集合会绕过宿主类的状态管控与业务逻辑，导致数据不一致、并发异常及调试困难；应返回只读视图并提供受控修改方法。

封装集合的核心不是“不让别人看到”，而是“不让别人乱改”。集合是引用类型，一旦直接返回原始集合（比如 List 或 ArrayList），调用方就能增删改查、排序清空——而宿主类完全不知情，业务逻辑（如总额更新、状态校验、日志记录）全部被绕过，bug 难定位、难复现。

为什么不能直接返回集合本身

直接暴露可变集合违背了封装的基本原则：对象应掌控自身状态。常见风险包括：

• 外部代码调用 list.add() 或 list.clear()，但宿主类的缓存字段（如 _orderTotal）未同步更新
• 多线程环境下，未经同步的集合修改引发 ConcurrentModificationException 或数据不一致
• 调试时发现集合内容异常，却无法追溯是谁、在何处修改的——因为修改点分散在各处，而非集中在宿主类内

正确做法：分离读与写权限

把“能看什么”和“能做什么”拆开设计：

• 取值函数返回只读视图：如 Java 中用 Collections.unmodifiableList(list)，C# 中用 AsReadOnly() 或 IEnumerable
• 提供明确的修改入口：如 addOrderLine()、removeOrderLine()，所有变更必须流经这些方法
• 禁止设值函数（setOrders()）——若需批量替换，改用 replaceOrders(List newOrders) 并在内部做完整重置与校验

关键细节：只读 ≠ 安全，还需配合初始化与校验

仅返回只读包装还不够。必须确保：

• 集合字段初始化即为空实例（如 new ArrayList<>()），避免 null 判断污染业务逻辑
• 添加/移除方法中嵌入必要逻辑：金额累加、状态检查、事件通知、审计日志等
• 若集合元素本身可变（如 OrderLine 含公共 setter），需考虑是否也应封装其属性，否则“防外不防内”

如何识别该重构的时机

当出现以下任意情况，就该立即封装集合：

• 类中已有针对集合的操作方法（如 calculateTotal()），但外部仍可绕过它们直接操作集合
• 测试中频繁出现“集合内容意外改变”类问题，且修改点不在宿主类内
• 集合被用于计算缓存值（如总数、平均值、最新时间），而缓存未随集合变化自动失效或更新
• 接口文档或团队约定说“请勿修改返回的集合”，但没人能强制执行——这说明设计依赖自觉，不可靠

今天关于《面向对象重构：封装集合（Encapsulate Collection）保护对象私有变量》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！