Page146 - sniper won the bidding Test

reportsWonIfAuctionClosesWhenWinning()
The next test introduces the Won event.
Page148 - sniper wins test implementation

introduced a new method sniperWon in SniperStateDisplayer
Page150 - UI refactor replacing JTable

The Swing pattern for using a JTable is to associate it with a TableModel.
The table component queries the model for values to present, and the model
notiÎõÎées the table when those values change. In our application, the
relationships will look like Figure 15.1.  We call the new class
SnipersTableModel because we want it to support multiple Snipers. It will
accept updates from the Snipers and provide a representation of those
values to its JTable
Page152 - replacing JLabel done
Page155 - displaying Price details of item

 display information about the Sniper's position in the auction: item
 identifier, last auction price, last bid, status. These values come
 from updates from the auction and the state held within the application.
 We need to pass them through from their source to the table model and
 then render them in the display. Of course, we start with the test. Given
 that this feature should be part of the basic functionality of the
 application, not separate from what we already have, we update our
 existing acceptance tests starting with just one test so we

Following along the sequence of method calls, we dont have to change
AuctionMessageTranslator, so we start by looking at AuctionSniper and its
unit tests. AuctionSniper notifies changes in its state to neighbors
that implement the SniperListener interface which, as you might remember,
has four callback methods, one for each state of the Sniper. Now we also
need to pass in the current state of the Sniper when we notify a listener.
We could add the same set of argu- ments to each method, but that would be
duplication; so, we introduce a value type to carry the Sniper's state.
Page155 - sniperstate implementation

The one signiÎõÎécant change is that the Sniper needs access to the item
identifier so it can construct a SniperState. Given that the Sniper
doesnt need this value for any other reason, we could have kept it in
the SniperStateDisplayer and added it in when an event passes through, but
we think it's reasonable that the Sniper has access to this
information. We decide to pass the identiÎõÎéer into the AuctionSniper
constructor; it's available at the time, and we don't want to get it
from the Auction object which may have its own form of identiÎõÎéer for an
item. We have one other test that refers to the sniperBidding() method,
but only as an allowance. We use a matcher that says that, since
its only supporting the interesting part of the test, we dont care
about the contents of the state object