Adding behaviour using inheritance

1
Unit 5

• Adding behaviour using inheritance
• Introducing polymorphism
• the ability of a single piece of code to operate
  with objects of different shapes

2
A simple addition first

• In each rocket controller, we re-write the same
  code for taking off
• how about adding a TakeOff method, which
  contains the necessary instructions?
• in each version of Fly that we write, we can
  simply call the TakeOff method rather than having
  to include all those instructions

3
Examine this solution

• We are now working with the Visual Studio
  solution directory AdvancedRocketry
• Open up the Rocketry solution in it
• Look for and open the AutoRocketController class
• Use the members pull-down to get to the new
  TakeOff method
• and then go to the AutoFly method to see it in use

4
General technique

• We observed that we wanted additional behaviour
  in this case a set of operations performed
  regularly
• We added a new method in a derived class of the
  original
• Users of our engineering can now use either
  version
• Try it out for yourself
• add to this class a method LoopTheLoop, including
  the necessary code to perform a loop, and then
  use it in the AutoFly method
• easiest take a copy of TakeOff and change the
  name and code appropriately

5

• Look around the rest of the class
• notice it is inherited from RocketController
• how can you tell this?
• it has quite a different kind of Fly method, and
  there's a complicated looking Land method too
• We'll explore these next

6
Motivation, using Rocketry

• Consider the Fly methods we've built
• We have written a simple sequence of instructions
  that depend on knowing the exact layout of the
  arena
• This is fine for some applications ballistic
  missile for example!
• Now consider sending a rocket to the moon or
  another planet
• Can we risk being so certain of our surroundings?
• History says no, since Neil Armstrong had to take
  over from the 'fixed' landing sequence to avoid
  Apollo 11 crashing into a crater
• So we need increased adaptability

7
Adaptability

• We need for the RocketController to adjust the
  instructions it sends to the rocket
• on the basis of the surrounding environment
• for example, how fast and in what direction is
  the rocket travelling? what obstacles are
  nearby?
• Neil Armstrong was a very adaptable controller
• he had gauges in the spacecraft to check his
  velocity
• he looked out of the window and saw the nasty
  craters
• we need these abilities

8
Extending the Rocketry model

• The rocket controller must be able to interrogate
• the Rocket
• how fast are you moving in each direction?
• what is your attitude?
• to ensure safe landings
• the Arena
• How close is the nearest obstacle in each
  direction?
• to avoid crashes along the way, and land safely

9
Explore with the Object browser

• IAdvancedRocket IAdvancedArena
• These both inherit from simpler versions of
  Rocket and Arena respectively
• Examine the added methods
• exactly the interrogation functionality we need
• and run ExecuteMission to see the new
  AutoRocketController in action
• you will see the rocket automatically landing
  itself
• experiment by changing the in-flight code, see if
  it still manages to perform a safe landing
• we will look at the detail of the Land method in
  Unit 7 it is interesting stuff

10
What's the point of all this?

• We have two kinds each of Rocket Arena
• the simple and the advanced version, defined by
  interfaces
• and an implementation for each interfaces
• Rocket, AdvancedRocket, SimpleArena,
  AdvancedArena
• Think of an interface as a contractual agreement
  on services supplied
• IRocket specifies a limited service,
  IAdvancedRocket a slightly more advanced service

11
Interfaces as contractual agreement

• A class can guarantee to produce objects meeting
  these agreements
• e.g. Rocket guarantees to meet the interface
  IRocket
• Now, many different factories can produce objects
  meeting the specification
• We have a competitive market for the best
  implementation of a given interface
• Note that the free market hasn't yet come to
  Rocketry there is only one factory for each
  kind of object
• Why have we built Rocketry this way?
• it is good engineering practice
• we've shared/reused as much design/code as
  possible
• all the components we've created may be flexibly
  used with one another

12
Interoperation

• The original RocketController will work with
• any class that implements IRocket
• any class that implements IArena
• this includes the advanced versions of Rocket and
  Arena, because they are derived from the simpler
  versions
• This feature is known as polymorphism
• literally poly many, morphism shapes
• the Rocket Controller will handle rockets and
  arenas of many shapes
• Key benefit here
• Old code (e.g. RocketController) is guaranteed to
  still work with new code (e.g. AdvancedRocket)
• Huge cost savings

13
(No Transcript)
14
Analogy

• Video recorder
• Any video recorder, no matter how new and with
  however many new features, will still play
  through virtually any television
• Why? because the interface specification the
  aerial socket is still supported
• even though the new SCART connectors have also
  been added, the original coaxial connection is
  still there
• Although note this interface is country-specific
• The interface specification in the UK is PAL
• and in the US it is NTSC

15
Summary

• Extended the concepts around inheritance
• this time, we added behaviour
• Introduced the interface
• a contractual agreement on minimum services
  provided by a class
• Introduced the concept of polymorphism
• objects of many different classes appear to be of
  the one class or interface, if
• they are derived from that one class, or
• they implement the interface
• improves code reuse and interoperability