Ivy Wallet 项目中的金额格式化功能设计与实现

背景介绍

在个人财务管理应用Ivy Wallet中，金额显示是一个核心功能。用户Muhmad-hamdi提出了一个需求：希望可以设置是否显示金额的小数部分（如2500.00），因为部分用户偏好简洁的整数显示方式。

需求分析

这个需求看似简单，但涉及应用架构的多个层面。核心要求是：

1. 提供一个设置选项，允许用户选择是否显示小数部分
2. 默认情况下显示小数部分（向后兼容）
3. 修改后的显示方式应全局生效

技术方案设计

架构考量

经过项目维护者的讨论，决定采用以下架构方案：

1. 数据层保持不变：确保原始数据精度不受影响，只在显示层做格式化处理
2. 集中式格式化逻辑：创建一个专门的FormatMoneyUseCase用例类
3. 依赖注入：通过DI将特性开关注入格式化类
4. 渐进式迁移：先实现核心格式化逻辑，再逐步应用到各界面

关键技术点

1. 格式化用例类：

class FormatMoneyUseCase @Inject constructor(
  private val feature: Features
) {
  suspend fun format(value: Double): String {
    // 根据feature设置决定格式化方式
  }
}

2. 格式化策略：

• 使用DecimalFormat而非手动四舍五入，确保国际化支持
• 印度等地区的数字格式化有特殊要求，需考虑本地化

3. 特性开关：

• 通过IvyFeatures类管理
• 默认值为显示小数（保证向后兼容）

实现细节

线程安全

虽然金额格式化计算量不大，但为确保最佳实践：

• 将format方法标记为suspend
• 在后台线程执行格式化操作

测试策略

1. 单元测试覆盖：

• 小数显示/隐藏两种模式
• 边界值测试（如刚好0.5的情况）
• 本地化格式测试

2. 集成测试：

• 验证与现有功能的兼容性
• 性能测试确保不影响用户体验

经验总结

这个需求的实现过程展示了几个良好的开发实践：

1. 关注点分离：保持数据层原始性，仅在UI层做展示适配
2. 集中管理：通过统一用例类避免格式化逻辑分散
3. 渐进式改进：先建立核心机制，再逐步应用
4. 国际化考量：使用标准库而非自定义算法处理数字格式化

对于类似需求，开发者可以参考这种架构模式，确保功能扩展不影响系统稳定性和可维护性。