Is it my instructor's interface that's the problem?

Aaron Perzan :

I have an assignment to make an implementation of an interface called "CarInterface". My class will be called "Car", and it is tested in another class called "CarTester".

I am having a small problem with one of the methods in the interface, however.

This method is called "equals", and it accepts a CarInterface parameter. In the CarTester main, it seems that he wants this method to check if the make, model, color, and year data are the same (only these attributes). Despite that, CarInterface does not have any methods for getting that information! Now I am at a standstill and contemplating if his interface is the problem or not.

I first thought it would be alright to cast the CarInterface parameter as Object, and then pass it on to this.equals(...). That's when I realized something was wrong here.

(Here is a snippet from the interface code) (The interface doesn't even have a method for getting the VIN)

/**
     * Checks to see if the calling Car and the argument Car have the same state except for the VIN
     * Precondition: Both the calling Car and argument Car are fully initialized
     * Postcondition: no change
     * @param pCarObject
     * @return
     * returns true if the calling Car and the argument Car have the same state except for the VIN, else returns false
     */
    public boolean equals(CarInterface pCarObject);

Here is the full interface code:

package interfacePackage;
public interface CarInterface 
{
    /**
     * This module changes the color of the car to the color of the argument.
     * Precondition: a state variable that holds the color of the Car
     * Postcondition: The value of the color of the car is now set to the value contained in the parameter.
     * @param pColor
     */
    public void paint(String pColor);

    /**
     * Fills the car fuel tank
     * Precondition: Car has a fuel tank
     * Postcondition: Car's fuel tank is full
     * @return
     * Amount of fuel used to fill tank
     */
    public double fillTank();

    /**
     * Adds fuel to the car's fuel tank
     * Precondition: Car has a fuel tank
     * Postcondition: Car's fuel tank may have added fuel
     * @return
     * Negative number indicating the amount of fuel the tank will still take
     * Positive value of the amount of argument fuel not used, if 0 it just filled the tank
     */
    public double fillTank(double pFuel);

    /**
     * Converts the Car object's state variables to a String representation
     * Precondition: All state variables are initialized
     * Postcondition: no change
     * @return
     * year, make, model, color, VIN
     */
    public String toString();

    /**
     * Checks to see if the calling Car and the argument Car have the same state except for the VIN
     * Precondition: Both the calling Car and argument Car are fully initialized
     * Postcondition: no change
     * @param pCarObject
     * @return
     * returns true if the calling Car and the argument Car have the same state except for the VIN, else returns false
     */
    public boolean equals(CarInterface pCarObject);

    /**
     * drives the Car predefined distance and speed.
     * Precondition: Car's trip state variables have been initialized
     * Postcondition: Car's fuel is reduced proportional to the distance and speed driven or depleted if the distance and speed are too great. odometer and trip odometer are updated with the miles traveled added.
     * @return
     * true if the car travels the distance with fuel remaining, false if the car runs out of fuel
     */
    public boolean driveCar();

    /**
     * gets trip odometer
     * Precondition: none
     * Postcondition: no change of state
     * @return
     * double value of trip odometer to nearest tenth of mile
     */
    public double getTripOdometer();

    /**
     * sets trip odometer mileage to 0.0
     * Precondition: none
     * Postcondition: trip odometer set to 0.0
     */
    public void clearTripOdometer();

    /**
     * gets odometer mileage
     * Precondition: none
     * Postcondition: no change to state
     * @return
     * double value of odometer to nearest tenth of mile
     */
    public double getOdometer();

    /**
     * retrieves fuel level in gallons
     * Precondition: fuel level is initialized
     * Postcondition: no change is state
     * @return
     * fuel level in gallons with decimal values
     */
    public double getFuelLevel();

    /**
     * Car's state is set to hold the speed of travel and distance to travel at that speed
     * Precondition: none
     * Postcondition: Car's state holds information on distance to travel and speed to travel
     * @param pAverageSpeed
     * @param pDrivingDistance
     */
    public void setUpTrip(double pAverageSpeed, double pDrivingDistance);



}

Bakna :

From what I can tell, it looks like the equals(CarInterface pCarObject) method is supposed to work off of unpacking pCarObject's information present in toString() from the interface, drop the VIN, and compare with the information from that. It's a nasty way to do it, but it works I guess.

Building upon what @racraman said, something like this will never fly in a professional context (at least, should never fly). A toString() is exclusively for making a human-readable output, and is not intended for transmitting data internally. Even a painful getDetails() method that returns everything in a cryptic array is more acceptable than using a toString().

The ideal way to handle this is to use getters and setters so you only spend time getting exactly what you need, no more, and no less. This is especially useful if a getter needs to do some amount of work to transform the value(s) into the output, so you don't waste time transforming an output that just gets dropped.