封装通过划定边界促高内聚、暴露最小接口降耦合：私有状态+受控方法保障一致性，接口抽象隔离实现，依赖注入显性化协作，分包按业务域强化模块边界。
封装本身不是低耦合或高内聚的直接手段，而是实现二者的底层支撑机制。真正起作用的是：用封装划定边界，把职责收拢到类内部（促高内聚），再通过接口暴露最小契约（降低耦合）。
用封装明确类的“专属责任”
高内聚的核心是让一个类只管一件事，而封装决定了这件事的范围和可见性。
- 把状态（字段）设为 private，强制外部通过方法访问——不是为了“藏”，而是为了控制变更入口，避免随意修改破坏内部一致性
- 方法只暴露必要行为，比如
User类提供changePassword()，而不是开放passwordHash字段供外部直接赋值 - 拒绝“工具方法塞进业务类”：日期格式化、JSON序列化等通用能力，应独立成
DateFormatter或JsonUtils，不混在OrderService里
用封装+接口实现依赖隔离
低耦合的关键不是“不依赖”，而是“依赖抽象、不绑定实现”。封装配合接口，才能把这种抽象落地。
- 定义清晰接口（如
PaymentService），只包含支付成功后该做的事（更新状态、发通知），不掺杂日志、库存、风控等无关逻辑 - 实现类（如
AlipayPaymentService）把所有支付宝细节封装在内部，对外只遵守接口契约 - 调用方（如
OrderService）只持有PaymentService接口引用，完全不知道也不需要知道背后是支付宝还是微信
用封装约束协作方式，避免隐式依赖
很多耦合来自“看不见的连接”，比如静态工具调用、全局单例、new 具体实现——这些都绕过了封装边界。
- 禁止在类内部
new AlipayClient()或调用StringUtils.isBlank()；改为构造器注入HttpClient和StringValidator接口 - 字段声明用 final + 接口类型，如
private final UserRepository userRepository;，既体现不可变性，又强调依赖抽象 - 测试时能直接传入
new MockUserRepository()，说明封装已把依赖显性化、可替换
用封装推动合理分包与模块边界
包结构是封装的物理延伸。一个包里的类应该共同守护同一块职责，且对外只暴露稳定接口。
- 按业务域分包（如
com.example.order），而非技术层（如controller、service）——避免跨包随意跳转、职责发散 - 包内类之间可以有较紧密协作，但对外只提供少数几个门面接口（Facade），其他实现类设为 package-private
- 禁止
order包里出现RedisTemplate或JdbcTemplate字样；数据库操作应封装在OrderRepository接口背后
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
