Introduction to Computer Science Extending Robots’ Vocabularies –New Methods –Top-Down Design –Multiple Robots Unit 2

2- 2 The Basic Language Can Be Clumsy To make a robot turn right, we have to send it 3 turnLeft messages In the robot world there are 8 blocks to the mile. To have a robot go ten miles east, pick up a beeper, then move ten miles north, we would need to have 160 move messages. We think in one language, but must program robots in another.

2- 3 The Solution Give the robot a dictionary of useful methods and definitions Each definition is built from simpler ones that the robot already understands The simplest instructions are the primitive ones that the robot knows Now we can solve problems using instructions natural to our way of thinking.

2- 4 For Example… A new method, turnRight, can be defined as three turnLeft instructions A new moveMile method can be defined as eight move instructions Our beeper picking program can now have 20 moveMiles and 8 moves (in the definition of moveMile), 28 instead of 160. The smaller program is much easier to read and understand. This is important!

2- 5 How do we Get a Robot that Has New Methods? We create a new Class that extends the BasicRobot Class The new Class inherits all of the methods and attributes of the BasicRobot Class, but then adds new methods of its own Then we use the new Class to create instances of robots, with the new methods

2- 6 Inheritance extends Robots created as instances of Class 2 have access to methods 1, 2, and 7 Class 1 method 1 method 2 Class 3 method 5 method 6 Class 2 method 7 Robots created as instances of Class 3 have access to methods 1, 2, 5, and 6

2- 7 Inheritance Class 1 is more general, less specific Classes 2 and 3 have more methods and attributes extends Class 1 method 1 method 2 Class 3 method 5 method 6 Class 2 method 7

2- 8 Class Hierarchy (showing Attributes, not Methods) extends Containers filled material color Boxes length method 6 Cereal Boxes Cylinder extends length width height radius height type of cereal Software Boxes type of software extends Objects made from this class have all the attributes of the classes above them

2- 9 Constructing Objects The objects we create, using a constructor, can be from any of those classes (though the most specific ones might be the most useful) We can make a Cheerios box object or a Corn Flakes box object from the “Cereal Boxes” class But we might also make just a “box” object from the Boxes class

2- 10 The Details, Defining a new Method, moveMile, inside a new class class MileWalker extends BasicRobot { void moveMile { move; move; move; move; move; move; move; move; } }

2- 11 class MileWalker extends BasicRobot { void moveMile { move; move; move; move; move; move; move; move; } } The Details, Defining a new Method, moveMile, inside a new class New reserved words, class, extends, void

2- 12 Visually, What Have We Got? move turnLeft pickBeeper putBeeper turnOff BasicRobot x-location y-location direction num-beepers move turnLeft pickBeeper putBeeper turnOff moveMile MileWalker x-location y-location direction num-beepers extends

2- 13 Block Structuring Block structuring makes one big instruction out of a sequence of smaller ones — place a sequence of instructions between the delimiters { and }: { ; } The entire block represents one method.

2- 14 But who is the “move” a Message To? The messages will be sent by an instance of the MileWalker class to itself ! class MileWalker extends BasicRobot { void moveMile { move; move; move; move; move; move; move; move; } } We could also write “this.move”, but leaving it off is legal and simpler.

2- 15 Robot Talks to Himself Using a constructor, we make an instance of the MileWalker class, called steve: MileWalker steve = new MileWalker(2, 3, East, 0) Now, we’ve got a new initialized object named steve We send steve a moveMile message: steve.moveMile; steve receives the message, and sends himself 8 “move” messages

2- 16 Finally, turnRight class RightTurner extends MileWalker { void turnRight { turnLeft; turnLeft; turnLeft; } } Yes, Virginia, we can have multiple levels of inheritance—and we can redefine ( override) an existing definition in an inheriting class. BasicRobot MileWalker RightTurner extends

