Site Map  Search

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

Exercise Solutions (Restricted)

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

Chapter 2

Question 2.5
(You may already have done a similar exercise to this one, in the previous chapter. You might consider it worthwhile to do another; then again you might not.)
Think of four different subject matters -- preferably ones you are familiar with, and preferably not those of the case studies (catering and crime). Think of four entities (relevant, subject matter objects) for each subject matter. Ask yourself if your entities actually do anything. If an entity does do things, list a couple of its example actions. Now check once again that your entities truly are there in the subject matter and that their actions are as well; assure yourself that you haven't made anything up.

If you have enough object-oriented programming experience, picture some Java, C++, etc. objects carrying out the same actions as their subject matter counterparts and ask yourself it that would be reasonable. This book says that it wouldn't. If you currently have little experience of object-oriented programming, return to these lists when you've more.

The kinds of subject matters I've worked on included:

  • Personnel: Department, Timesheet, Employee, Qualification Granting Body
  • Accounting: Invoice, Customer, Petty Cash Account, Balance Sheet
  • Theatre Seat Reservations: Seat, Performance, Booking Fee, Payment
  • Radar Operator Training Simulator: Cloud, Obstruction, Beam, Reflection

I've listed some of their entities. Several of them don't do anything at all. A Timesheet, an Invoice, a Petty Cash Account and a Balance Sheet, for example, don't actually do anything at all. Pushing at the limits of credulity, a theatre Seat sometimes flips to its vertical position, leading to potential embarrassment if one hasn't noticed; as well as failing the test of relevance however, this would also fail to be something sensible for a software Seat object to do.

A Qualification Granting Body issues a qualification, for example; but would its counterpart Java or C++ object do anything similar? No. Even if the systems between the Qualification Granting Body and ourselves were completely automated, the qualification would still arrive out of the blue, over the wire, and not be created by our Qualification Granting Body object.

What does a Customer do. They buy things and they, hopefully, pay their bills. Neither of these would be sensible instance methods (non-static member functions) for a software object.

A Performance does lots of interesting things. It entertains. It gets rave reviews or Golden Turkey awards. Once again, these are not sensible things for the Java or C++ objects to do. Am I just picking the silly examples? No, it wouldn't matter what you picked. What about the performance generating revenue? Well it doesn't -- that's a fabrication (sometimes justified by calling it an abstraction). The performance attracts people and the people stump up the revenue.

In the Radar system, the real Cloud absorbs some of the radiation from the radar transmitter and reflects some of it back. In the software, however, we will have to calculate the amount of reflected radiation, and that calculation is more likely to be done by the beam, receiving the cloud as argument, or, even more likely, by a calculation object whose existence and nature will be pure invention.

[What about subject matter entities that have things done to them. Some early methods advocated modeling the actions suffered or performed by subject matter entities (or real world entities as they might have been called.) We could say that the Invoice suffers (or enjoys) being paid. But, again, that's no clue as to what methods or member functions the counterpart software object would have. Something else would probably message the Invoice that it had been paid, on such-and-such a date. And that something else, isn't going to be a Customer object; it's going to be something like a GIU (graphical user interface) invoice object, that we are not going to be programming up unless we're completely mad masochists. JD]

Question 2.6
Consider the subject matter entities from the previous exercise. List a couple of the measurable properties (attributes) of each entity. Again depending on whether or not you have enough experience of object-oriented programming, ask yourself now or later whether or not the software objects would reasonably exhibit the same properties. (This book says they will.)

Picking up the example from earlier (Chapter 1, exercise 5), the DVD entity found in our rental shop subject matter would have measurable properties of rating, and loan period, and it would seem entirely reasonable that any Java or C++ DVD object would happily respond to the messages rating() and loanPeriod().

The Performance from the Theatre Seat Reservation system has a date and a time in the real world. And these are eminently sensible things to turn into query messages for its object counterpart to answer.

Any and all relevant attributes of relevant subject matter entities will suggest reasonable query messages for Java, C++ or Smalltalk objects. They would suggest reasonable properties* for Object Pascal, C# and CORBA objects:

  • Department: name, code, budget, ...
  • Timesheet: period (but not the contents -- the entries would be better off as related entities with their own attributes) , ...
  • Employee: name, postal address, age, ...
  • Qualification Granting Body: date established, postal address , ...
  • Invoice: date issued, amount excluding taxes, number, ...
  • Customer: formal name, postal address, date established, ...
  • Petty Cash Account: nominal ledger account number, maximum limit amount, ...
  • Balance Sheet: nominal ledger account number, ...
  • Seat: row (although this might be better as an entity in its own right), number, ...
  • Performance: date, start time, ...
  • Booking Fee: monetary amount, ...
  • Payment: date received, amount received, ...
  • Cloud: position, density, ...
  • Obstruction: position, density (so some opportunities to generalize)
  • Beam: energy, width, ...
  • Reflection: energy, start time, end time, ...

Question 2.9
In the context of object-oriented software engineering, define type and define class. Compare and contrast the two.

"Type" is generally taken to be a notion that describes and specifies interchangeability. Two object instances have the same type if they can both serve their clients interchangeably. For good, ordinary object instances, this means that they accept the same set of messages. We normally extend this to include intentionality rather than just coincidence. (And an object is of a subtype if the messages denoted by the supertype are a subset of its accepted messages.)

"Class" is much harder to define. It varies from language to language. And even within a language (particularly C++) a class can be put to a large number of quite diverse uses. In the Smalltalk language, simplifying a tiny bit, a class is just an object that specializes in defining and making other objects. So the only general-purpose definition of class that I can come up with is: a means for managing object instances.

Type then is an external perception and class is both an internal and external perception. Type is of interest to the client end of a message, whereas class tends to be of interest to the server end. Variables (and parameters and returns) have types; objects come from classes. In nearly all everyday OO languages, an object can exhibit several types but is instantiated from just one class. A concrete class is a class and a type, but it's usually a poor type. An abstract base class is a class and a type, and is a slightly more useful type. We got into so much trouble with base classes (superclasses) however, that today we tend to prefer purely abstract base classes (pABC) for our types, or in more modern languages, interfaces for our types.

 

* These languages (Object Pascal, C# and CORBA's IDL have a device called a property: a value that can be exhibited to the outside world independently of whether or not the object actually stores the value within.