ITP 165: Introduction to C++
Project 4 - Cash Register, Part 1


Part I: Overview
  The purpose of this project is to familiarize you with the basic elements of creating objects in C++. For this project you will be responsible for implementing the customer and invoice classes. Each of these classes are essentially "data wrapers," in the sense that their primary responsibility is to maintain a collection of data about the objects they represent. This type of class is the easiest to implement. The majority of the interface you will be writing is merely protecting the private data members of each class.
Part II: Topics Covered
 
  • Dynamic Data Management - many of the strings in each object are char *'s. This means that the actual string is kept in a dynamic array. You will be responsible for maintaing data integrity and preventing memory leaks.
  • Data Hiding/Abstraction - The first aspect of Object Oriented Programming Languages (OOPL's), data hiding is accomplished by simply storing your data in private data members and forcing users of this class to use public member functions to access your data. Data abstraction happens when your public member functions do not strictly map to your private data members. The first example of this is in your invoice class. The public member function total is calculated rather than stored.
Part III: Implementing the Customer Class
 

The customer class is the easiest class to implement. For this class, you will be responsible for implementing the following interface:

  • Get/Set Functions - create get & set functions for each of the private data members of the customer class. NOTE: You will not need to create integer variables to track the size of each dynamically allocated string, use the strlen function instead. Just make sure to set each char * to NULL in the constructor. Use the functions g_name() & s_name() as examples for get and set functions.
  • Operator Overloading - You will be responsible for overloading the assignment (=) operator and some boolean operators (== & !=) for the customer class. Use the strcmp function on the name data member to implement the boolean operators. Use the copy constructor as an example for implementing the = operator.
  • Friend Functions - you will need to implement the stream operators << and >>. These operators actually belong to the iostream class, and thus must be declared friends.
Part IV: Implementing the Invoice Class
 

The invoice class is a little more difficult class to implement. Keep in mind that money data in this class is actually stored as integers and returned a floats. This means that you will need to multipy by 100 when inputting data, and divide by 100 when returning data. For this class, you will be responsible for implementing the following interface:

  • Get/Set Functions - create get & set functions for each of the private data members of the customer class. NOTE: Just follow the interface established by the class declaration (invoice.h). Use the functions g_name() & s_name() from the customer class as examples for get and set functions.
  • Public Member Functions - The invoice class uses some functions that do not map directly to data members. These functions will massage data before presenting it to users of the class.
  • Operator Overloading - You will be responsible for overloading the assignment (=) operator and some boolean operators (== & !=) for the customer class. Use the strcmp function on the name data member to implement the boolean operators. Use the copy constructor as an example for implementing the = operator.
  • Friend Functions - you will need to implement the stream operators << and >>. These operators actually belong to the iostream class, and thus must be declared friends.

 

The University of Southern California does not screen or control the content on this website and thus does not guarantee the accuracy, integrity, or quality of such content. All content on this website is provided by and is the sole responsibility of the person from which such content originated, and such content does not necessarily reflect the opinions of the University administration or the Board of Trustees