使用 [ CRC ](https://en.wikipedia.org/wiki/Class-responsibility-
collaboration_card “CRC”) 的方式,设计一款售票系统。
![CRC](https://upload.wikimedia.org/wikipedia/commons/thumb/c/c6/Brainstorming_Customer_Needs_%282%29.jpg/230px-
Brainstorming_Customer_Needs_%282%29.jpg)
Specification
Create a program that keeps track of ticket sales for an auditorium that has
32 rows of seats with a varied number of seats in each row. Each ticket is
associated with a seat (row letter and seat number such as A12), a price (low
$10, medium $30, or high $50), whether or not the seat is for sale or
complementary (for example, sold to the public or given to friends of a
performer), name of occupant (who bought the ticket), their e-mail address,
and the date, time, and name of the performance so that tickets for each seat
can be sold to different people at different times.
It should be possible to get a list of names of all people who bought tickets
for a particular date. For a given performance, it should also be possible to
print a grid of x’s and o’s where an x represents a seat that is occupied
(that is, it’s associated ticket has been sold) and an o represents seats for
which no ticket has yet been sold.
Anyone who buys a high-priced ticket automatically joins the Gold Members Club
which is an e-mail list. It should be possible to generate an e-mail list of
all people in the Gold Members Club, and to delete someone from that e-mail
list upon request.
A ticket holder should be able to create and access an account that stores the
seats, dates, and names of performances attached to all of the tickets which
they have purchased.
Classes
This is where major design decisions are made. Can we store all of the
information in the UserAccounts?
No, because we do not want to accidentally sell the same seat to the same show
to two different people. So information about each show should be stored
separately from the user accounts.
Could we have a ShowManager which keeps instances of class Show in which we
store in- formation associated with each seat and ticket?
Alternatively, could we let seats be entries in a collection or multi-
dimensional array that exists within the Show class, generating tickets for
each by accessing a TicketManager?
There are many good designs that can fulfill this specification. When creating
CRC cards, you need to choose one design, work with it, and adjust it as
problems arise.
Responsibilities
More than one class needs access to the seat number and row number of a given
ticket. Where should we store that information?
For the purposes of this handout, we decide to have a Ticket class. But where
do we instantiate Ticket? In the TicketManager and pass it to the UserAccount,
or should we instantiate the ticket class in the UserAccount and pass that
information to the Show and its associated TicketManager?
Likewise, should we store the e-mail list in the TicketVendorSystem, or create
a method that generates that list whenever we need it? If the latter, how do
we store the information about whether or not a user is on that list?
Collaborations
Collaborators can be classes that are adjacent on the inheritance hierarchy
(that is, one is the parent of the other), or instantiate one inside the
other, or one gets passed as an argument into a method in the other.
Collaboration is symmetric. So, if class A collaborates with class B, then
class B collaborates with class A. For example, the TicketManager will
collaborate with Ticket objects (through instantiation), so the TicketManager
collaborates with class Ticket (through creating and storing instances of
Ticket).
On the next page is one possible set of CRC cards that describes one piece of
software that fulfills the given specification. Class names are at the top of
each card. The responsibilities (variables and methods) of that class are
written on the left, while collaborating classes are listed on the right.
Warm-Up Questions
- According to the CRC cards, where is the user’s name stored?
- How does the system generate a list of users names for a given show?
- How does the system generate the map of seats with x’s and o’s showing which seats are available? Can you think of another way to accomplish this?
Questions About The Current Design
- In which class does execution start?
- Where does class Show get instantiated?
- Where are instances of class Ticket stored?
- How does a UserAccount get information about available seats for a particular show?
- How does a user buy a ticket (represented by a Ticket)?
- Once a Ticket is generated, where does it go? How many classes have direct or in- direct access to the information contained in that Ticket?
- Should UserAccount collaborate with class Show? Why or why not?
Questions About Changing the Design:
- Do we need a separate class for Show or can we reorganize the ShowManager so we no longer need instances of Show? If so, should we?
- How can we change the design so that the same TicketVendorSystem sells tickets to multiple venues (different rooms with different numbers of rows and columns of seats)?