Course Home | Course Policies | Homework | Lab Open Hours | Programming | Labs | Schedule & Lecture Notes

Programming Assignment 01

Due: Friday, September 18, 2009, 11:59pm

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.


Collaboration Policy

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 introduces an example of a credit card class. We will use that class as a model for that assignment, but we are making some adaptions and adding additional functionality. In particular, we will introduce bookkeeping for a typical monthly cycle.


Meeting formal specifications is a vital aspect of programming. The public interface for a class serves as a contract for coordination between the implementor of the class (in this case, you) and the users of that class (in this case, you and the rest of the class). As part of this assignment, we are providing a header file, CreditCard.h, which defines the public interface for the CreditCard class. This includes signatures for the required public member functions. Formal documentation has been embedded in the source code and is viewable here. 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.

A CreditCard instance manages aspects of a typical credit card account. Some of the functionality is rather basic, for example keeping track of the owner's name, the card number, the credit limit. There must also be basic support for managing the up-to-the-minute balance on the account, including allowing for the customer to make charges against the card (though not exceeding the limit) and making payments to pay off some portion of the current balance.

The most challenging aspect of our specification is that your class must also manage the typical monthly cycle for a credit card. A customer can stay in good grace each month by paying the full balance as it existed at the time of the most recent formal statement. (even if new charges this month means that the current balance is non-zero). A good customer is never charged interest or fees. However, additional charges are accrued when that previous balance is not paid off. In particular, once a customer loses good graces, interest is charged on the entire current balance (old charges and new charges). Furthermore, if the customer did not even meet the minimum payment schedule established by the company, an additional late fee is assessed.

More formally, a processMonth method will be triggered at the end of each hypothetical month. The responsibility of that method is to calculate appropriate interest and fees and to recalculate a minimum payment for the coming month. The formal rules are as follows.

The official set of public methods which must be supported is as follows:

The constructor

The constructor has the following signature

Note well that we have varied slightly from the convention of the text's version. The parameter lim defines the credit limit for the card (expressed in dollars). The parameter bal defines the initial balance on the account (expressed in cents). We provide a default initial balance of 0, as a new account typically starts with a zero balance. However, we leave open the possibility that someone may open a new credit card while transferring a non-zero balance from elsewhere.

Although your class may have other private attributes in addition to those listed as parameters, all others attributes should have initial values that are not directly customizable. For example, the minimum required payment for the first month of a new card is automatically zero (even with a non-zero starting balance).


There are seven standard accessor functions to return the values of respective aspects of the underlying state. Those signatures are:


Note Well: None of your methods should generate any output. We have provided an implementation already for the output stream operator (<<) and the user of a credit card can print their own information based on values returned by the standard accessors.

An example

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 $325.75, $800 and $100 are made to the card. When processMonth() 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 $1225.75 and a minimum payment of $61 is recorded.

Continuing, lets assume that the next month includes new charges totaling $228, and payments totaling $300. If processMonth() is again called, the processing should be handled as follows. The received payments of $300 surpass the minimum monthly requirement of $61, so no late charge is assessed. However, the $300 does not constitute payment in full against the previous monthly balance of $1225.75. Therefore interest will be computed based on the current balance which is $1153.75 ($1125.75 + $228 - $300). At the specified rate, an interest charge of $9.11 is added to the balance, resulting in an end of the month balance of $1162.86, and an associated minimum monthly payment of $58.

In the third month, assume that there is no activity on the card. Because there is an unpaid balance of $1162.86, an interest charge of $9.19 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 $1192.05. The minimum payment assigned for the subsequent month is $60.

In the fourth month, the customer makes a payment of $1200 and an additional purchase of $500. In this case, at the end of the month, no late fees or interest are charged, because the payment of $1200 exceeds the previous month's balance of $1192.05. At this point the updated balance of $492.05 ($1192.05 - $1200 + $500) is recorded, along with a minimum monthly payment of $30.

In the fifth month, the customer makes a payment of $475 and does not charge any purchase. Because there is an unpaid balance of $17.05, an interest charge of $0.13 is added to the balance. Therefore the new balance is $17.18 and the minimum payment assigned for the subsequent month is also $17.18.

Your Private Implementation

Thus far, we have given a clear explanation of the public semantics of the class, and examples of several scenarios. However we have said nothing at all about how you are to implement this. Based on the concept of encapsulation, it is up to you how to accomplish this.

You may feel free to add any private members to the original definition in CreditCard.h. Clearly, some basic attributes will be necessary to store the information needed for the standard accessor methods. However you will likely need to store additional internal information to properly support the specifications.

We strongly suggest that you think a bit about your design before getting too far into your implementation.

Testing your Credit Card class

For this assignment, we wish to have you submit your own version of a test program which utilizes the CreditCard class. Your test may only use the public behaviors which have been defined for this assignment.

To get you going, we provide an initial implementation of Test_CreditCard.cpp which simulates the five months of activity as described in the above example. However, you should go on to add additional such tests. Those five months do not demonstrate a complete set of scenarios which may arise. We will certainly test more possibilities when we grade your program!

Grading Standards

The assignment is worth 10 points.

Files You Will Need

Rather than have the entire project in a single file, we would like to shift to a more standard development practice where components of a program are stored in a combination of different files which support better reuse of components. Please read Chapter 1.6 of our text for a discussion of this breakdown.

For this assignment, we are providing four files. These can either be downloaded from this website, or copied directly into your account on turing, with the command

    cp -R /public/goldwasser/180/programs/credit .

The files are:

Submitting Your Assignment

Please see details regarding the submission process from the general programming web page, as well as a discussion of the late policy.

Because this is a pair assignment, you should abide by the following procedures:

In addition, one member of the team should submit the three source code files: