使用CRC的方式，设计一款售票系统。
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)?