2- 17 Overriding Inherited Methods (bizarre example) Let’s say we wanted a new Class of Robot, Spinner, who turned around twice when it was sent the turnRight message class Spinner extends RightTurner { void turnRight { turnLeft; turnLeft; turnLeft; turnLeft; turnLeft; turnLeft; turnLeft; }

2- 18 The Meaning and Correctness of New Methods Robots do not understand what methods are supposed to accomplish; robots are quite literal: void turnRight { turnLeft; turnLeft; } This is an intent error. A new instruction can also cause an error shutoff.

2- 19 Meaning and Correctness The definition on the previous slide is a perfectly legal method, but fundamentally wrong. The name says what the method is intended to do. The definition says how the method does what the name implies. The two had better match; otherwise, one or both should be changed.

2- 20 Simulating Instructions When simulating newly-defined methods, make sure to simulate literally what the method does, and not take a shortcut and simulate what the defined method’s name means. Robots can’t take the shortcut; neither can you.

2- 21 Defining New Instructions in a Program Initial Situation Final Situation

2- 22 Defining New Instructions in a Program

2- 23 Defining New Instructions in a Program

2- 24 Defining New Instructions in a Program

2- 25 Defining New Instructions in a Program

2- 26 Defining New Instructions in a Program

2- 27 Defining New Instructions in a Program

2- 28 Defining New Instructions in a Program

class StairSweeper extends BasicRobot { void turnRight { turnLeft; turnLeft; turnLeft; } void climbStair { turnLeft; move; turnRight; move; } } main { StairSweeper larry = new StairSweeper(2, 1, East, 0); larry.climbStair; larry.pickBeeper; larry.climbStair; larry.pickBeeper; larry.climbStair; larry.pickBeeper; larry.turnOff; }

Importing Class Definitions Instead of putting all these things together in one file, we could break them up as follows: class StairSweeper extends BasicRobot { void turnRight { turnLeft; turnLeft; turnLeft; } void climbStair { turnLeft; move; turnRight; move; } } A file called StairSweeper.r import StairSweeper; main { StairSweeper larry = new StairSweeper(2, 1, East, 0); larry.climbStair; larry.pickBeeper; larry.climbStair; larry.pickBeeper; larry.climbStair; larry.pickBeeper; larry.turnOff; } A file called main.r

2- 31 The Dictionary Declaration of a new class (and its new methods) is placed before the main block. This area is called the dictionary; each definition is called a dictionary entry The definition of BasicRobot is “built-in” The order of dictionary entries is not important

2- 32 Memory fades… The Controller does not memorize dictionary entries forever When it is turned on, the only thing it remembers is the BasicRobot class and reserved words Each program has to include a full set of definitions for all new instructions it uses

2- 33 An Ungrammatical Program class RightTurner extends BasicRobot { void turnRight turnLeft; turnLeft; turnLeft; } } main { RightTurner ted = new RightTurner(2, 2, North, 0); ted.move; ted.turnRight; ted.turnOff; }

2- 34 The Controller Finds a Mistake When the Controller is being read a program it is constantly looking for lexical and syntactic errors The Controller discovers syntactic errors by checking for proper grammar and punctuation

2- 35 class RightTurner extends BasicRobot { void turnRight turnLeft; turnLeft; turnLeft; } } main { RightTurner ted = new RightTurner(2, 2, North, 0); ted.move; ted.turnRight; ted.turnOff; } An Ungrammatical Program The next thing should have been a delimiter, { Forgetting to use delimiters can lead to syntactic errors.

2- 36 Programming by Top-Down Design How can we naturally write a set of methods that are correct, simple to read, and easy to understand? We do not first write all the methods and then write the main program block (how can we know ahead of time which instructions will be needed?).

2- 37 Top-Down Design First write the main program block using any methods we want, then write the definitions of these methods in a new class Then, put it all together

2- 38 Top-Down Design The process can continue, with methods used in the dictionary causing us to define more methods (above them) Execution Block Dictionary }

2- 39 The Harvest Task Initial Situation Final Situation

2- 40 The (High-Level) Program main { Harvester bill = new Harvester(2, 2, East, 0); bill.move; bill.harvest2Furrows; bill.positionForNext2; bill.harvest2Furrows; bill.positionForNext2; bill.harvest2Furrows; bill.move; bill.turnOff; } New Methods: harvest2Furrows positionForNext2

2- 41 One of the New Methods void harvest2Furrows { harvestAFurrow; goToNextFurrow; harvestAFurrow; } New Methods:  harvest2Furrows positionForNext2 harvestAFurrow goToNextFurrow Subtasks generate sub-subtasks: Remember: this method will be inside a new Class, of which the bill robot will be an instance The object created from this class will be sending messages to himself...

2- 42 Another New Method void harvestAFurrow { pickBeeper; move; pickBeeper; move; pickBeeper; move; pickBeeper; move; pickBeeper; } New Methods:  harvest2Furrows positionForNext2  harvestAFurrow goToNextFurrow Assumption: Robot is next to first beeper in a furrow, rest of the furrow in front of him

2- 43 Yet Another void goToNextFurrow { turnLeft; move; turnLeft; } New Methods:  harvest2Furrows positionForNext2  harvestAFurrow  goToNextFurrow Assumption: Robot is facing east and wants to go one block north, then turn to face west

2- 44 And Finally… void positionForNext2 { turnRight; move; turnRight; } New Methods:  harvest2Furrows  positionForNext2  harvestAFurrow  goToNextFurrow turnRight Assumption: Robot is facing west on the corner of last harvested beeper in a furrow

