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 formatted from a binary representation, an approximate value is stored in the float. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate values, especially with larger numbers. [6]

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 http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html] 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

Abstract Class

Single Class

Mixed Money

Using an Interface

Handling Conversion

Resources

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