Polymorphism Are there different ways to solve the Harvester problem? – Robot teams – instead of one robot to solve a problem, let’s get a team of robots to tackle the problem Three robots, each picking two rows Six robots each picking one row – Download HarvesterW3.zip demo projectHarvesterW3.zip

Names of Robots as “references” We do not need three different names to refer to three different robots – We can use one name to refer to three robots in sequence – Name of robots are “references” public static void task() { Harvester Karel = new Harvester(2, 2, East, 0); Karel.pickTwoRows(); Karel.turnOff(); Karel = new Harvester(4, 2, East, 0); Karel.pickTwoRows(); Karel.turnOff(); Karel = new Harvester(6, 2, East, 0); Karel.pickTwoRows(); Karel.turnOff(); }

Declaration versus Robot Creation We only declared a Robot name once Harvester Karel = – Karel is a name that refers to Harvester robots We created three robots = new Harvester(2, 2, East, 0); – Creating a Harvester robot at 2, 2, facing East, with 0 beepers We could better illustrate this in code: Harvester Karel = null; Karel = new Harvester(2, 2, East, 0) – null : a reference to a robot is not referring to any real robot

Similar Tasks We want to do several tasks, which are very similar Task: We want to lay down beepers in a field with 5 rows, four columns. Odd numbered rows will have two beepers on each corner, even numbered rows will have three beepers on each corner

Different Robots, Similar skills TwoRowLayer vs ThreeRowLayer Very similar, differ only in one way Capture the commonality in an abstract class – A template for the construction or more specific robots – Download BeeperLayer.zip demo projectBeeperLayer.zip This is polymorphism: two objects (robots) receiving the same instruction, will behave differently – The object receiving the instruction determines what is done when the message is received

Single robot vs. team of robots We could build a robot to solve every possible task, a super-duper robot. Should we? – This results in a large program – Large programs are hard to build and harder to modify – Large programs are hard to understand Better to build small robot classes with a single, simple to understand purpose – With small robot classes we can choose a set of robots to solve much of a complex task, and write other simple classes to perform the rest If we design our classes well, our robots will be trustworthy

Choreographers Let one robot coordinate the actions of some others Need two different kinds of robots – One a Choreographer, because it directs the others – The others can be standard ur_Robots The Choreographer will set up the others so that they mimic the actions of the others – Download Choreographer.zip demo projectChoreographer.zip

Choreographer details Choreographers need to know the names of the other robots, so we make these private to the Choreographer – Helpers to the robot class being declared, but not accessible to other robots or to the main task block We will also overwrite (redefine) the inherited primitive instructions of the Robot class, so that all the other private robots know what to do – move(), turnLeft(), pickBeeper(), putBeeper(), turnOff()

Doing Arithmetic with Robots Computers manipulate numbers well We want to teach robots to manipulate numbers We could represent a value, say 24, by putting 24 beepers on a corner Or, we could use two corners, the first will have 2 beepers, and the second will have 4 beepers

Representation for robot addition To add two digits we could set up a world to look like this (but we will start the columns on 2 nd Avenue, not 1 st ) Download Adder.zip demoAdder.zip

The robot addition classes The Adder robot will utilize two helper robots – The first to see if a carry is necessary – The second will actually do the carry if necessary These robots will be created by a parent, and will need to find it in order to help it, we will start with a super (parent) class that provides the finding method: called Finder – All other classes ( Adder, Carrier, Checker ) will be subclasses of Finder) – Actually, we are not going to create any Finder robots

The robot addition classes Finder : – the parent superclass; – a convenient place to place methods common to all the other classes Adder : – Creates helpers; – Picks up all beepers north of it – Returns to 1 st Street – Deposits all of the beepers there

The robot addition classes Carrier : – Quite simple – Takes another beeper to adjacent column if necessary – Given an infinite number of beepers Checker : – Does all of the interesting work – Are there 10 or more beepers collected by Adder? Yes, return true No, return false – Actually it has to check for multiples of 10 – Also, if it finds less than 10 it must leave them on the corner

Polymorphism: Design? When is it appropriate to design a new class, and when should we modify or add to an existing class? – To really be answered as we continue in the course Guidelines: – Modify If a class contains errors or omissions, modify it Omissions mean there is some action or predicate needed to complete the basic functionality of the class – New class If we have a useful class, but we need new, specialized functionality, then build a new class as a subclass Sometimes a class is what we want, but one or two methods may need to be modified