Site Map  Search

OOA Home OOD content UML Corrections book Code object Exercise Solutions oriented Resources tutorial Miscellany textbook

Exercise Solutions (Unrestricted)

Chapters 1 2 3 4 5 6 7 8 9 11 12

Chapter 11


Question 11.4
In the early stages of the CRC session described in the case study, Booking was considered for the placeBooking responsibility. Write down at least two good reasons why you might turn down the responsibility if you were playing Booking.

  • One is in the text -- which booking am I? We can't be messaging the new booking to make itself. Taken to extremes, this is sometimes known as the "magic constructor". "Let's just instantiate a valid booking in the right place if these 'ere objects are so all-fired wonderful." One ends up with all the logic in a constructor; constructors aren't run by objects against their own state, so we wouldn't be being object-oriented and such a constructor would be huge, complicated and unmaintainable -- no progress. And we can't be messaging another booking instance to place the new booking instance. How would this other booking instance be chosen? What singles it out? Another way of looking at this objection would be instantiation -- I might not exist yet.
  • Another reason for refusal would be that too much knowledge of restauranting would be required on the part of the message sender -- a view (GUI) object at this juncture. If the interface/view/GUI object were to message a creature as simple as a booking (or a table) then surely there would be lots of work left for the interface/view/GUI object to do; and, inevitably, being able to carry out that work would place a lot of restauranting logic in the interface/view/GUI. Imagine porting the application from one GUI to another, and picture the large quantity of logic would be "left behind".
  • One could also invoke the "can’t see me" reason. There are a strictly limited number of mechanisms by which one object is able to get a message to another. The typical six mechanisms are listed in the text. None would be reasonable here. The booking definitely shouldn't be global; there's no way that the GUI could have received an appropriate booking as argument or as return; and it's quite unreasonable for some GUI object to hold an instance variable (data member) expressly for being able to message some particular booking.


Question 11.6
The Booking object type was described in terms of its message-accepting interface toward the end of the case study section. Present it as a UML classifier symbol (a multibox).

[Note that these are types, so visibility marks and other implementation details are inappropriate. It's a good idea to give formal names for the parameters. The text left undecided details of the "suitability" enumeration; I've filled in some example detail. JD]

Question 11.7
Checking the requirements, as one must from time to time, you realize that you have overlooked floating bookings. If a member of the restaurant staff is convinced that they can take a booking because they are sure at least one table will finish in time, the system should accept the booking to the restaurant or to a zone rather than to a particular table. The final table allocation will take place on the night. For safety, you learn, there is a policy maximum on the maximum number of floating bookings that can be taken.

What do you think is the impact on the emerging design: a few simple changes in some obvious places, or a major reworking of the design? Have our efforts given us a flexible design after all?

Bookings are currently accepted by dairies that belong to tables. In the process of being accepted they seem to successfully participate in finding destinations that are suitable for them. I see no extra, impossibly difficult questions that a floater needs to be asked. And I can easily picture a dialog ensuing when no table has been able to accept the booking, wherein a restaurant is asked, or a room (also known as "area" or "zone") is asked, if it can accept the booking. Restaurant and room objects could quite reasonably have knowledge as to policy and limits, or knowledge of the objects that do have such knowledge, and could take a decision on whether or not to accept the floater. It would also be quite feasible for booking dialog objects, in the GUI, say, to check for floaters and keep a warning visible that they floaters are present and that the staff of the shift must ensure they are dealt with and homes eventually found, typically by a table booking turning out to have an earlier departure time than the one that originally anticipated.

[This activity is sometimes known as "change case". One saves up speculative requirements -- requirements not destined for implementation in any of the planned stages of incremental development and delivery -- stage n requirements, where n might be infinite. JD]