M250 Unit 2 Subsection 3 - Classes and subclasses (7)

Subclasses pretty much have their own unit later on in the module, so it's worth getting familiar with them now.

Transcript

1. M250 Unit 2 Subsection 3 Classes and subclasses
2. Subsection 3 introduces HoverFrog objects. HoverFrog objects can do everything that Frog objects can do AND more. They understand all the messages in the protocol of Frog objects AND the messages up() and down(). They also have all the attributes that Frog objects do AND the additional attribute height.
3. We observe that HoverFrog is a subclass of Frog. A subclass is an extended version of its superclass. In this scenario: superclass: Frog subclass: HoverFrog So, the subclass is derived from its superclass.
4. We use subclasses and superclasses when: • We want instances of the subclass to have all the same attributes and to understand the same set of messages as the superclass. • But we also want the sub to have additional attributes and/ or to understand more messages than the superclass.
5. So because HoverFrog is a subclass of Frog: • HoverFrog objects have at least the attributes and protocol of Frog objects. • In addition HoverFrogs have the attribute height and understand the additional messages up(), upBy(), down(), and downBy().
6. In bluej this relationship is demonstrated by an arrow showing that Frog is the superclass of HoverFrog. Note how the Toad class is present but that it is not a subclass or a superclass of either Frog and HoverFrog.
7. Inheritance We say that a subclass inherits its attributes and protocol from its superclass. HoverFrog inherits its attributes and protocol from Frog.
8. We use the phrase ‘is a’ to demonstrate a superclass- subclass relationship. We say that a HoverFrog ‘is a’ kind of Frog. In other words, HoverFrog objects are an extension of Frog objects. They build upon it. The HoverFrog class is a blueprint that builds upon the blueprint of the Frog class.
9. The benefits of subclassing If we know that we need a subclass relationship between two classes of objects (by recognising an ‘is a’ relationship) then we only need to define the common attributes and protocol of both classes once – in the superclass. Then we know that the subclass will inherit these as a bare minimum, to which we can further extend the subclass by adding more.
10. In later units we’ll observe: • How to create a subclass. • How a subclass might differently initialise the common attributes it shares with the superclass. In our case, HoverFrog objects and Frog objects both have position initialised to 1. But they could be different. • How we might override the behaviour of an inherited message. In our case every message that HoverFrog inherits from Frog behaves the same for both (e.g. left() and home()). But what if we wanted different behaviour from the same message?
11. Questions Q: Do Frog and HoverFrog objects respond the same way to the message left() ?
12. Questions Q: Do Frog and HoverFrog objects respond the same way to the message left() ? A: Yes. Since HoverFrog is the subclass of Frog, HoverFrog objects can understand all the messages as defined in the Frog class. Since left() is defined in the Frog class then HoverFrog objects understand this.
13. Questions Q: What would happen if we sent an instance of Frog the message up() ?
14. Questions Q: What would happen if we sent the message up() to an instance of Frog? A: An error would occur. The message up() is not in the protocol of Frog, it is in the protocol of HoverFrog. Since Frog is NOT a subclass of HoverFrog (it is the other way around), it does not inherit its protocol, so can’t understand up().