Java类方法排序：按功能vs按可见性分组的取舍与社区规范

方案A（功能分组：public-private交替）的利弊 #

优势 #

• 逻辑关联紧密：public方法与其专属的私有辅助方法相邻，阅读某个功能（比如你提到的Router Bean端点）的完整逻辑时，无需上下跳转，连贯性强，能快速理解整个流程。
• 维护效率更高：修改某个功能时，相关代码集中在一起，不容易遗漏辅助方法的调整，也能避免误改其他功能的代码。

劣势 #

• 公共API分散：类对外暴露的核心public方法被私有方法打断，想要快速梳理类的全部对外能力时，需要跳过中间的私有实现，效率较低。
• 整体结构零散：功能较多时，public和private方法交替出现，类的结构显得不够规整，不利于快速把握类的整体轮廓。

方案B（可见性分组：先public后private）的利弊 #

优势 #

• 核心能力一目了然：所有public方法集中在类的前部，能快速掌握类对外提供的所有功能，符合“重要内容优先展示”的原则，对于Router Bean这类需要明确端点定义的场景，能快速定位所有对外接口。
• 类结构规整：按可见性分层的结构符合多数开发者的阅读习惯，能快速区分对外接口和内部实现边界。

劣势 #

• 逻辑连贯性弱：阅读某个public方法的实现时，需要跳转到类的后半部分查找对应的私有辅助方法，辅助方法越多，来回跳转的认知负担越大。
• 维护易脱节：修改public方法时，对应的辅助方法在类的其他位置，可能会忽略相关修改，或者需要频繁滚动代码，影响效率。

Java社区的约定与选择 #

Java社区没有强制统一的标准，两种方案都有广泛使用场景：

• 主流代码规范（如Google Java Style Guide）推荐按可见性排序，优先展示public方法，目的是让开发者先关注类的对外接口。
• 但不少团队会根据业务场景选择方案A，尤其是当每个public方法逻辑独立、私有辅助方法仅服务于对应public方法时，功能分组的可读性优势更突出。

本质上，这更多是团队偏好问题，团队内部保持统一的风格比纠结方案本身更重要，统一的规范能减少团队成员的认知成本，提升协作效率。

内容的提问来源于stack exchange，提问作者Kalman Yudin