代写Java基础作业，模拟一个Electric Train系统。
Learning objectives
By the end of this assignment, you will have
- worked with version control, making frequent commits to your git repository.
- read and worked with code that is not well designed.
- refactored the code to make it more readable and maintainable.
- added features to the refactored code.
- created useful Javadoc, other comments, and maintained or improved the visual style of the given code.
- created an inheritance diagram of the original code to see how your improved design changes the inheritance hierarchy.
Problem domain
For this assignment, you will work with a Java program that simulates an electric train set. The program draws the train track in a window and allows the user to control the direction of the trains by clicking on parts of the track.
The code was written twenty years ago and can be improved in many ways. Imagine that someone at your company found this code and it was decided that you would improve it so that it can be marketed as a new train set simulator. Throughout this assignment, your ultimate goal is to make the code easy to read by other people and easy to modify, in case you want to repurpose this code later.
Code Smells
Code smells [Wikipedia] are warning signs that there might be problems in your code. Take a look at the list of common code smells on that Wikipedia page. There are related Design smells [Wikipedia], which you should also read about.
Here is a blog post that discusses some of the more common smells.
Getting set up
Open IntelliJ on your home computer. Go to “File” –> “New” –> “Project From Version Control” –> “Git” (NOT Github).
Where userName is replaced by your MarkUs user name. The directory folder should be A2. Click clone and then next repeatedly until your project has been created. Inside the “A2” –> “a2” –> “src” folder there should be 31 java files.
Don’t change the code yet
Run the program. You should see a window containing a grid on which is a train track with clickable parts, samples of each type of track that are not connected to the main track, and a number of buttons on the right side of the window.
The Google Java Style Guide
Google has published a Java Style Guide. You will be using this style to format your code. To do this automatically, you can set up the CheckStyle plug-in.
Download intellij-java-google-style.xml from the GitHub google/styleguide project. You should be able to figure this out yourself — it’s part of being a software developer — but other people have written instructions on Installing the google styleguide settings in intellij and eclipse.
If you need help, search the course discussion boards, and ask if you can’t find an answer, you can ask in the Help Centre (BA 2230 Mondays-Thursdays at 4-6 PM), in office hours (to be announced by e-mail and portal) and during lab time.
Checkstyle
Checkstyle is a linter, which is a program that checks code for style errors. There is an IntelliJ Checkstyle plugin. To install it, go to “Preferences” –> “Plugins” –> “CheckStyle-IDEA”. Checkstyle knows about Google’s Java style. IntelliJ may already have the most current version. All you need to do is click Install.
What to do
You must do this assignment one step a time, pushing your changes whenever you finish a step.
Step 1: Create notes.txt
Create a file called notes.txt in the a2 directory of your repo. Copy and paste this into your file:
#########
# Step 1
Code affected: none
Created this file.
Add and commit it with this commit message: “Added notes.txt for keeping track of changes during a2.”. Copy and paste! Then push your changes.
Sanity check: Clone your repo again, somewhere else on your hard drive, and make sure that a2/notes.txt exists and has the expected contents. You can do this by running git clone url from the command line, where url is replaced by the url of your MarkUs repository (see above). If the file does not exist yet, keep trying until it does.
Step 2: Reformat the starter code
Open each .java file in turn and select Source->Format, or write click to Check Style, or use the keyboard shortcut. Save all the files as you go. Do not fix bugs, do not manually add spaces, and do not move anything around. Just use Google’s style formatter.
Run the program to make sure that it still works.
Make a note in notes.txt that you reformatted all the source code. Copy and paste this as your note:
#########
# Step 2
Code affected: all .java files
Reformatted using the Google Java style formatter.
Git add each .java file, and also notes.txt. Commit and push.
You can do a sanity check, if you want to, at this point. It is not mandatory, but we recommend it.
Notice that, so far, everyone’s repositories should have exactly the same changes in them.
Step 3: Draw an inheritance diagram
This can be done at the same time as Step 4.
Read through the code and draw an inheritance graph which includes all the classes defined in the program. If class B extends class A, then show an arrow pointing from B to A. If a class in the program explicitly inherits from a Java API class (e.g., Thread), then show this relationship as well in your diagram. To distinguish the Java API classes from the ones in our program, draw a rectangle around each Java API classname and an oval around each class name from our program. Note: this is not a UML diagram.
Step 4: Read through the code
Here are some questions you can ask yourself in order to better understand the code:
- How does one piece of Rail determine which other piece of Rail is “connected” to it?
- When building a Track, how do you “connect” one piece of Rail to another?
- What instance variable in which class determines the speed of a train?
- What is the relationship between the value of this variable and the speed of the train?
- What sequence of code is executed when someone clicks on the “Accelerate” button, causing the train(s) to speed up?
Steps 5 to N-2: Refactor the code and correct errors
Refactor the program to eliminate useless or repetitive code. Other flaws to avoid or eliminate: bad names, duplicate code, ugly code, nearly-duplicate classes, inappropriate print statements (when was the last time you ran an app that printed anything?), inappropriate use of static, chances to use inheritance, bad visibility modifiers, and recalculating a value over and over when it only needs to be done once are all candidates. You can refer back to the “Code Smell” links for more ideas. You will be marked on the quality of your fixes. By the end of this process, there should be no obvious design problems.
Every time you fix a flaw, add a feature, or create a new file, add a note to notes.txt that looks like the following where the value of x should increase by one each time:
#########
# Step x
Code affected:
Flaw:
Fix:
That is the format that every one of your notes should follow: the list of files that are affected, the flaw that you addressed, and a note about how you fixed it. The flaw and the fix should be concise: no more than a couple of sentences each. The TAs will be using these notes as the primary guide to marking your assignment, so be clear in your communication. Bad grammar and spelling, unclear descriptions, and excessive verbosity will all receive marks deductions.
Add notes.txt and any affected files, commit (with a clear commit message), and push. This can be done by right clicking on the file.
Continue identifying flaws (code smells) and fix one per push. After each fix, make a clear note in notes.txt, then add, commit (with a clear commit message), and push your changes.
Run Checkstyle after each fix, and address Checkstyle flaws that are directly associated with the code that you just fixed. By the end of these steps, you should have resolved all the Checkstyle warnings. You will lose marks if there are any Checkstyle warnings left after your final push.
Here is one feature you can fix. Currently, trains pass through each other instead of crashing. To fix this, design and implement a way for the trains to stop moving if they run into each other.
Step N-1: finish the comments and Javadoc
It is possible that you added comments and Javadoc while you read through and corrected the code. However, now is the time to go back and make sure that there are enough comments to fully describe each class, that no comment describes easily-read code (forcing the reader to read the same thing twice), and to make sure that the comments match the code (and not a previous version of the code).
Include “finalize Javadoc” in notes.txt, and add, commit, and push your changes. If you wrote significant amounts of Javadoc and/or comments in an earlier step, say which one.
Step N: Add at least six new grid squares of rail to the track
Now that your code is beautiful, design and add at least six new grid squares of rail to the track. Your extra track should connect to the existing track so that trains travel over it and back to the original track without derailing. You can move the original track to accommodate the new pieces of rail so that there are no breaks in the track. There are many possibilities, and we’re running MOSS to detect similarities, so please do not copy from each other. Whatever track configuration you choose, write the code yourself.
Make a final note in notes.txt describing the new configuration of your track. There is no a flaw, so just describe your change in a concise paragraph or bullet-point form after the # Step N note header.
In Summary
You are to work on the following:
- understanding the code, making an inheritance diagram and answering the given questions
- properly formatting the code
- redesigning the class structure and fixing internal flaws within the classes, code smells, etc.
- ensuring correct and sufficient internal comments and Javadoc comments
- changing the configuration of the rails (train tracks) to accommodate the addition of at least six new grid squares of rail
- recording each activity in the notes.txt file