Ruby组合类最佳实践咨询：方法数量与存放路径

1. 组合类的方法数量限制，以及“仅含一个非私有方法”的说法是否正确？ #

• 没有严格的方法数量上限，核心原则是单一职责：组合类要聚焦某一类特定功能逻辑，不能变成包揽各种无关逻辑的万能工具类。
• 关于“仅包含一个非私有方法”的说法，这是一种偏向极致的单一职责实践，并非强制规则。这种说法的核心逻辑是：让组合类的职责极度明确，调用方只需要和一个核心接口交互，最大程度降低耦合。比如一个处理订单支付的组合类，只暴露process_payment这个非私有方法，内部的参数验证、调用支付网关、记录操作日志等逻辑都封装为私有方法。
• 实际项目中，如果一组方法属于强关联的同一业务域，也可以暴露多个非私有方法。比如一个用户资料处理的组合类，同时暴露update_basic_info和reset_password是合理的，只要这些方法都围绕“用户资料管理”这一核心职责。

2. 组合类的目录存放选择 #

没有绝对标准，可根据组合类的职责和使用场景灵活选择：

• 如果是为模型层服务的通用逻辑：比如多个模型都需要的格式转换、数据校验逻辑，可以放在app/models/concerns下。注意concerns更偏向Mixin（混入）用法，如果是纯组合类（通过实例化调用而非include），可以调整命名空间，或者在concerns下建子目录区分。
• 如果是独立的业务服务逻辑：不依赖特定模型、或跨模型的业务流程，放在app/services下更合适。比如处理跨模型的“用户注册全流程”组合类，放在services目录更符合服务对象的定位。
• 自定义目录：如果项目中组合类数量较多且独立，可以新建app/compositions目录专门存放，Rails默认会加载app下的子目录，无需额外配置，这种方式职责划分更清晰。

经验分享：优先根据职责划分目录，而非刻板遵循规则。和模型强绑定的逻辑用concerns，独立业务服务用services，数量多且独立的组合类用自定义目录更易维护。

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