Session 13
Planning for the Nim Project
810:062
Computer Science II
Object-Oriented Programming
On Homework 4
Two items:
- If an object has a toString() method, then
System.out knows how to print it. You don't
need to ask for the string before printing. So, for
example, this will do:
Association assoc = (Association) collection.elementAt( i );
System.out.println( assoc );
- Determining whether one Association is less than
another can be done by any method that has access to their
keys and values. But then those objects have to know about
the implemetation of the Association class. What
if that implementation changes? (Think about how we
changed the implementation BowlingGame...)
The alternative is to tell Associations how
to determine whether it is less than another. This way,
only the Association class has to know about the
implementation of the class. If we ever change the class,
the change will affect no other code!
Here is a rule of thumb you can use when deciding
where to put a behavior:
Any code that manipulates an object's instance variables
should be in the object's own class.
And don't forget that the
homework submission requirements
require your hard copy to be stapled in a particular order!
Exercise: Planning for Homework 5
Pair up with another member of the class. Compare your solutions to
Task 1
of Homework 5.
- Are your stories at the same level of detail? If not,
then break the larger stories into smaller parts.
- Does one of your lists have stories that the other does not?
If yes, then add the extra stories to the other list.
Together, construct a single list of stories that combines the
stories of your two lists. Put your stories in the order you
would want to implement them one at a time.
Debrief the Exercise: An Ordered List of Stories
[ As a class, we discuss the stories and the order... ]
[ ... run demo ... ]
Do you see any stories you missed in the demo we ran?
Review for the Exam
Some ideas I noticed in reviewing the course notes so far:
- three-step process for implementing a new feature
- writing tests and code
- the roles played by our tests as we design and code
- JUnit and various assertions
- Linux commands and operators (e.g., >)
- the Principle of Continuity
- test coverage: "ordinary" and boundary cases, positive and negative
- interface method
- compound tests
- how to test a printing behavior
- Java text processing tools, and standard processing loops
- using stdin, stdout in Java
- different object + same code = different behavior
- computing anagrams by piping standard Unix commands with Java programs
- the big idea Unix is similar to the big idea of object-oriented
programming
- lots of code: BowlingGame, the Echo variations, Squish, Sign,
four homework assignments -- and all their associated tests
Some pragmatic ideas for taking the exam:
- Time is limited.
- When I ask for a short answer, I mean a short answer.
Writing a page about a problem whose answer can be
expressed in one or two sentences will leave you
short of time at the end.
- Budget your time per problem. When your time is up
for a problem, stop (in mid-sentence?).
- Writing code takes more time than writing short answers.
- Don't rewrite code. If you are asked to add code to
a class or to modify a method, you only have to write
the new or changed code. Just be sure to tell me where
it belongs.
- Your proctors are not equipped to answer questions about the
content of a question. If you have a question about
what something means, write your assumption as a part of your
answer.
I will check my mail before I leave tomorrow morning and then again
as early as I can on Thursday. Feel free to send me any questions
you have before the exam.
Wrap Up
- Reading -- Prepare for our midterm exam.
- Programming --
Homework 5
is available and due one week after the exam.
- Midterm Exam -- Our first midterm exam is one week from today.
Eugene Wallingford .....
wallingf@cs.uni.edu .....
February 22, 2005