Java Reference
In-Depth Information
some of the alternatives such as “Head First Design Patterns” by Elisabeth Freeman, Eric
Freeman, Bert Bates, and Kathy Sierra (O'Reilly, 2004), the Portland Pattern Repository at
http://c2.com/ppr/index.html , or the Wikipedia entries for design patterns starting at
http://en.wikipedia.org/wiki/Design_pattern_(computer_science) . Sun's J2EE design pat-
terns at http://java.sun.com/blueprints/patterns/ are also very useful, but you should be
aware that they are J2EE-centric, and may describe patterns in a form that may not seem to
make sense for this assignment.
Documenting Design Decisions
Document the choices that you make during the development process. Write down the vari-
ous decisions you make and the reasons you make them. For example, if you decide to use an
ArrayList instead of a Vector for an internal data structure, document the fact the ArrayList s
are not synchronized and thus were chosen because they are a more lightweight data struc-
ture. There is no need to go overboard with this type of documentation, so be mindful to use
common sense. This sort of documentation is a crucial tool in debugging and performance
tuning, and it also serves as an excellent source for anyone who needs to understand the code.
Whatever you do, don't leave documenting your design decisions until the end of the
project. If you wait until after you have completed coding before beginning this document,
not only will you have to remember why you chose a particular option, but you will also have
to remember that you had other options in the first place! For example, if you decided at the
start of the assignment that you were going to use a custom dialog box, at the end of the
assignment you might have forgotten that you had originally also considered having an
editable cell on the main window.
It is quite possible that by the time you get to the end of the assignment, you may find
that your design decisions document is huge—minor decisions can be removed to reduce the
size of the document.
Tip You might want to use bullet points to describe your design decisions. Not only will this reduce the
amount you write, but also they are easier to remember when it comes time for the exam. This is especially
useful for candidates for whom English is not their first language—you will not have to be so concerned
about how good your spelling is or how well you have formed your sentences.
For instance, we might document a few decisions like so:
Sockets used instead of RMI—allows complete control over threads
RandomAccessFile used instead of separate DataInputStream and DataOutputStream
classes—allows for random access to the file
Testing
You should begin testing by writing a unit test client for each class, or you can use a testing
tool such as JUnit ( http://www.junit.org/ ) to automatically generate test clients. When you
design a custom test, it is best to write the test class before implementing the methods to be
Search WWH ::




Custom Search