2- 45 Now Assemble into Complete System class Harvester extends BasicRobot { void turnRight {... } void positionForNext2 {... } void goToNextFurrow {... } void harvestAFurrow {... } void harvest2Furrows {... } } main { Harvester bill = new Harvester(2, 2, East, 0); bill.move; bill.harvest2Furrows; bill.positionForNext2; bill.harvest2Furrows; bill.positionForNext2; bill.harvest2Furrows; bill.move; bill.turnOff; }

2- 46 Verify the Program Verification through simulation is still necessary “Programs are assumed to be guilty of being wrong until they are proven correct.”

2- 47 Consider the Methods Your Objects Should Have Your objects can have many small methods, even if the new methods are only executed once in your program! Early decisions that are made are the most important—they establish the structure of the rest of the program (try several high-level plans). Use words and phrases to convey the intent of the program…

2- 48 Object Oriented Analysis and Design In a real (non-robot) system, you have to decide what the objects are, then figure out what methods they should have There are entire courses on how to analyse a system, decide what the objects are, and design them effectively There is both art and science in good object oriented programming

2- 49 How to Break It Up We could easily solve the problem of harvesting the field by using three separate robot objects, all instances of the class Harvester. The main block will send messages to them one after another.

Three Separate Robots Harvesting class Harvester extends BasicRobot { void turnRight {... } void positionForNext2 {... } void goToNextFurrow {... } void harvestAFurrow {... } void harvest2Furrows {... } } A file called Harvester.r import Harvester; main { Harvester john = new Harvester(2, 2, East, 0); Harvester paul = new Harvester(2, 4, East, 0); Harvester george = new Harvester(2, 6, East, 0); john.move; john.harvest2Furrows; john.turnOff; paul.move; paul.harvest2Furrows; paul.turnOff; george.move; george.harvest2Furrows; george.turnOff; } A file called main.r

2- 51 Objects Sending Messages to Other Objects We could have a single robot that, when sent a move message, moves himself and send two other move messages to two other “helper” robots The new class overrides the definition of move so that it is defined as –move myself –move helper 1 –move helper 2 Same thing for pickBeeper and turnLeft

2- 52 Objects Controlling Other Objects Send first robot move message

2- 53 Objects Controlling Other Objects He moves

2- 54 He sends a move message to first helper First helper moves Objects Controlling Other Objects

2- 55 He sends a move message to second helper Second helper moves Objects Controlling Other Objects

2- 56 Send first robot pickBeeper message Objects Controlling Other Objects

2- 57 He picks up beeper Objects Controlling Other Objects

2- 58 He sends a pickBeeper message to first helper First helper picks up beeper Objects Controlling Other Objects

2- 59 He sends a pickBeeper message to second helper Second helper picks up beeper Objects Controlling Other Objects

2- 60 First robot is a new class, where we have overridden the definitions of move, pickBeeper, etc. Helper robots can be plain BasicRobots Objects Controlling Other Objects How does the first robot define his own, simple, “move”, when he is overriding “move”?

2- 61 The Paper Retrieving Task main { PaperBoy lou = new PaperBoy(4, 3, West, 0); lou.goToDoor; lou.exitHouse; lou.getPaper; lou.returnToDoor; lou.enterHouse; lou.goBackToBed; lou.turnOff; }

2- 62 Writing Understandable Programs A good program is the simple composition of easily understandable parts We must make sure to name our new methods properly –the names describe how tasks are accomplished –imagine the previous program with methods named “firstMethod” and “doItNow”

2- 63 Defined Methods Make a Program Easier to Debug/Verify Defined methods can be independently tested — verified, then remember just what the object does, not how it does it Defined methods impose a structure to help locate bugs Hiding the implementation of an object’s methods is a central concept in object oriented programming

, plus or minus 2 The human brain can focus on a limited amount of information at one time The ability to ignore details that are no longer relevant is useful for program writing and debugging

2- 65 Build a House Task Initial Situation Final Situation

2- 66 Good OOP Means Seeing Appropriate Decomposition Initial Situation Final Situation Areas of Responsibility

2- 67 Many Choices are Possible This breakdown into two objects is only one possible solution Many others exist Good design has many aspects, and we’ll look at this in greater detail throughout the course: –Considering the objects that comprise a system –Considering the methods that each object (class) should have

2- 68 Keep them Small Use multiple classes, as appropriate for the system Methods should rarely exceed five to eight instructions If they are longer, break them up That includes the main execution block WRITE MANY SMALL, WELL-NAMED METHODS, RATHER THAN A FEW OVERSIZED METHODS.

2- 69 Imagine All the Programs… Imagine the harvesting program without defined methods How easy to convince someone it is correct? How easy to locate and correct an error (like a missing instruction)? How hard to change slightly (make 3 more beepers per furrow)?