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.

Collaboration Policy

For this assignment, you must work individually in regard to the design and implementation of your project.

Please make sure you adhere to the policies on academic integrity in this regard.

Contents:

• Overview
• Our Model
• Files we are providing
• Submitting Your Assignment
• Grading Standards

Overview

This assignment is designed to be a bit of a puzzle. In the end, it will take relatively few lines of actual code. The key will be to successfully settle upon a those lines of code. The topic we wish to explore are the subtleties involve the life cycle of an object: how and when objects are constructed and destroyed; the distinctions between objects, references to objects, and pointer variables; the ways in which information is passed to and from functions. For preparation, we strongly suggest that you review all aspects of the object demo that we have discussed in class.

This project attempts to model the relationships between car manufacturer, car dealers, and the end customers. The manufacturers produce cars and in some cases provide support to dealers for properly servicing cars. The dealers act as intermediaries between the manufacturers and the customers. The customer is the end client and interacts only with the car dealer (never with the manufacturer).

Our Model

There are three main components to this project: the Car class, the Dealer class, and a Customer application.

• The Car class.
  We have implemented this class and you should not make any changes to it. It has been carefully designed to provide different access levels for varying roles (somewhat as a car manufacturer). The relevant behaviors of a car are as follows:
  
  
  • These public behaviors are available to anyone who has an instance of a car (e.g., a customer).
    
    • void breakIt()
      This breaks the car (so drive safely!)
    
    
    • operator<<
      This produces a description of the relevant attributes of a car (color, number of doors, whether it is currently broken, and the name of the dealer at which it was purchased).
    
    
    • Note well that a member of the general public cannot directly construct a car.
  
  
  • Our Car class has officially denoted the Dealer class as a "friend", providing dealers with an additional level of support.
    
    
    • A dealer is allowed to order the construction of a new car, using the constructor form:
      Car(string color, int doors, int dealerName)
      where color specifies the color of the car (e.g. "red"), doors specifies the number of doors (e.g. 2-door, 4-door), and dealerName the name of the dealer at which the car is being purchased.
    
    
    • getDealerName
      Returns the name of the dealer as was specified when the car was originally constructred (this allows a dealer to determine if a particular car instance was one purchased through the dealership).
    
    
    • void fixIt()
      A dealer has necessary abilities to fix a broken car. A call to this method on a Car instance resets the state of the car to be fixed.
  
  
  • Restricted for all:
    
    
    
    • No one (not even a dealer) is allowed to 'clone' a car. We have intentionally disabled both the copy constructor for the Car class as well as the typical semantics of the assignment operator (=). Any direct or indirect use of such syntax will result in a car which is tagged as 'invalid'.


• The Dealer class.
  The Dealer class will be your main contribution to the project. We are providing you with files that get you going, but you must design the workings of the class yourself. Your main task is to design and implement two public functions which are to be supported by the Dealer class (and presumably used by a customer).

  • orderCar
    This function is what the public will use when they want to purchase a car. It should take two parameters, specifying the desired color and the desired number of doors.

  • repairCar
    This function should take one parameter which is used to specify the particular car in question. The dealer will be responsible for seeing that the car is fixed. However, dealers are only willing to repair cars that were purchased at their dealership. A call to this function on any other car should leave it in a broken state.

  You may notice that we have been intentionally vague as to the precise signature of these two methods. It is up to you to decide upon the precise means to accomplish the desired goals. In fact this is the biggest challenge in the assignment.



• A Customer application.
  While there is no Customer class per se in the project, the main routine of the file Customer.cpp should serve as the primary application, demonstrating what is possible for the general public. The main routine should simulate a script with the following steps.
  
  
  1. Instantiate two Dealer objects for further interactions. Make sure to give each dealer a different name, for differentiation.
  
  
  2. Order a blue 4-door (the family car) from one of the dealers and a red 2-door (the convertible) from the other dealer. Output the description of each car to demonstrate that they have been properly created.
  
  
  3. Once you have your two cars, break the blue one. After doing so, again output a description of each car to demonstrate that one is broken and the other is not.
  
  
  4. Take the broken car to the wrong dealer to have it fixed (i.e., not the one from which it was purchased). After doing so, again output a description of each car. Presumably, the blue one is still broken.
  
  
  5. Have the proper dealer repair the broken car. After this is complete, again output a description of each car to demonstrate the progress.

Files we are providing

The files you need for this assignment can be downloaded here or copied directly on turing as
cp -R /Public/goldwasser/180/programs/carDealer/ .

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.

You should submit four files:

• Customer.cpp - The file which includes the main routine.

• Dealer.h - The revised definition of a Dealer class.

• Dealer.cpp - The revised implementation of Dealer functions.

• readme - In your own words, please explain what decisions led you to the final choice of signatures for the orderCar and repairCar functions. You may add any further comments you wish to make to the grader.

Notice that you need not submit the Car class files or the makefile, as they are presumed to be unchanged from those we originally provided.

Grading Standards