There is a problem in the previous discussion and has not been analyzed. It is the type of data indicating "currency". Therefore, if you continue to discuss, you must exceed the scope of the interview topic, so another article.
If the requirements for currency information are just to distinguish between the monetary species represented by different MONEY objects to ensure that only the same currency object can be calculated, then both string, int or Enum is enough. However, in a slightly larger project, the requirements may not be limited to this. For example, you need to display the correct currency symbol when the display amount is displayed, or some of the 3-digit currency code is also required, such as the USD, and RMB represents RMB. In the absence of user input or interacting with other systems, it is necessary to judge whether the input data is legal, system supported currency. In the case of these needs, natural, we need a separate class currency. As for the specific type of Currency inside, see the discussion in the previous one.
Therefore, the Money class should look like this:
public class Money {private Currency currency; private BigDecimal amount; public Money (Currency aCurrency, BigDecimal aAmount) {...} public Money add (Money aMoney) throws IncompatibleCurrencyException {...} public Money subtract (Money aMoney) throws IncompatibleCurrencyException { ...}}
If the system needs to be used by the user to maintain the currency supported by the system, it is generally necessary to maintain a table in the database. At this time, CURRENCY is a sustainable class.
Regarding this design problem, please refer to the "prefactoring" of "preFactoring" in front. Although the article mainly discusses the analysis and field modeling phase, many discussions are still effective for design phases.
