Saint Louis University |
Computer Science 180
|
Dept. of Math & Computer Science |
Please make sure you adhere to the policies on academic integrity.
Please see the general programming webpage for details about the programming environment for this course, guidelines for programming style, and details on electronic submission of assignments.
The files you may need for this assignment can be downloaded here.
For this assignment, you are allowed to work with one other student if you wish (in fact, we suggest that you do so). If any student wishes to have a partner but has not been able to locate one, please let the instructor know so that we can match up partners.
Please make sure you adhere to the policies on academic integrity in this regard.
Chapter 1.6 of the text introduce an example of a credit card
class, giving the class definition in
For this assignment, we will use that class as our model, however our goal is to adapt it to meet new specifications which more accurately model typical credit card terms. In particular we will introduce a monthly interest calculation, a minimum monthly payment, and a penalty for a late payment. Precise details are in the coming section.
Meeting the formal specifications is an important aspect of programming. For this reason, please make sure that you carefully read and follow the specifications outlined in this section when designing your program. If you feel that there are any ambiguities, ask for clarification before completing the assignment.
At minimum, the state information for a credit card should include the following:
The public member functions must include each of the following. We describe each giving the formal prototype (i.e., parameters and return types) as well as a prose description of the expected behavior.
CreditCard(string no, string nm, int lim, double rate, double bal=0)
A constructor which allows user to specify some initial
parameters. Note that the default starting balance is zero,
unless otherwise specified.
string getNumber() const
accessor method for credit card number
string getName() const
accessor method for card owner's name
int getLimit() const
accessor method for current limit
double getRate() const
accessor method for current interest rate.
double getCurrentBalance() const
accessor method for up-to-date balance
double getPreviousBalance() const
accessor method for balance, as it had been computed at end of
previous month.
Note: this value should remain unchanged until the next monthly statement is generated, even if payment is received.
int getMinPayment() const
accessor method for minimum monthly payment, as it had been
computed at end of previous month.
Note: this value should remain unchanged until the next monthly statement is generated, even if payment is received.
bool chargeIt(double price)
This is called when the card owner attempts to make a purchase
of the given price. The charge should only be approved if the
resulting current balance remains at or below the user's credit
limit. The return value represents whether or not the charge is approved.
You should refuse charges for a negative amount.
void makePayment(double payment)
This is called when the card owner submits the specified
payment. The balance should be reduced appropriately.
You should ignore payments of a negative amount.
string toString()
Though not in the original code in the book, we introduce this
technique in our version as a convenient convention to simplify
output. This routine does not generate output directly, but
instead prepares the output in a string and returns that string
to the caller.
std::ostream& operator<<(std::ostream& out, const CreditCard& c)
Paired with the above toString() method, the overload
of the output operator can now be implemented rather trivially,
as shown in our sample code. Though the text does not use this
convention, we will do so throughout the semester for uniformity.
void endOfMonth()
This method is called to signify the end of the month. At this
point in time, the method is in charge of various aspects of
bookkeeping. In particular, an updated balance should be
computed and recorded, as well as a minimum monthly payment.
Looking back at the end of the previous month, there should have been both a recorded balance as well as a minimum monthly payment determined at that time (if this is the end of the first month, assume both of those figures were $0).
The new balance and new minimum payment should be computed as follows:
If payments received this month do not fulfill the full
stated balance as of the end of the previous month, then
an interest charge
of
If payments received this month do not fulfill the stated minimum monthly payment as computed at the end of the last month, an additional late charge of $20 should be added to the balance.
This new current balance should be recorded as the official "end of the month" balance.
If the new balance is non-zero, a minimum monthly payment should be calculated and recorded. Generally, the minimum payment will be the larger of $30 or 5% of the new balance (rounded to the nearest dollar). However in the case that the above calculation results in a minimum payment which is greater than the balance itself, the minimum payment should be set to the balance itself (rounded down to the nearest dollar).
As an example, assume a new card is created with zero balance and 0.79% monthly interest (approximately 9.5% per year). During the first month,charges of $25, $500 and $100 are made to the card. When endOfMonth() is called, no late charge or interest charge should be incurred, because there was no minimum payment or balance as of the beginning of the month. However at this time, the current balance of $625 and a minimum payment of $31 is recorded.
Continuing, lets assume that the next month includes new charges
totaling $228, and payments totaling $300. If endOfMonth()
is again called, the processing should be handled as follows. The
received payments of $300 surpass the minimum monthly requirement of
$31, so no late charge is assessed. However, the $300 does not
constitute payment in full against the previous monthly balance of
$625. Therefore interest will be computed based on the current
balance which is
In the next month, assume that charges of $300 are incurred, and a payment of $600 is received. In this case, at the end of the month, no late fees or interest are charged, because the payment of $600 exceeds the previous month's balance of $557.37. At this point the updated balance of $257.37 ($557.37+$300-$600) is recorded, along with a minimum monthly payment of $30.
In the next month, assume that there is no activity on the card. Because there is an unpaid balance of $257.37, an interest charge of $2.03 is added to the balance. Worse yet, because not even the minimum payment from the previous statement was paid, a late charge of $20 is added to the balance. Therefore the new balance is $279.40. The minimum payment assigned for the subsequent month is again $30.
The text demonstrated the functionality of their original credit card
class by means of a Test program shown in
For this assignment, we wish to have you submit your own version of such a test program. In particular, please make sure that you demonstrate those areas of additional functionality which go above and beyond the original credit card class given in the text (e.g., monthly statements, penalties, etc). You might start by trying to script the example given above. Yet you should go on to add additional such tests (as we will certainly do when we grade your program!)
As an example, here is a simple test program which simulates the first two months of activity as described in this handout. Ideally, you might start with that file and then expand upon the test to show more scenarios which might arise.
Please see details regarding the submission process from the general programming web page, as well as a discussion of the late policy.
You should submit four files:
CreditCard.h - The header file which contains the class
definition, akin to that of
CreditCard.cpp - A file which includes additional code
providing the bodies of the member function for class CreditCard,
akin to that of
TestCard.cpp - A file which provides a main driver for
testing the credit card, akin to that of
readme - For every assignment, you will be asked to submit such a text file. In general, this provides a way for you to add any further comments you wish to make to the grader. For many assignments, there will also be additional explicit requirements for the contents of this file. For this assignment, please make sure to explain the design decisions you made in regard to the private data members of the CreditCard class.
You may wish to use the code from the book as your original model. For your convenience, we will provide those original files as well as a makefile for compiling the project.
Preface: If you are going to attempt the extra credit challenge, please first complete and submit the required class, CreditCard. Then copy and rename those files to define a new class CreditCardExtra for this challenge. (we want to make sure to avoid penalizing your original submission because of mistakes incurred in attempting the extra credit.)
Based on the above assignment specifications, a credit card owner was receiving what is known as a grace period. That is, purchases could be charged to the card, yet the debt was interest-free until the end of the month. In fact, if the previous monthly balance was paid in full before the end of the next month, no interest charges were incurred.
For extra credit, we would like to take away such a grace period for users who do not pay off their balance in full. In particular, once a month ends with a non-zero balance, interest computation should be performed daily (at 1/30 of the monthly interest rate) rather than monthly. The daily computation of interest should continue until a point in time when a user's balance reaches zero. At this point, the grace period policy should be reinstated, reverting to interest computations at the end of the month.
Implement this new specification, adding a new method,