CSC/ECE 517 Fall 2011/ch7 7a or

From Expertiza_Wiki
Jump to navigation Jump to search

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.

Introduction

Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's Object-Oriented Design Using Java, he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

Properties of Money

Money has certain properties and uses that must be considered in implementation.

Responsibilities/Using Money

The following are ways in which a representation of money should be able to be used: [1]

  • To represent a positive or negative amount of money.
  • Possibly representing multiple components of a currency - i.e. dollars and cents.
  • Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
  • To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
  • Addition, subtraction, multiplication, and division.

The degree to which of the above must be met will depend on the depth of the implementing project.

Different Currencies

Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.[2]

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. [3][4]

Immutable vs. Mutable

Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.[5]

Possible Representations

There are several possible ways to represent money in code.

Floating Point Number

Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. [6] Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results, especially with larger numbers.

Two Integers

For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. The main drawbacks of this implementation is the added overhead and storage required. [7]

One Integer, Implied Decimal Point

One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In Object-Oriented Design Using Java, Skrien considers this to be the best use of the primitive types for representing money. [8]

BigDecimal

Java offers a BigDecimal class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. [9] On the downside, this specification for rounding and scale is required, which adds code to the implementation. [10] BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. [11] While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented: 

BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
    return bd1.divide(bd2);
} catch(ArithmaticException ae) {
    return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}

Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. [12]

Class

In Object-Oriented Design Using Java, recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. [13] Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

Abstract Class

If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java: 

public abstract class Money implements Comparable<Money> {
  public long getAmount()
  public String toString()
  public int compareTo(Money m)
  public boolean equals(Object o)
  public int hashCode()
  public Money plus(Money)
  public Money minus(Money)
  public Money times(double factor)
  public Money dividedBy(double divisor)
  public Money negate()
}

[14]

Single Class

Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a Currency class which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in Object-Oriented Design Using Java: 

public class Money implements Comparable<Money> {
  private long amount;
  private Currency currency;
  public Money(long amount, Currency currency) {
    this.amount = amount;
    this.currency = currency;
  }
  public long getAmount() { return amount; }
  public Currency getCurrency() { 
    return currency; }
  public String toString() { ...above... }
  public int compareTo(Money o) { ... }
  public boolean equals(Object o) { ... }
  public int hashCode() { ... }
  public Money plus(Money) { ... }
  public Money minus(Money) { ... }
  public Money times(double factor) { ... }
  public Money dividedBy(double divisor) { ... }
  public Money negate() { ... }
}

[15]

Mixed Money

Using an Interface

Resources

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch7_7a_or&oldid=56359"