November 14, 2019

An art gallery scenario - the Artwork class

 

I want to illustrate many of the points that I have outlined in the preceding pages. Applying the maxim, "stick to something you know", I have constructed a scenario based on a London art gallery.

Cordelia Pleydell-Bouverie, the owner of The Quad Gallery in London's Mayfair, has approached one of her regular buyers, Rick Elgate. Rick is head of marketing at software developers Macroconcepts. Cordelia's accountant thinks that her gallery needs some software to support her business. Rick, never slow to miss an opportunity, puts the wheels in motion. He sends in senior analyst Gordon Petrie to find out exactly what Cordelia and her accountant require. After protracted discussions and numerous lunches at the Chelsea Arts Club, all paid for by Cordelia of course, a Negotiated Statement of Requirements is produced.

Gordon swiftly decides that the system requires a class called Artwork with the subclasses Painting, Drawing, Print and Sculpture. He and other members of the Macroconcepts team have also highlighted the need for other classes, but these can wait.

Part of the class hierarchy is represented below.

Object
   Artwork
      Painting
      Drawing
      Print
      Sculpture

Note how we format the hierarchy, indenting the subclasses of a superclass and that all class names are written in the singular, we don't say the class Artworks.

Next page » Artwork protocol

Previous page « Guide to accessors

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Up to top of page