子类继承父类API请求方法的设计：通用接口vs专属方法？

• 优先为子类实现专属方法（比如UserManager.get_users()），好处很实在：
  • 调用成本更低：不用让调用者记忆各业务端点的特殊参数、路径，看方法名就知道功能，代码可读性和可维护性大幅提升。
  • 封装业务细节：把每个业务的API参数、端点路径等细节藏在子类方法内部，后续API变更时只需修改对应子类，不用改动所有调用处。
  • 减少低级错误：专属方法可以明确规定参数类型、必填项，避免通用方法因参数传错导致的运行时问题。
  • 扩展性更强：如果某个业务需要额外逻辑（比如参数预处理、结果转成业务模型），直接在专属方法里添加即可，不会影响其他业务模块。

即使已经测试过父类的get_omd_assets()，仍然需要为子类的get_users()等专属方法编写测试：

• 验证参数传递正确性：确保子类传递给父类的参数（比如用户接口路径、过滤条件）符合业务API要求，避免路径拼写、参数格式等错误。
• 覆盖业务逻辑：如果专属方法包含参数默认值设置、结果转换等业务逻辑，必须测试这些逻辑的正确性。
• 隔离变更影响：后续父类方法更新时，子类专属方法的测试能快速验证是否影响了业务功能的正常运行。
• 起到文档作用：测试用例本身就是直观的使用示例，能清晰展示方法的预期输入输出和行为。

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