对外只暴露必要接口的本质是控制访问边界，需通过明确职责、私有化内部细节、谨慎提供getter/setter、删除非契约方法、禁止链式调用及依赖抽象接口等层次化设计实现。
对外只暴露必要接口，本质是控制访问边界——把不该被外部看到的全藏起来，只留刚够用的“门”。这不是简单加个 private 就完事，而是一套有层次的设计动作。
明确哪些该暴露、哪些必须隐藏
先梳理类的核心职责：它到底要提供什么能力？比如一个 PaymentService，业务上只需“发起支付”“查询状态”“退款”，那就不该暴露数据库连接、加密密钥、HTTP客户端实例等细节。所有内部字段、辅助方法、工具类引用，只要不直接参与这三项能力，一律设为 private 或包私有（default）。
用 getter/setter 控制属性访问，但不无脑暴露
- 属性本身必须
private，这是底线 - 只对真正需要外部读写的属性提供 getter/setter；例如订单号可读不可写，就只加
getOrderNo()，不加setOrderNo() - 集合类避免直接返回原始引用，改用
Collections.unmodifiableList()或封装成addItem()、getItemCount()等语义化方法
方法层面做减法：删掉“能用但不该用”的接口
常见误区是把内部工具方法也设成 public，方便自己调试或临时调用。结果别人一发现就用上了，后续重构时反而不敢动。正确做法是：
- 所有非契约性方法（即不属于核心职责的方法）一律
private - 如果子类需复用，再考虑
protected，但优先用组合代替继承 - 链式调用如
user.getProfile().getAddress().getCity()必须禁止——它等于把三个类的结构强绑定在调用处，应封装为user.getCity()这样单一入口
配合接口抽象，让“必要接口”真正稳定
光靠类内封装还不够。比如一个服务类依赖了具体的数据访问实现，那它的“必要接口”就容易随 DAO 变动而失效。此时应：
- 定义
PaymentGateway接口，只声明pay()、refund()等业务方法 - 让服务类依赖该接口，而非具体实现类
- 通过构造器注入实现，使外部可轻松替换模拟实现或不同厂商 SDK
不复杂但容易忽略。
