2010-03-22 49 views
1

我有一個值對象,它存儲信息,例如金額。 getAmount()getter返回金額爲美分。但是在不同的地方,我們需要以美元計價。有兩種方法我可以想到:Value object getter

  1. 編寫一個轉換方法並將其放置在實用程序類中。
  2. 在值對象中添加一個getAmountInDollar()getter。

我更喜歡第二種方法。你怎麼看?這兩種方法的優缺點是什麼?

+0

對於金額來說,查看http://joda-money.sourceforge.net/可能是一個想法。該項目還沒有一個真正穩定的版本,但該API是乾淨和可用的。 – gpampara 2010-03-22 06:20:24

回答

1

這有點味道。但是,在我看來,如果這些信息與所討論的模型無關,那麼我更喜歡第一種方法。它保持模型清潔,另一個好處是它可以重複使用所有其他類型的值。如果你使貨幣類型變成該實用方法的另一個參數,它會更好,這樣它就更加靈活。提示:NumberFormat

+0

我明白了你的觀點。謝謝! – sarahTheButterFly 2010-03-22 02:41:45

0

因爲封裝是關於「黑匣子」場景中的數據和行爲的,所以我更喜歡第二個方面,即面向對象的說服。

+0

是的,那也是我最初的想法。但在閱讀凱文和BalusC的評論後,我會去的方法2. – sarahTheButterFly 2010-03-22 02:41:03

+0

@sarah:你不是唯一一個:) – 2010-03-22 03:10:22

0

我喜歡選項1,所以它可以用於任何可能以美分爲單位的值,而不僅僅是該特定類中的特定字段。它使您可以在代碼中的其他地方使用該選項,而無需重複代碼。

1

我更喜歡讓公共的API保持相當集中。一旦你開始向它添加不屬於「核心」組成部分的方法,你就有可能擁有一個非常複雜的野獸。在一個幾乎只有數據的類中,我會努力保持這種狀態。

最後,沒有明確的「最佳」答案......它只是基於您的個人經驗。 Mine說,一旦你開始「污染」API,它很難停下來,最終你需要打破這個課程。

該實用程序類還爲您提供了一個地方,可以將隨着時間的推移可能找到的其他相關但不完全的方法。

如果你的目標是減少班級數量,我會說不。如果你覺得在課堂上使用這種方法會使代碼「更清潔」,那麼就不要這樣做。

+0

謝謝。我會記住不要'污染'API。 – sarahTheButterFly 2010-03-22 02:44:58

3

老實說,我正在爲此付出努力,因爲我認爲貨幣應該總是以小數表示,在內部用作小數,然後根據需要在輸出上格式化。所以我可能會在輸出格式化程序中處理美元/美分問題。

如果我需要處理到其他貨幣單位的轉換,那麼我會創建一個Money類並將其與包含金額和單位信息的Money類一起返回(並且可能是與要用於服務的服務的連接根據需要進行轉換)。

+0

我不認爲你明白海報的要求。當她說「我有一個價值對象」時,我想她是在說她有一個Money類,並想知道如何從中獲得信息。她應該有'getAmountInDollars()'和'getAmountInEuros()'嗎?或者她應該只有一個'getAmount()'並讓消費者調用'convertToDollars()'或'convertToEuros()'? – Gabe 2010-03-22 02:47:13

+0

這當然有可能。我認爲這只是一個容器類,適用於各種數據,包括數量(也許是價格)。 – tvanfosson 2010-03-22 02:54:53

+0

是的,你說得對。這正是我所問的。 – sarahTheButterFly 2010-03-22 02:58:59

4

我認爲這可能是更好地指示哪個單位的過載來概括你的吸氣,這樣我就可以打電話getAmount()得到默認,但getAmount(Units.Dollar)getAmount(Units.Euro)也將提供,而無需創建一個新的getter每一個可能的貨幣轉換。

當然這會進一步推廣,因此您可以在Kelvin中內部存儲溫度值,但可以允許getAmount(Units.Celsius)getAmount(Units.Rankine)獲取其他尺度的溫度。

+0

謝謝!沒想到只要問這麼一個小問題就能學到很多東西。 :) – sarahTheButterFly 2010-03-22 02:59:54

+0

這是我喜歡的方法,我喜歡把它寫成getAmount(Locale)的想法。關於這一點的好處是,您可以修改getAmount方法來返回其他內容,而不會使API膨脹太多。 – David 2010-03-22 03:09:03

相關問題