Hi Jake,
This program doesn't do anything useful, so I understand why you don't see a reason for what's going on. What's happening with the setTime() method is that some other code can create a Clock, call setTime() to tell it what time it is, and then that Clock remembers that time value, forever.
Besides the fact that there's no immediate use for this, there's also the glaring problem that clocks don't, in fact, remember one time value forever; they have a constantly-changing time value.Let's set that aside, however. Imagine that this class represents a broken clock, the kind that's only right twice a day. You can set it, but then it doesn't change.
So (trivial example, but hopefully it makes a little more sense) imagine that Clock has a method called displayTime(). It might look like this:
Now I can create any number of broken clocks, each stuck at a different time, and ask each one to describe its own unique perspective:
Imagine (if your imagination isn't already overworked!) that this class is part of a text adventure computer game. Every time you look at a clock, you want it to display its little message. There are several broken clocks in the game, and each broken clock remembers the time you set it to. Woooo.
Now, how do we make this useful? Imagine a Report class, with setTitle(), setNumColumns(), setData(), setLogo()... then you build a Report, and then call Report.preview(). It if looks good, you call report.print().
This general idea, with objects that remember their own state, is extremely important in
Java.
