improve some codes

You have been provided with a Java program of a text-based version of the Battleships game. It works, but there are a number of ways in which it could be improved. Your job is to write a critique of it and to suggest improvements. Aim The aim of this coursework is test the following: ability to read and understand Java code ability to understand the implications of object-oriented theory on software and the development of software. ability to read apply object-oriented theory to suggest improvements to Java code Your marks will reflect this. Your task The UML diagram for the project you should critique is above. You can download the BlueJ project from the coursework section of the Moodle page. The [login to view URL] file tells you that the BattleShips class contains the main() method. You need to write a 3-page critique of the code covering the following five issues. Object-oriented design: Are the classes well designed and do they follow good object-oriented principles? How well are errors dealt with?: How robust is the program (does it crash)? User interface.: As text-based interfaces go, how good and intuitive is it? Note: text-based interfaces aren't necessarily bad!. Clarity of code: How easy is it to follow how the program works? Flexibility and extensibility: How easy it it to change aspects of the gameplay? How easy is it to extend? Each of the above should be under its own heading. You should mention all five issues, but focus of those that you think are are more important to write about. For each: Good and bad: Mention both good and bad points (unless you can't find any), giving specific examples. Reasons and implications: As well as the reasons, give examples of what the implications are. Suggested improvements: Suggest improvements and the benefit of the improvements. Some examples follow. Note that these don't apply to the code you have! Make sure you put them the under the appropriate headings. Where appropriate, you should have snippets of code in your document, but in some cases a simple description may suffice. Good: The Student class implements the Comparable interface and implements its compareTo() method. This enables uses encapsulation in that the object is able to sort itself by surname whenever any of Java's collection need to determine its order. However, it could be improved my sorting on the first name where surnames are identical. Bad: The numerical object variables in Student are stored as Strings. It would be more appropriate to store these as float. This would take up less memory and would make it easier to do statistics based on these values. Bad: The toString() method has not been overridden, so relevant fields need to be extracted everytime it's printed to screen (e.g. line 34 in GradeMark). Overriding Objectss toString() method is the standard way of dealing with this, e.g. public void String toString(){ return this.firstName+" "+[login to view URL]; } Bad: Javadoc comments are missing in the Car class. For example, it's not clear what the setData() methods is (as it has quite a generic name) and difficult to know how to use it. It should perhaps be renamed to setEmissionsData0510(). The Javadoc would be something like: /**Method that set emissions data for the car * @param data Data in an array for the period 2005 to 2010. */ Bad: The menu does not tell you what the options are! It should print out all the options everytime the menu is offered. Marking You'll be marked on: Good and bad: Whether the important the issues are raised and whether good examples are given. Reasons and implications: Good reasoning as to why the issue is important, in terms of implications for both gameplay and development. Suggested improvements: Whether the improvements suggested are detailed enough to assess and are likely to benefit the gameplay or future development of the code.