April 16, 2024
The protocol of Artwork and its subclasses
For the purposes of this discussion, I will restrict the protocol, which
Macroconcepts have decided is required, to the following:
title, title:, price, price:, height, height:, media, media:, width,
width:, yearCreated, yearCreated:, size, initialize
In other words an instance of Artwork has the attributes title, price,
height, media, width and yearCreated. The decision that Artwork should
have these attributes has been made as a result of the development process.
All of these attributes, or properties, will be stored as the instance variables
title, price, height,media, width, yearCreated. There are corresponding
accessor messages consisting of the getters title, price, height, media,
width, yearCreated together with the setters title:, price:, height:,
media:, width:, yearCreated:. Methods will eventually be written to
implement these messages. You will see that the Artwork protocol contains
two other messages, size and initialize. How these messages are implemented
will not concern us for the moment.
We now need to look at the protocol of the four subclasses of Artwork. I would ask you to keep in mind the concept of abstraction and remember that the OO methodology begins with generalizing at a high level and then moves down and particularizes by adding extra detail to our model. Object is more abstract than Artwork which in turn is more abstract than its subclasses. These subclasses will inherit the protocol of their superclasses, Artwork and Object. Furthermore, Painting, Drawing, Print and Sculpture will inherit all the attributes and hence instance variables of Artwork.
There is no need to list the protocol of the superclass in a subclass, we only ever list the additional messages that our classes require. Here are the protocols for these subclasses.
Class: Painting
framed, framed:, initialize
Class: Drawing
framed,framed:, initialize
Class: Print
framedPrice, framedPrice:
Class: Sculpture
depth, depth:, size
We can see that Painting and Drawing have an additional instance variable framed, with corresponding accessor messages. Print has an additional instance variable framedPrice. Sculpture has an instance variable depth. The accessor pairs are as expected. You will note that Painting and Drawing have an initialize message in their protocol and that Sculpture has a size message. Why, when all these classes have inherited the protocol of Artwork, does initialize and size re-appear in the protocol of these subclasses? The answer is that design considerations have led to more detail being added to the subclasses. The Smalltalk messages initialize and size messages in the subclasses have a different implementation. These particular messages have been overridden. However all instances of all these classes will respond to messages called initialize and size even though the implementation of these messages may differ in each class.
This property of OOP, whereby objects belonging to different classes can respond to the same message, is called polymorphism. It has far reaching consequences for the development of software. Later in the course you will be introduced to the concept of usability in software design. Reducing the number of messages that a user has to remember is one obvious advantage of polymorphism. Cut, copy and paste are universally accepted messages that are used in many applications. The implementation of these messages is hidden from the user; it is only necessary to remember the message.
A discussion of polymorphism deserves far greater space than I am giving it here and it is possible that I will return to this at a later date. If you begin to read other texts on OOP you will discover that not everyone agrees on the definitions of these concepts and polymorphism is no exception. However for the purposes of M206 the preceding interpretation should suffice.
We can now look at some instance methods.
Next page » Artwork methods
Previous page « Artwork class
⇑ Up to top of page