Lab 3: Inheritance and Interfaces

This lab consists of three parts. The first two parts are compulsory, while the last part is optional (and will not be graded).

1. Implementing an Interface

   Write a class, Employee, that implements the Salaried interface:

   interface Salaried {
     void setSalary(BigDecimal salary);
     void giveRaise(float raise);
     BigDecimal getSalary();
   }
   

   As far as semantics (behavior) of these methods, your implementation should do the following:

   setSalary

   Set the salary of this object to the value of the salary argument to the method.

   giveRaise

   Modify the salary by the fraction given by the raise argument to the method. For example, when giveRaise(.1f) is called on an object whose salary is $50,000, that object's salary should be modified to be $55,000 (i.e., a 10% raise).

   getSalary

   Returns the object's salary.

   For your convenience, the test program TestEmployeeSimple.java is provided. Your Employee class should compile with this test program. Note that this test program is not very complete with respect to the behavior of the methods. The grading of the lab will be carried out with a more thorough test program.

2. University Records System

   Narrative Description

   Design and implement the classes needed to accomplish two basic tasks related to university personnel: (i) associate a student with an advisor and (ii) assign a seat category for football games.

   You should implement the following five classes: Person, Employee, Student, Faculty, Staff. These classes should be related by inheritance such that every class inherits, either directly or indirectly, from Person. Apart from this constraint, the rest of the structure of your class hierarchy is up to you.

   Seat categories come in six varieties: AA, A, B, C, D, and NONE. These categories are represented by the (provided) enumerated type StadiumDeck.

   The public interface for these classes is summarized below.

   Common Elements

   The following aspects of state and behavior are common to all five classes (Person, Employee, Student, Faculty, and Staff).

   • These classes each provide a single constructor. Each class's constructor is a 1-argument constructor taking a String argument.
   • Every object has an int ID greater than or equal to 1 and unique among all objects. That is, if a faculty member has ID 10, no other faculty members or students or anyone else has ID 10. This ID can not be changed after object construction. An object's ID is returned by the getID() method. The client that creates an object can not request a particular ID value: The unique ID is chosen by the object being constructed (or that object's class), not the client.
   • Every object has a (String) name. As with ID, a name can not be changed after object construction. Unlike IDs, the name is set by the client constructing the object (i.e., the String argument to the constructor is the name), and names are not necessarily unique. An object's name is returned by the getName() method.
   • Every object can be assigned a seat category for football games. This is done by calling the ticketLottery() method on the object. The result of the lottery can be observed by then calling the getSeat() method on the object. A different allocation algorithm for each class should be used to assign seats for objects of that class. For example, a generic Person object may have relatively low priority and receive a StadiumDeck.NONE seat often (or always?). Students, on the other hand, may be given relatively high priority and receive seats in the best deck often (or always?). Any allocation algorithm you choose is acceptable, as long as it reflects a difference in relative priority between the different classes. You may assume that there is an unlimited number of seats in each deck.

   To summarize, each class must provide methods with the following signatures:

   public Person (String name) //renamed, as appropriate, for each class
   public String toString()
   public int getID()
   public String getName()
   public void ticketLottery()
   public StadiumDeck getSeat()
   

   Salaried Personnel

   In addition to the state and behavior described in the "Common Elements" section above, Employee, Faculty, and Staff are all salaried objects in the sense of part 1 of this lab. You can use your Employee class from part 1 of this lab as a basis for implementing these classes.

   Student

   In addition to the state and behavior described in the "Common Elements" section above, a student has an advisor. The ID of student's current advisor can be seen by calling getAdvisorID().

   An advisor is associated with a student as a result of the chooseAdvisor() method. This method is overloaded. The first version of this method takes an array of Faculty and assigns one of the Faculty from the array to be the student's advisor. The algorithm for making this selection is up to you. The second version of this method takes an array of Faculty and a String. If a Faculty object in the array has a name matching the String argument, that Faculty object is assigned to be the student's advisor. If there are no name matches or multiple matches, the behavior of this method is up to you.

   To summarize, the Student class (in addition to the "Common Elements") also provides methods with the following signatures:

   public int getAdvisorID()
   public void chooseAdvisor(Faculty[] profs)
   public void chooseAdvisor(Faculty[] profs, String profName)
   

   Faculty

   In addition to the state and behavior described in the "Common Elements" and "Salaried Personnel" sections above, a faculty member has an array of students whom they advise. This array is set by calling findAdvisees() and passing in an array of Students. The Faculty object then checks whether, for each Student in the array, it is the advisor of record, and modifies its own array of advisees accordingly.

   To summarize, the Faculty class (in addition to the "Common Elements" and in addition to being salaried) also provides methods with the following signatures:

   public void findAdvisees(Student[] students)
   public int getAdviseeCount()
   public int[] getAdvisees()
   

   Checking Method Signatures

   To help you check that you have implemented all the required method signatures, a small test program is provided here. Your implementations of the classes described above should compile with this test program. Note: this test program is not a very thorough test of the functionality of your solution. Grading will be carried out with a more exhaustive test program.

3. Optional Extras

   Note: This part of the lab is optional. It will not be graded, so you do not have to complete it in order to get full credit for the lab.

   Ordering BigNaturals

   Modify your BigNatural class from Lab 2 to implement the java.lang.Comparable interface. See the Java API documentation for a description of the requirements (both syntactic and semantic) that this imposes on your modified class.

   If you did not complete Lab 2, you may use the BigNatural implementation provided here. (Note: This version of BigNatural is not an acceptable solution for Lab 2 since it uses BigInteger. It is acceptable to use in this lab, however.)

   Behavioral Subtyping

   Write a precise specification of the (client-view of) behavior of Person's ticketLottery() method. You can use a RESOLVE-style formal comment or some other unambiguous formal or semiformal notation. Now write a similar specification for Student's ticketLottery() method.

   Is your Student class a behavioral subtype of the Person class? If so, give a brief argument why. If not, give an example of client code that uses a Person object and that is correct when given a Person object at run time, but not correct when given a Student object.