Polymorphism Flashcards
Polymorphism: Definition
From the Greek and Latin…
- To take many forms.
- Remember that any subclass has all the instance variables and methods of its superclass, by definition.
- Therefore a subclass can only add functionality to a class… not remove it.
- All classes have all the external behaviour of their parent, so can be treated as a type of their parent classes.
- All instances of a subclass can therefore be passed as a parameter into methods expecting its parent class, stored in an array that is typed as it superclass, etc!!!
- This provides full backward compatibility of a subclass with any code written for its superclass.
Polymorphism: Application 1
An extremely powerful OO concept, that is often misunderstood.
- Any instance of a class which inherits from (extends) another can also be treated as
an instance of that class.
- An object reference of one type, can actually refer to an object of a different type!
- This is safe, as any subclass will have at least the same methods and instance variables.
- Casting is the process of converting a primitive variable from one type to another
- e.g. Converting an int into a float
- Casting can also be used convert between types of object references…
- BUT ONLY IF THE UNDERLYING OBJECT IS THE SAME CLASS OR A SUBCLASS OF THE TYPE YOU ARE CASTING TO
Polymorphism: Application 2
Casting object references ctd…
⚫ Remember we have an inheritance hierarchy?
⚫ Java will implicitly and transparently cast an object reference as necessary, provided that the transformation goes upwards the inheritance hierarchy…
⚫ Casting down the hierarchy must be done explicitly.
⚫ It is also inherently dangerous… why?
⚫ Casting cannot be undertaken outside a super/subclass relationship
⚫ E.g. a Prawn cannot be casted to a Queen…
⚫ n.b. It is only the object reference which changes type during casting.
⚫ An underlying object instance is created, lives and dies with the same class and
cannot be changed!
⚫ Polymorphism can be viewed as an ‘overlay’ that only looks at part of an object’s
implementation.
Polymorphism and Method Overriding
If we have an object reference of type ChessPiece…
⚫ …on which we invoke the canMoveTo() method…
⚫ …which method is executed?
⚫ The one defined in ChessPiece? X
The underlying object instance never changes type
⚫ The method invocation will relate to the most specific (i.e. lowest in the inheritance
hierarchy) applicable to that object instance.
⚫ EXACTLY the same functionality as if the object reference were the same type as the
object instance.
⚫ However, only access to the methods and instance variables matching the object
reference’s position in the inheritance hierarchy will be accessible.
⚫ This enables us to create heterogeneous collections of object instances. They aren’t
necessary all of the same type, but share a minimal functionality to allow them to be
interoperable…
Abstract Classes
Consider: Will we ever actually make an instance of the Chesspiece class? Or just its subclasses?
⚫ There is no good reason to…
⚫ …and allowing a programmer to do so would likely just confuse them, and
encourage them to use your classes in ways that your code might not
expect…
⚫ In OO we call such classes abstract classes.
⚫ These can only be extended, never instantiated (if you try you’ll get a compile
time error).
⚫ Java has a an abstract keyword for classes you never want to be instantiated.
Abstract Methods
Similarly, we can define methods which can never be invoked!
⚫ These are called abstract methods.
⚫ Any subclasses extending a class containing an abstract method MUST override that method. This is enforced at compile time.
⚫ Abstract methods provide a placeholder only – guaranteeing that any
subclass has an implementation of that method…
⚫ This is particularly useful for methods that you know are needed, but do not
make sense at a given level of abstraction. e.g.