平衡过度封装与直接暴露的核心在于封装应服务于协作契约的清晰性与变更容忍度，而非单纯私有化；需依成员是否构成对外承诺、是否稳定、是否支持扩展来动态决定可见性。
界定过度封装与直接暴露的平衡，核心不在于“是否隐藏”，而在于“谁需要知道、何时需要知道、为什么需要知道”。关键基准是：**封装应服务于协作契约的清晰性与变更容忍度，而非单纯追求私有化。**
以接口契约而非访问权限定义边界
过度封装常表现为把本该由调用方参与决策的逻辑硬塞进类内部（如把所有条件判断封死），或把本该公开的稳定行为设为私有（如一个始终不变的计算规则却无法复用）。直接暴露则体现为把实现细节（如字段名、缓存结构、中间状态）当作公共API开放。
- 问自己：这个成员是否构成该类对外承诺的一部分？它的变化是否必然导致调用方修改？
- 稳定的行为（如calculateTax()）、明确的输入输出契约（如parse(json: String): Result<User>），即使内部简单，也值得公开；
- 易变的实现（如cacheMap、retryCount）、临时状态（如isProcessing）、框架适配层（如jacksonNode字段），应默认隐藏。
按演化阶段动态调整可见性
封装不是一锤定音的设计动作，而是随系统演化的持续判断。初期可适度放宽（如用protected代替private），待使用场景浮现后再收敛；成熟模块则应收紧，用不可变返回值、只读集合、接口而非具体类来约束依赖。
- 新功能上线时，优先用package-private（Java）或internal（Kotlin）验证使用模式，比直接public更安全；
- 当多个模块开始绕过你的API、直接访问内部字段时，说明你暴露了不该暴露的东西，或没提供足够支撑能力；
- 当别人总要为你加getter来完成本该由你负责的逻辑（如“请加个getDiscountRate()，我来算最终价”），说明你封装过度——应该提供calculateFinalPrice()。
用测试作为封装合理性的探测器
单元测试的脆弱性是封装失衡的显性信号。如果测试必须大量mock内部状态、反射访问私有字段、或因重构一个算法就需重写十几个测试，大概率是封装粒度错了。
- 好封装的类，测试应聚焦在输入→输出、状态迁移、异常路径，而非内部步骤；
- 若测试被迫依赖private方法，说明该方法本应是公开契约的一部分，或它属于另一个职责更单一的类；
- 集成测试能正常运行但单元测试频繁断裂，往往意味着你把协作逻辑错误地锁进了单个类里。
让“需要扩展”成为提升可见性的唯一理由
除非有明确的扩展需求（如子类定制、策略替换、框架回调），否则不要为“将来可能有用”提前开放。真正的扩展需求会带来具体上下文：谁扩展？扩展什么？在什么流程中触发？
- protected方法必须附带文档说明：“供子类重写以定制XX行为，例如支付渠道的签名方式”；
- 开放public构造函数前，确认调用方真的需要自己组装实例，而不是通过工厂或构建器；
- 把字段设为public final仅适用于真正意义上的常量（如MAX_RETRY = 3），而非为了省写getter。
不复杂但容易忽略：每次添加public或protected成员时，写下一行注释——它解决的具体问题是什么，以及谁会因此受益。如果写不出来，先放一放。
