CO882 Assignment 2 Introduction This assignment is designed to assess your understanding of the material covered in chapters 10 and 11 of the course text book: inheritance in objectoriented languages. In particular, you will be exploring how shared characteristics of related classes can be represented in a superclass, with the specialised elements of the related classes represented in multiple descendent subclasses. The assignment will be marked out of 100 and provisional marks have been associated with the individual components. . Date set: 7 December 2016 Date due: 23:55 16 Janary 2017. Provisional weighting: 25% of the coursework mark. The task has been broken down into three elements, with provisional assignments of marks to the elements. Two of the elements are designed to be reasonably straightforward, while the third is designed to be challenging. The Task You will work with an existing project that does not currently use inheritance, https://moodle.kent.ac.uk/2016/pluginfile.php/3958/course/section/43991/assi gn2.zip. The scenario is a that a program is under development for a taxi company. Part way through the implementation, the old programmer has to abandon development and you are taken on to finish the job. Looking at the code you realise that it is basically ok, but improvements could be made through the use of inheritance. The basic operation of the program is that a TaxiCo object is created, and a name supplied for the company. A fleet of taxis and shuttles is created by calling the addTaxi and addShuttle methods of TaxiCo. A sample company, with two taxis and one shuttle, can be placed on the object bench by right clicking over the Helper class and selecting Test Fixture to Object Bench. Do that and then call its showStatus method to print a list of the statuses of the three vehicles. Taxis and Shuttles A taxi has an identity (ID), a location (initially the company's base) and an optional destination. If the taxi is free (not booked) then it has no destination (is it null). If it has been booked then it has a destination. If the arrived method is called on a taxi then this causes it to change its state so that its location becomes what was its destination, and the taxi becomes free again. Shuttles are different from taxis in that they move between a fixed set of destinations on a circular route that includes the company's base. Each time a shuttle's arrived method is called, its location becomes what was its destination and its destination changes to the next place in its route list. Each shuttle has an ID. There are clearly some similarities in the implementations of Taxi and Shuttle that suggest use of inheritance to represent them. Introducing inheritance is the primary task of this assessment. The TaxiCo class The TaxiCo class maintains separate lists of taxis and shuttles. It has a lookup method that searches for a taxi with a given ID. The original programmer left before a similar method could be written for shuttles. You will probably realise that this would have introduced code duplication into the TaxiCo class. Introducing inheritance into the project (35 marks) The Taxi and Shuttle classes share some common attributes – id, location and destination. They also have some common methods – getID, getLocation, getDestination, getStatus and setDestination. Capture as many of these common elements as you feel are appropriate in a new class, Vehicle, that becomes the superclass of both Taxi and Vehicle. This change involves placing the common fields and methods into Vehicle and removing them from Taxi and Shuttle. Rather than making the changes all in one go, it will be safer to move one field at a time, perhaps as described below, but this is only a suggestion. Each time you make a significant change to your code, check that it recompiles and behaves as you would expect. You can use the existing Helper class with this, and add further tests to it to increase the robustness of your implementation. Moving the id field In order to move the id field you will need to engage in a process called refactoring. The aim is to improve the class structures by revising the existing code. This will involve moving some code around, removing other bits, and making small changes to some. However, we are not aiming in the main to introduce new functionality by this process. Start by creating a new class called Vehicle. Modify Taxi to indicate that it is a subclass of Vehicle. Move the id field to Vehicle by removing it from Taxi. You can do this with cutand-paste quite easily. As this field will also eventually be inherited by the refactored Shuttle class, make sure that the field has an appropriate comment once it has been moved. Arrange for Taxi's constructor to call the constructor of Vehicle so that a value for id is passed from one to the other. Move the getID accessor method from Taxi to Vehicle. Make sure the text of the method comment is appropriate to a shared method. With id now a private field of Vehicle, subclasses cannot use the field directly in their methods. Taxi must replace direct accesses with calls to the public getID method it inherits from Vehicle. Make these changes to Taxi and check that all classes compile correctly. Use the Helper class to help you check the results of your changes. Once you have successfully moved the id field to Vehicle, you can make use of this in the Shuttle class. Make Shuttle a subclass of Vehicle and remove all the elements it no longer requires because it inherits them from Vehicle. You will have to make a very similar set of changes to those you have just made to Taxi. Moving the destination field When you have successfully moved the id field to the Vehicle class you can move the destination field. The process will be similar and you should probably work on Taxi and Shuttle at the same time. Start in a similar way as with id - move the destination field along with its accessor and mutator to Vehicle. Replace accesses to these fields with accessor and mutator calls from the subclasses. Ensure that everything compiles and works as you would expect. Enhance the Helper class with fresh test methods to support this regression testing. Moving the location field Using the experience you have gained above, move the location field to Vehicle. Check by using the Helper class that everything still works as it did originally. Add further tests to the Helper class to increase your confidence that things are working properly. Introducing polymorphism (25 marks) The TaxiCo maintains separate lists of taxis and shuttles. Replace these two lists with a single list of Vehicles. Note that one consequence of this will be that the lookup method will now return a Vehicle rather than a Taxi. Another change will be that the showStatus method will require only one for-each loop rather than two. Improved status information (10 marks) The original getStatus method of the Taxi class printed null if a taxi was free. If your version in Vehicle does the same, have it test to see whether destination is null or not, and print something more meaningful if it is. Challenge component (30 marks) A new method is required in the TaxiCo class. The idea is that a customer has phoned the taxi company and wants to catch either a shuttle or a taxi to a particular destination. The destination is passed as a parameter to the method. This method must return a Vehicle which is: Either: a shuttle whose next stop (i.e., destination) is where the customer wants to go. Or: a taxi that is free (i.e., has a null destination). If no suitable shuttle is available, and no taxi is free, then this method should return null. A customer will always prefer a suitable shuttle because they are cheaper so if there is a suitable shuttle then that must be returned. Note that there is a bit of a catch here. It is important to be able to distinguish between a shuttle whose next destination is the one required, and a taxi that is already booked to go there. A booked taxi is no good to the customer, even though it is going where they want to go. In order to be able to work out whether a given Vehicle is a Taxi or a Shuttle you will need to use Java's instanceof operator. (This is covered in chapter 10 of the course text, or you can read about it on the Web.) In addition, we can use a cast to recover the subtype and access the full functionality of the object. The following example shows how these features are used in a hierarchy where Cat and Dog are subclasses of Animal: public void identify(Animal whatAmI) { if(whatAmI instanceof Dog) { System.out.println("You are a dog."); // Use a cast to access its Dog characteristics. Dog fido = (Dog) whatAmI; fido.bark(); } else if(whatAmI instanceof Cat) { System.out.println("You are a cat."); // Use a cast to access its Cat characteristics. Cat tiger = (Cat) whatAmI; spot.miaow(); } else { System.out.println("I don't know what you are."); } } Test your code thoroughly to ensure that a customer's requirements are met in all possible cases. What to submit You will submit a Java JAR file of your project via a Moodle hand-in area to be provided shortly. Plagiarism and Duplication of Material The work you submit must be your own. We will run checks on all submitted work in an effort to identify possible plagiarism, and take disciplinary action against anyone found to have committed plagiarism. Some guidelines on avoiding plagiarism: • One of the most common reasons for programming plagiarism is leaving work until the last minute. Avoid this by making sure that you know what you have to do (that is not necessarily the same as how to do it) as soon as an assessment is set. Then decide what you will need to do in order to complete the assignment. This will typically involve doing some background reading and programming practice. If in doubt about what is required, ask a member of the course team. • Another common reason is working too closely with one or more other students on the course. Do not program together with someone else, by which I mean do not work together at a single PC, or side by side, typing in more or less the same code. By all means discuss parts of an assignment, but do not thereby end up submitting the same code. • It is not acceptable to submit code that differs only in the comments and variable names, for instance. It is very easy for us to detect when this has been done and we will check for it. • Never let someone else have a copy of your code, no matter how desperate they are. Always advise someone in this position to seek help from their class supervisor or lecturer. Otherwise they will never properly learn for themselves. • It is not acceptable to post assignments on sites such as Freelancer and we treat such actions as evidence of attempted plagiarism, regardless of whether or not work is payed for. Further advice on plagiarism and collaboration is also available. You are reminded of the rules about plagiarism that can be found in the course Handbook. These rules apply to programming assignments. We reserve the right to apply checks to programs submitted for assignment in order to guard against plagiarism and to use programs submitted to test and refine our plagiarism detection methods both during the course and in the future. Meng Wang 6 December 2016.