1

我有一个值对象，它存储例如金额的信息。getAmount() getter 以美分返回金额。但是在不同的地方，我们需要以美元为单位。我能想到的方法有两种：

  1. 编写一个转换方法并将其放在实用程序类中。
  2. 在值对象中添加一个 getAmountInDollar() getter。

我更喜欢第二种方法。你怎么看？两种方法的优缺点是什么？

4

6 回答 6

4

我认为用一个指示什么单位的重载来概括你的吸气剂可能会更好，所以我可以调用getAmount()来获取默认值，但是getAmount(Units.Dollar)或者getAmount(Units.Euro)也可以在不必为每种可能的货币转换创建新吸气剂的情况下使用。

Of course this generalizes even further so you could have a temperature value stored internally in Kelvins, but could allow getAmount(Units.Celsius) or getAmount(Units.Rankine) to get the temperature in other scales.

于 2010-03-22T02:42:54.527 回答
3

老实说，我正在为此苦苦挣扎，因为我认为钱应该始终表示为小数，在内部用作小数，然后在输出时根据需要进行格式化。所以我可能会在输出格式化程序中处理美元/美分问题。

如果我需要处理到其他货币单位的转换，那么我将创建一个 Money 类并将其与包含金额和单位信息的 Money 类一起返回（并且可能是根据需要与用于转换的服务的连接） .

于 2010-03-22T02:33:00.790 回答
1

这有点口味问题。但是，在我看来，如果这些信息与所讨论的模型无关，那么我更喜欢第一种方法。它使模型保持干净，另一个好处是它可以重复用于所有其他类型的值。如果您将货币类型设为该实用程序方法的另一个参数，那就更好了，这样它就更加灵活了。提示：NumberFormat。

于 2010-03-22T02:27:18.410 回答
1

我更喜欢保持一个类的公共 API 相当集中。一旦你开始向它添加不属于“核心”的方法，你就会冒着拥有一个非常复杂的野兽的风险。对于一个几乎只保存数据的类，我会努力保持这种状态。

最后，没有明确的“最佳”答案......它只是基于您的个人经验。我的说，一旦你开始“污染”API，就很难停止，最终你还是需要打破这个类。

实用程序类还为您提供了放置其他相关但不完全是随着时间的推移可能会找到的方法的地方。

如果您的目标是减少课程数量，我会说不要。如果您觉得在类中使用该方法会使代码“更干净”而不是那样做。

于 2010-03-22T02:32:30.260 回答
0

因为封装是关于“黑盒”场景中的数据和行为，所以我也更喜欢第二种，用于面向对象的说服。

于 2010-03-22T02:27:36.770 回答
0

我喜欢选项 1，因此它可以用于任何可能以美分为单位的值，而不仅仅是该特定类中的特定字段。它留下了在代码中其他地方使用的选项，而无需重复代码。

于 2010-03-22T02:27:53.663 回答