代写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
