Roboten Karel lär sig Java

Transkript

1 Verónica Gaspes Högskolan i Halmstad 23 augusti 2010 Roboten Karel lär sig Java Tacksägelse Detta är en översättning och en anpassning till Högskolan i Halmstads programmeringsmiljö av delar av Karel the Robot Learns Java,ett material framtaget av Eric Roberts vid Stanford University för deras kurs Programming Methodology. Acknowledgement This is a translation and an adaptation to the programming environment at Halmstad University of parts of Karel the Robot Learns Java. The original was written by Eric Roberts at Stanford University for their course Programming Methodology. Kapitel 1: en introduktion. Vad är Karel? Karel är en mycket enkel robot som lever i en mycket enkel värld. Genom enkla kommandon kan Du styra den att genomföra vissa uppdrag i sin värld. Att beskriva dessa kommandon kallas för programmering. Till att börja med förstår Karel bara ett litet antal fördefinierade kommandon, men en viktig del av programmeringsprocessen består av att lära Karel nya kommandon som utökar dess förmågor. När Du programmerar Karel för att utföra ett uppdrag, måste Du skriva ner de nödvändiga kommandon på ett mycket exakt sätt så att roboten kan tolka det Du har instruerat den att göra. Speciellt måste de program Du skriver följa ett antal syntaktiska regler som definierar vilka kommandon och språkformer som är giltiga. Tillsammans utgör de fördefinierade kommandona och de syntaktiska reglerna Karels programmeringsspråk. Detta språk är konstruerat för att likna Java så mycket som möjligt för att underlätta övergången till det språk Du skall använda resten av läsperioden. Karels program har till stor del samma struktur och använder samma grundläggande element som Javaprogram gör. Den mest påtagliga skillnaden är att Karels programmeringsspråk är ytterst litet: det har mycket få kommandon och regler. Det är till exempel möjligt att lära ut hela språket på ett par timmar. Efter den tiden skall Du känna till allt Karel kan göra och hur man beskriver dessa handlingar i ett program. Detaljerna är lätt att behärska. Trots detta kommer Du att märka att problemlösning kan vara mycket utmanande. Problemlösning är programmeringens väsen; språket och reglerna är bara en mindre angelägenhet på vägen. I mer sofistikerade språk, som Java, finns det så många detaljer att dessa ofta blir fokus för kursen och det man skall lära sig. När detta sker, tenderar de mera kritiska aspekterna kring problemlösning att försvinna. Genom att börja med Karel kan Du fokusera på problemlösning från början. Karels värld Karels värld definieras genom gator som löper vågrätt (öst-väst) och avenyer som löper lodrätt (nord-syd). Karel kan bara befinna sig i en korsning mellan en gata och en aveny och måste vara vänd mot en av de fyra kompassriktningarna nord, syd, öst och väst. En typisk situation visas nedan. Här återfinns Karel vänd mot öst i korsningen mellan första gatan och första avenyn. 1

2 Flera andra delar av Karel s värld ses i denna exempel. Föremålet framför Karel är en beeper. Som de beskrivs i Rich Pattis bok är beepers plastic cones which emit a quiet beeping noise 1. Karel kan bara upptäcka en beeper om den är i samma korsning. De hedragna linjerna i diagrammet är murar. Murar tjänar som barriärer i Karels värld. Karel kan inte ta sig genom murar och måste istället ta sig runt dem. Karels värld är alltid omgiven av murar kring kanterna, men världen kan ha olika dimensioner beroende på de specifika problem Karel måste lösa. Vad kan Karel göra? När Karel lämnar fabriken kan den utföra ett mycket litet antal kommandon: move() Ber Karel att förflytta sig framåt ett kvarter. Karel kan inte utföra move()-kommandot om det finns en mur som blockerar hans väg. turnleft() Ber Karel att rotera 90 grader åt vänster (moturs). pickbeeper() Ber Karel att ta upp en beeper från en korsning och lagra den i sin säck, som kan innehålla ett oändligt antal beepers. Karel kan inte utföra kommandot om det inte finns en beeper i den aktuella korsningen. putbeeper() Ber Karel att ta en beeper från sin säck och ställa den i den aktuella korsningen. Karel kan inte utföra kommandot om det inte finns någon beeper i hans säck. De tomma parenteser som avslutar varje kommando är en del av den syntax som delas av Karel och Java och de används för att uttrycka anropandet av kommandot. Så småningom kommer Du när Du skriver program att ange extra information i mellanrummet mellan parenteserna, men sådan information är inte en del av Karels ursprungliga språk. Parenteserna skall därför vara tomma i Karels program, men Du måste komma ihåg dem i alla fall. Det är också viktigt att förstå att flera av dessa kommandon medför begränsningar i Karels aktiviteter. Om Karel försöker göra något ogiltigt, så som att ta sig genom en mur eller ta upp en beeper som inte finns där så uppstår ett fel. Vid ett sådan händelse visar Karel ett felmeddelande och utför inga av de resterande kommandona. Karels kommandon kan dock inte utföras i isolering. Innan Karel kan svara på kommandon måste de infogas i ett Karelprogram. Du skall snart få se några enkla Karelprogram, men innan dess är det nyttigt att berätta lite om den programmeringsfilosofi som ligger bakom denna implementation av Karels programmeringsspråk. Karel och det objektorienterade paradigmet I objektorienterad programmering fokuserar programmeraren på att modellera beteendet hos begreppsmässigt integrerade enheter kallade objekt. Objekt i ett programmeringsspråk kan motsvara fysiska objekt i verkligheten, men lika ofta representerar de mer abstrakta begrepp. Det centrala i varje objekt verkligt eller abstrakt är att det måste utgöra en meningsfull helhet 2. En av huvudfördelarna med det objektorienterat paradigmet är att det uppmuntrar programmerare att inse det grundläggande förhållandet mellan tillståndet hos ett objekt och dess beteende. Tillståndet hos ett objekt består av ett antal attribut som berör objektet och som kan förändras över tid. Till exempel kan ett objekt karakteriseras genom dess position, dess färg, dess namn och ett antal andra egenskaper. Med ett objekts beteende menas vilka sätt objektet reagerar på händelser i dess värld eller på kommandon från andra objekt. I objektorienterad programmering använder man i allmänhet begreppet meddelande för något som orsakar ett beteende hos ett objekt (fast det kan var tydligare att använda ordet kommando när det gäller Karel). Responsen på ett meddelande brukar innebära att tillståndet hos objektet ändras. Till exempel, om en av de egenskaper som ingår i ett objekts tillstånd är dess färg, så kommer objektet troligen att reagera på ett setcolor(blue) meddelande med att byta färg till blå. 1 plastkoner som ger ifrån sig ett dovt tutande ljud 2 must make sense as a unified whole 2

3 /* * File: BeeperPickingKarel.java * * The BeeperPickingKarel class extends the basic Karel class * by defining a "run" method with three commands. These * commands cause Karel to move forward one block, pick up * a beeper, and then move ahead to the next corner. import stanford.karel.*; public class BeeperPickingKarel extends Karel { pickbeeper(); Figur 1: Enkelt Karel-exempel för att plocka upp en enda beeper På många sätt är Karel en idealisk miljö för att illustrera det objektorienterade angreppssättet. Även om ingen har byggt en mekanisk variant av Karel, är det ändå lätt att föreställa sig en Karel i verkligheten. Karel är en robot och robotar är verkliga objekt. De egenskaper som definierar Karels tillstånd är dess position i världen, den riktning den pekar mot, och antal beepers i dess säck. Karels beteende definieras av de kommandon den reagerar på: move(), turnleft(), pickbeeper() och putbeeper(). Kommandot move() ändrar Karels position, turnleft() ändrar dess riktning, och de två sistnämnda kommandona ändrar antalet beepers i Karels säck och antalet beepers i den aktuella korsningen. Karels miljö tillhandahåller även ett användbart ramverk för att definiera ett av de centrala begreppen i objektorienterad programmering. Både i Karel och i Java är det väsentligt att skilja mellan klass och objekt. Det enklaste sättet att förstå skillnaden är att tänka på en klass 3 som ett mönster eller mall för objekt som delar ett gemensamt beteende och en gemensam samling tillståndsattribut. Som Du kommer att förstå i nästa kapitel så står ordet Karel i Karel program för klassen av robotar som kan reagera på kommandon move(), turnleft(), pickbeeper() och putbeeper(). När Du har en robot i världen, är denna robot ett objekt som är en specifik instans 4 av klassen Karel. I denna kurs skriver vi bara program där det bara förekommer en enda robot. Kapitel 2: att programmera Karel I dess enklaste form är ett Karelprogram en definition av en ny Karel-klass som beskriver en följd av fördefinierade kommandon som skall utföras när programmet körs. Ett mycket enkelt program visas i Figur 1 Programmet i Figur 1 består av flera delar. Första delen består av följande rader: 3 Översättarens inlägg: Klass (substantiv): grupp, avdelning; kategori, sort, art, typ. Klassa (verb): sätta i en speciell klass; klassificera 4 instance 3

4 /* * File: BeeperPickingKarel.java * * The BeeperPickingKarel class extends the basic Karel class * by defining a "run" method with three commands. These * commands cause Karel to move forward one block, pick up * a beeper, and then move ahead to the next corner. Dessa rader är ett exempel på ett kommentar, som är text skriven för att förklara programmets funktion för människor. Kommentarer i både Karel och Java börjar med tecknen /* och avslutas med tecknen. I detta exempel börjar kommentaren på första raden och löper över flera rader. Stjärnorna i början av mellan raderna behövs inte, men gör det lättare för människor att se hur långt kommentaren sträcker sig. I ett enkelt program är långa kommentarer onödiga för att programmets funktion är uppenbar, men de är extrem viktiga för att dokumentera större och mer komplexa program. Andra delen i programmet är raden import stanford.karel.*; Denna rad begär att programmet inkluderar alla definitioner i biblioteket stanford.karel 5. Detta bibliotek innehåller alla grunddefinitioner som behövs för att skriva Karel-program, såsom definitioner av operationerna move() och pickbeeper()(). Eftersom Du alltid behöver tillgång till dessa operationer, måste alla Karel-program Du kommer att skriva innehålla denna rad före resten av programmet. Sista delen i programmet består av följande klassdefinition: public class BeeperPickingKarel extends Karel { pickbeeper(); För att förstå denna definition hjälper det att titta närmare på dess struktur. Definitionen av klassen BeeperPickingKarel består av raden som börjar med public class och omfattar allt mellan klammern i slutet av den raden och klammern i sista programraden. Raden som inleder den nya klassen kallas för definitionens header och koden mellan klamrar kallas för definitionens kropp. I programmering är det ofta hjälpsamt att tänka på en given definition och dess kropp som separata idéer. I vårt exempel har definitionen av BeeperPickingKarel följande form, där hela kroppen har ersatts med en box som Du kan glömma för en stund: public class BeeperPickingKarel extends Karel { klassdefinitionens kropp Header-raden berättar mycket om klassen BeeperPickingKarel, även innan Du har sett vad kroppen innehåller. Det viktigaste nya begreppet i klassens header markeras av ordet extends som används både i Karel och i Java för att markera att den nya klassen är en utvidgning av en befintlig klass. Här säger klassheadern att BeeperPickingKarel är en utvidgning av standardklassen Karel som importeras från stanford.karel-biblioteket. När vi i objektorienterade språk definierar en ny klass genom utvidgning betyder det att den nya klassen (här BeeperPickingKarel) bygger på allt som den befintliga klassen (här Karel) erbjuder. I synnerhet garanterar det faktum att den utvidgar Karel att den nya klassen BeeperPickingKarel har följande egenskaper: 5 I Halmstads system finns biblioteket i filen karel.jar som delas ut via kursens hemsida 4

5 1. En instans av BeeperPickingKarel är också en instans av Karel. En instans av Karel representerar en robot som bor i ett värld av gator, avenyer, beepers, och murar. Robotens tillstånd består av dess position, riktning och antal beepers i sin säck. Eftersom BeeperPickingKarel är en utvidgning av Karel vet Du att en instans av BeeperPickingKarel också är en robot som bor i samma typ av värld och har samma tillståndsattribut. 2. En instans av BeeperPickingKarel skall per automatik reagera på samma kommandon som en instans av Karel gör (move(), turnleft(), pickbeeper(), putbeeper()). Med andra ord erhåller den nya klassen BeeperPickingKarel per automatik tillståndsattributen och beteendena hos klassen Karel från vilken den härstammar. Processen att bygga på struktur och beteende hos en moderklass kallas för arv. När en klass definieras med utvidgning kallas den nya klassen för en subklass av moderklassen. I vårt exempel, är BeeperPickingKarel en subklass av Karel. På motsvarande sätt kallas Karel för en superklass till BeeperPickingKarel. Tyvärr kan dessa ord vara förvirrande för nybörjarprogrammerare, som kan ledas att tro att en subklass är på något sätt mindre kraftfull än dess superklass, när det i verkligheten är precis tvärtom. En subklass ärver sin superklass beteende och kan därför reagera på alla kommandon som är tillgängliga för superklassen. En subklass brukar dessutom definiera nya kommandon som inte finns tillgängliga för superklassen. På det sättet har subklassen i vanliga fall mera funktionalitet än superklassen. Detta uttrycks bättre med begreppet utvidgning: en subklass utvidgar sin superklass och kan då lägga till ny funktionalitet till den. Nu när Du har lite grepp på vad klassutvidgning betyder blir det meningsfullt att titta närmare på kroppen i klassen BeeperPickingKarel. Kroppen består av följande rader pickbeeper(); Dessa rader står för en ny metod-definition, som beskriver följden av steg som behövs för att utföra metoden. Precis som i fallet med själva klassen BeeperPickingKarel, består metodens definition av två delar som kan betraktas var för sig. Första raden är metodens header och koden mellan klamrar är metodens kropp. Om Du bortser från kroppen, ser metodens definition så här: metod definitionens kropp De första två orden i headern, public och void, är en del av Javas syntaktiska struktur, och Du kan mycket väl välja att ignorera dem för tillfället. Nästa ord är den nya metodens namn. Med en metoddefinition menar man att instanser av den nya Karel-subklassen kan reagera på ett nytt kommando med det namnet. Klassen Karel svarar på metoderna move(), turnleft(), pickbeeper() och putbeeper; en BeeperPickingKarel svarar även på run(). Kommandot run() spelar en speciell roll i ett Karelprogram. När man startar ett Karelprogram genom java -classpath.:karel.jar BeeperPickingKarel så öppnas ett fönster som i Figur 2. Man trycker sedan på knappen Start Program. Då skapas det en instans av BeeperPickingKarel som placeras i världen och sedan anropas dess run() kommando. Effekten av att anropa run() definieras av kroppen av kommandotrun(); en följd av kommandon som roboten skall utföra i tur och ordning. I Figur 3 ser Du resultatet av att BeeperPickingKarel utför kommandot run() med start enligt tillståndet i Before. Att lösa ett intressantare problem Klassen BeeperPickingKarel definierad i Figur 1 gör inte så värst mycket. Låt oss försöka med något lite mer intressant. Säg att målet är att få Karel att plocka upp beepern och förflytta den från dess startposition i korsningen mellan andra avenyn och första gatan till 5

6 Figur 2: Gränsnittet till BeeperPickingKarel Figur 3: Före-och-efter diagram 6

7 Figur 4: Före-och-efter diagram för beeperforslande Karel Figur 5: Mot nord femte avenyn och andra gatan. Du skall alltså programmera en ny Karel-subklass som åstadkommer det som visas i diagram i Figur 4 De tre första kommandona i det nya programmet de som flyttar Karel framåt, plockar upp beepern och flyttar Karel fram till hyllan är samma som tidigare: pickbeeper(); Härifrån gäller det att vända åt vänster och klättra upp till hyllan. Detta är enkelt eftersom Karel har ett kommando turnleft() i sin repertoar. Att utföra turnleft() efter de föregående kommandona lämnar Karel vänd mot nord, fortfarande i korsningen mellan tredje avenyn och första gatan. Om Karel utför ett move() kommando skall han flytta sig ett steg mot nord. Du ser resultatet av detta i Figur 5. Härifrån skall Karel vända sig åt höger för att återigen vara vänd mot öst. Medan detta kan verka lika enkelt som att vända sig åt vänster, så finns det ett problem: Karels språk innehåller ett turnleft() kommando, men inget turnright() kommando. Det är som om Du har köpt en billig variant och upptäcker nu att den saknar viktiga funktioner. Här har Du ditt första tillfälle att börja tänka som en programmerare. Du har ett antal kommandon, men inte exakt vad Du behöver. Vad kan Du göra? Kan Du åstadkomma effekten av en turnright() med de möjligheter Du har? Svaret är förstås JA. Du kan åstadkomma effekten av att vända åt höger genom att vända åt vänster tre gånger. Efter tre vändningar kommer Karel att vara riktad åt rätt håll. Efter detta måste Du bara programmera Karel för att flytta sig till mitten av hyllan, lämna beepern där och flytta sig ytterligare ett kvarter. En fullständig implementation av BeeperTotingKarel ser Du i Figur 6. Att definiera nya metoder Även om klassen BeeperTotingKarel i Figur 6 visar att det är möjligt att utföra en turnright operation med bara hjälp av Karels inbyggda kommandon, är programmet inte 7

8 /* * File: BeeperTotingKarel.java * * The BeeperTotingKarel class extends the basic Karel class * so that Karel picks up a beeper from 1st Street and then * carries that beeper to the center of a ledge on 2nd Street. import stanford.karel.*; public class BeeperTotingKarel extends Karel { pickbeeper(); Figur 6: Program för att forsla en beeper till mitten på hyllan 8

9 särskilt uppenbart begreppsmässigt. I din mentala bild av programmets konstruktion, vänder Karel sig åt höger när den når hyllans topp. Det faktum att Du måste använda tre turnleft() kommandon är irriterande. Det vore mycket enklare om man kunde säga turnright() och att Karel skulle förstå detta. Programmet skulle inte bara bli kortare, men även lättare att läsa. Som tur är, låter Karels programmeringsspråk oss definiera nya kommandon genom att helt enkelt göra nya metoddefinitioner. När som helst när Du ser en följd av Karel-kommandon som gör något användbart så som att vända åt höger kan Du definiera en ny metod som utför denna följd av kommandon. Formatet för att definiera nya metoder är till stor del detsamma som för att definiera metoden run() i föregående exempel. En typisk metoddefinition ser ut så här: private void name() { kommandon som bygger metodens kropp I detta mönster står name för det namn Du väljer för den nya metoden. För att göra definitionen komplett återstår bara att föreskriva följden av kommandon mellan klamrarna. Till exempel kan Du definiera turnright() så här: private void turnright() { På liknande sätt kan Du definiera en metod för att få Karel att vända helt om: private void turnaround() { Det finns en uppenbar skillnad mellan dessa definitioner och definitionen av run som Du ser i Figur 7: metoden run är markerad som public, medan turnright är markerad som private. Skillnaden mellan dessa två markeringar är att offentliga 6 metoder kan anropas från utanför klassen, medan privata metoder inte kan det. Metoden run måste vara offentlig eftersom Karel-miljön måste kunna anropa ett run() kommando för att få saker att hända. I kontrast används turnright bara i annan kod som finns i klassen. Då kan definitionen markeras som privat. Det är god programmeringsvana att hålla definitioner privata när det är möjligt. Anledningen till detta är svår att se så här i början när de program Du skriver är korta. Grundidéen är att klasser så långt som möjligt ska kapsla in information. Detta betyder att klassen inte bara samlar information, den begränsar även tillgången till den. Stora program blir snabbt komplexa i termer av hur mycket detaljer de inbegriper. Om en klass är välkonstruerad, skall den försöka minska komplexiteten genom att gömma så mycket detaljer som den kan. Denna egenskap kallas för information hiding och är en grundbult i det objektorienterat tankesättet. Så här långt i dina programmeringsstudier kan Du tycka att dessa argument för inkapsling inte verkar så övertygande. Att definiera turnright och turnaround i varje program är lite plågsamt, särskild med tanke på att de är så användbara. Svårigheten i att göra dem mer tillgängliga ligger dock i att lista ut var man skall lägga definitionerna. Att markera definitionen av turnright som offentlig i klassen BeeperTotingKarel skulle inte hjälpa särskilt mycket. I ett objektorienterat programmeringsspråk kapslas de metoder som beskriver klassens beteende in i den klassen. Metoden turnright som finns i klassen vet hur man gör för att vända en instans av BeeperTotingKarel 90 grader åt höger, men den metoden kan inte tillämpas på en instans av klassen Karel eller någon av dess subklasser. I någon mening vill man lägga till turnright och turnaround till klassen Karel så att alla subklasser har tillgång till dem. Problemet med denna strategi är att Du inte nödvändigtvis har tillgång till klassen Karel, som är nödvändig om Du vill göra ändringar. Klassen Karel är en del av en bibliotek 6 public 9

10 /* * File: BeeperTotingKarel.java * * The BeeperTotingKarel class extends the basic Karel class * so that Karel picks up a beeper from 1st Street and then * carries that beeper to the center of a ledge on 2nd Street. import stanford.karel.*; public class BeeperTotingKarel extends Karel { pickbeeper(); /** * Turns Karel 90 degrees to the right. private void turnright() { Figur 7: Reviderad version av programmet för att forsla en beeper, med metoden turnright 10

11 i Stanford University som används i flera kurser där. Om Du gör ändringar i den kan Du göra så att andras program förstörs. På samma sätt, om Du längre in i kursen upptäcker att Du skull vilja lägga till funktionalitet till några av Javas standardklasser, skulle Du inte ha möjlighet till det eftersom dessa klasser tillhör Sun Microsystems. Det Du kan göra dock är att definiera en ny klass som har den nya funktionaliteten. Så om Du vill kunna använda turnright och turnaround i flera Karel-program skulle Du kunna definiera en ny klass som innehåller dessa metoddefinitioner och sedan skapa dina program genom att utvidga denna klass. Denna teknik illustreras i Figur 8 som består av två programfiler. Den första innehåller en klass definitions kallad NewImprovedKarel som har definitioner för turnright och turnaround som offentliga metoder så att andra klasser kan använda dem. Den andra är ytterligare en version av BeeperTotingKarel som utvidgar NewImprovedKarel och därför har tillgång till de nya metoderna. Paketet stanford.karel innehåller inte klassen NewImprovedKarel som den visas i Figur 8 men den har en klass SuperKarel som har metoderna turnright och turnaround samt ett antal andra som gör det möjligt för Dig att skriva mer intressanta program. I följande exempel utvidgas klassen SuperKarel för att ha tillgång till alla metoder. Andra delar av utvidgningen beskrivs i Kapitel 6. Nedbrytning Som ett sätt att visa mera av den kraft som följer med att kunna definiera nya metoder är det nyttigt att få Karel att göra något litet mer praktiskt än att frakta en beeper från en position till en annan. Vägbanorna kring Palo Alto är ofta i behov av reparation och det kan vara kul att se om Karel kan fylla i groparna i sin abstrakt värld. Till exempel, föreställ dig att Karel står på vägensom visas i vänstra delen av diagrammet i Figur 9, en korsning till vänster om en grop i vägen. Karel s jobb är att fylla gropen med en beeper och fortsätta mot nästa korsning. Diagrammet till höger i Figur 9 visar hur världen skall se ut efter programmet körts. Om Du är begränsad till de fyra fördefinierade kommandon skulle metoden run se ut så här: Du kan dock göra huvudprogrammet lättare att läsa genom att utvidga SuperKarel och använda metoderna turnright och turnaround. Detta visas i Figur 10. Vår första motivering för att definiera metoden turnright var att det var krångligt att upprepa tre turnleft() kommandon för att åstadkomma en vändning åt höger. Men att kunna definiera metoder har ett annat viktigt syfte, det öppnar upp för en av de viktigaste strategierna inom programmering processen att bryta ner ett stort problem i mindre bitar som är enklare att lösa. Denna process som bryter ner ett program i mindre bitar kallas för nedbrytning 7, och de delar av problemet kallas för delproblem 8. 7 decomposition 8 subproblems 11

12 /* * File: NewImprovedKarel.java * * The NewImprovedKarel class extends the basic Karel class * so that any subclasses have access to the turnright and * turnaround methods. It does not define any run method * of its own. import stanford.karel.*; public class NewImprovedKarel extends Karel { /** * Turns Karel 90 degrees to the right. public void turnright() { /** * Turns Karel around 180 degrees. public void turnaround() { /* * File: BeeperTotingKarel.java * * The BeeperTotingKarel class extends the basic Karel class * so that Karel picks up a beeper from 1st Street and then * carries that beeper to the center of a ledge on 2nd Street. import stanford.karel.*; public class BeeperTotingKarel extends NewImprovedKarel { pickbeeper(); 12 Figur 8: Förbättrad Karel samt ny version av forslande Karel

13 Figur 9: Gropfyllning /* * File: PotholeFillingKarel.java * * The PotholeFillingKarel class puts a beeper into a pothole * on 2nd Avenue. This version of the program uses no * decomposition other than turnright and turnaround, * which are inherited from SuperKarel. import stanford.karel.*; public class PotholeFillingKarel extends SuperKarel { turnaround(); Figur 10: Karel-program för att fylla i en enda grop 13

14 Till exempel kan problemet att fylla i en grop i vägen brytas ner i följande delproblem: 1. Flytta till gropen 2. Fyll gropen genom att lämna en beeper där 3. Flytta till nästa korsning Om Du tänker på problemet på det här viset kan Du använda metoddefinitioner för att programmet skall spegla din uppfattning av programstrukturen. Metoden run skulle kunna se ut så här: fillpothole(); Sambandet med nedbrytningen är uppenbar och allt skulle vara toppen om bara Karel förstod vad Du menar med med fillpothole(). Givet att vi kan definiera metoder är det enkelt att implementera fillpothole: private void fillpothole() { turnaround(); Det fullständiga programmet visas i Figur 11. Att välja rätt nedbrytning Du skulle kunna ha försökt med andra nedbrytningstrategier. Till exempel skulle Du kunnat skriva programmet så: approachandfillpothole(); där metoden approachandfillpothole helt enkelt är private void approachandfillpothole() { turnaround(); 14

15 /* * File: PotholeFillingKarel.java * * The PotholeFillingKarel class puts a beeper into a pothole * on 2nd Avenue. This version of the program decomposes * the problem so that it makes use of a fillpothole method. import stanford.karel.*; public class PotholeFillingKarel extends SuperKarel { fillpothole(); /** * Fills the pothole beneath Karel s current position by * placing a beeper on that corner. For this method to * work correctly, Karel must be facing east immediately * above the pothole. When execution is complete, Karel * will have returned to the same square and will again * be facing east. private void fillpothole() { turnaround(); Figur 11: Karel program för att fylla i en grop med metod fillpothole 15

16 Eller så skulle Du kunnat skriva programmet så här: fillpotholeyouarestandingin(); turnaround(); där kroppen för fillpotholeyouarestandingin är bara ett putbeeper() kommando. Vart och et av dessa program motsvarar en möjlig nedbrytning. Vart och ett löser problemet. Givet att alla versioner av programmet fungerar, vad är det som gör ett val av brytning problemet bättre än en annan? Det är i allmänhet svårt att välja hur man bryter ner ett program. Faktum är att ju mer komplexa problemen blir, desto kommer valet av lämplig nedbrytning att bli en av de svåraste delarna av programmeringen. Du kan ändå förlita dig till följande riktlinjer 1. Varje delproblem bör utföra en begreppsmässig enkel uppgift. Lösningen till ett delproblem kan kräva många kommandon och kan vara ganska komplex i termer av sin interna struktur. Även i dessa fall bör den åstadkomma någon konceptuell uppgift som i sig är enkel att beskriva. Ett gott tecken på om Du har lyckats med att hitta en rimlig uppgift kommer från det namn Du ger din metod. Om Du kan ganska exakt definiera dess effekt med hjälp av ett enkelt beskrivande namn har Du troligen valt en bra nedbrytning. Å andra sidan, om Du kommer på svåra namn som approachandfillpothole, är nedbrytningen troligen inte så lovande. 2. Varje delproblem bör utföra en uppgift som är så allmän som möjligt så att den kan användas i flera sammanhang. Om en nedbrytning leder till ett program som bara kan användas i exakt den situation som är för handen och en annan skulle fungera lika bra i ett antal situationer, Du bör troligen välja den mer generella. Kapitel 3: Styrsatser i Karel Tekniken att definiera metoder hur användbar den än är möjliggör inte att Karel löser några nya problem. Eftersom varje metodnamn bara är en förkortning för en specifik följd av kommandon, är det alltid möjligt att expandera ett program skrivet som en följd av metodanrop till ett enda huvudprogram som utför samma uppgift, fast programmet blir längre och svårare att läsa. Komandon oavsett om de är skrivna som ett enda program eller uppdelade i metoder exekveras fortfarande i en bestämd ordning som inte är beroende av tillståndet i Karel s värld. Innan Du kan lösa mer utmanande problem måste Du upptäcka hur man skriver program där denna strikt linjära, stegvisa ordning av operationer inte tillämpas. I synnerhet måste Du lära dig nya delar av Karels programmeringsspråk som gör det möjligt för Karel att undersöka sin värld och kunna ändra exekveringsmönstret därefter. Satser som påverkar ordningen i vilket ett program exekverar kommandon kallas för styrsatser 9. Styrsatser indelas ofta i två kategorier: 1. Villkorssatser 10. Villkorssatser anger att vissa satser i ett program skall utföras bara om ett visst villkor är uppfyll. I Karel anger man villkorlig exekvering med hjälp av en if sats. 2. Upprepningssatser 11. Upprepningssatser anger att vissa satser i ett program bör exekveras upprepade gånger; det bildar det som programmerare brukar kalla en loop. Karel stödjer två olika upprepningssatser: en for-sats som kan användas när man vill upprepa vissa kommandon ett givet antal gånger och en while-sats som kan användas när man vill upprepa en operation tills ett 9 control statements 10 conditional statements 11 iterative statements 16

17 Figur 12: Villkor som Karel kan kolla villkor gäller, uan att man vet hur många upprepningar som krävs. Detta kapitel presenterar var och en av dessa styrsatsformer i samband med problem inom Karels värld som visar på behovet för varje typ av sats. Villkorssatser För att få en uppfattning om var villkorssatser kan vara lämpliga, låt oss återgå till programmet med fillpothole i Kapitel 2. Innan Karel fyller i gropen i metoden fillpothole finns det ett antal villkor Karel skulle vilja kolla. Till exempel skulle Karel vilja kolla om ett annat arbetslag har redan fyllt i gropen, vilket betyder att det redan finns en beeper i den korsningen. I så fall behöver Karel inte lägga dit ytterligare en beeper. För att uttrycka dessa test i ett program Du behöver använda en if sats som ofta har följande format: if (villkorstest) { satser som skall exekveras bara om villkoret är sant Villkorstestet som visas i första raden måste ersättas av en av de tester Karel kan göra på sin omgivning. Resultatet av villkorstestet är antingen sant eller falskt. Om resultatet är sant utför Karel satserna mellan klamrarna; om resultatet är falskt gör Karel ingenting. De tester Karel kan göra visas i Figur 12. Observera att varje test har ett par tomma parenteser, som används i Karels programmeringsspråk för att visa att testet anropas. Observera också att varje villkor har en motsats. Till exempel så kan Du använda frontisclear för att kolla om vägen framför Karel är fri eller så kan Du använda frontisblocked för att kolla om det finns en mur som blockerar vägen. Villkoret frontisclear är sant när frontisblocked är falskt och vice versa. Att välja rätt villkor i dina program kräver att Du tänker på problemets logik och ser vilket villkor som är lättast att tillämpa. Du kan använda en if-sats för att ändra definitionen av metoden fillpothole så att Karel lägger en beeper bara om det inte redan finns en beeper i korsningen. För att göra detta villkorstest behöver Du testet nobeeperspresent. Om det inte finns någon beeper i korsningen bör Karel lägga dit en beeper; om det redan finns en beeper där bör Karel inte göra någonting. Den nya definitionen av fillpothole ser ut så här: private void fillpothole() { if (nobeeperspresent()) { turnaround(); 17

18 If satsen i detta exempel har flera kännetecken som är gemensamma för alla styrsatser i Karel. Styrsatsen börjar med en header, som anger typen av styrsats tillsammans med den extra information som behövs för att kontrollera programmets flöde. I exemplets fall är headern if (nobeeperspresent()) som visar att de satser som finns mellan klamrar skall utföras bara om testet av nobeeperspresent ger resultatet sant. Satserna inom klamrarna utgör styrsatsens kropp. Programmerare brukar skriva kroppen av en styrsats lite indragen i förhållande till headern. Indragningen gör det lättare att se vilka satser som påverkas av styrsatsen. Indragningen är extra viktig när kroppen av en styrsats innehåller andra styrsatser. Till exempel kan Du vilja göra ett extra test för att se om Karel har några beepers innan den ens försöker lägga ner en beeper. För att göra detta är allt Du behöver göra är att lägga till en extra if sats inom den befintliga, så här: if (nobeeperspresent()) { if (beepersinbag()) { I detta exempel utförs kommandot putbeeper() bara om det inte finns någon beeper i korsningen och Karel har beepers i sin säck. Styrsatser som förekommer inne i andra styrsatser kallas för nästlade. Utfallet av ett beslut i ett program behöver inte alltid vara att göra ingenting eller att utföra ett antal operationer. I vissa fall kan Du behöva välja mellan två alternativa tillvägagångssätt. För dessa fall har Karel en utökad variant av if satsen som ser ut så här: if (villkorstest) { satser som skall exekveras bara om villkoret är sant else { satser som skall exekveras bara om villkoret är falskt Denna form av if satsen illustreras av metoden invertbeeperstate som plockar upp en beeper om det finns en och lägger ner en beeper om korsningen är tom: private void invertbeeperstate() { if (beeperspresent()) { pickbeeper(); else { Upprepningssatser När Du löser Karel-problem kommer Du att märka att upprepning är en nödvändig del av din lösning. Om Du skulle programmera en robot som fyller i gropar skulle det inte vara så användbart att få den att fylla i bara en grop. Värdet i att använda en robot för sådana uppgifter kommer från att en roboten kan användas för att upprepade gånger fylla i grop efter grop. För att se hur upprepning kan användas i samband med ett programmeringsproblem, tänk på följande stiliserade väg där groparna är jämnt utsprida längst första gatan vid varje jämnt numrerade aveny: 18

19 Din uppgift är att skriva ett program som instruerar Karel att fylla i alla gropar längs denna väg. Observera att vägen tar slut vid den elfte avenyn, som betyder att Du vet exakt hur många gropar skall fyllas. Eftersom Du vet att det finns exakt 5 gropar är styrsatsen Du behöver en for sats, som anger att Du vill upprepa en operation ett i förväg bestämt antal gånger. Strukturen hos en for-sats verkar lite komplicerad eftersom den är mycket mer kraftfull än det som Karel behöver. Den enda version av for-syntaxen som Karel använder är for (int i = 0; i < count ; i++) { satser som måste upprepas där count är ett heltal som anger antal upprepningar. Till exempel, om Du vill ändra fillpothole programmet så att det löser det mer komplexa problemet att fylla i 5 jämnt fördelade gropar, är allt Du måste göra att ändra run metoden enligt: for (int i = 0; i < 5; i++) { fillpothole(); For-satsen är användbar bara när Du vet i förväg antalet upprepningar Du måste göra. I de flesta tillämpningar styrs antalet upprepningar av problemets natur. Till exempel är det inte troligt att den gropfyllande roboten alltid kan räkna med att det finns 5 gropar. Det vore mycket bättre om Karel kunde fortsätta att fylla i gropar tills den möter ett villkor som får den att sluta, som till exempel att komma till gatans slut. Ett sådant program skulle var mycket mer generellt och kunnat tillämpas på flera världar där groparna är jämnfördelade, så som För att skriva ett generellt program som fungerar i alla dessa världar, behöver Du använda en while sats. I Karel har en while sats följande form: while (test) { satser som skall upprepas Testet i headern väljs från villkoren som visas i Figur 12. I detta fall Karel måste kolla om vägen framför är fri genom att använda villkoret frontisclear. Om Du använder villkoret frontisclear i 19

20 en while-loop, kommer Karel att utföra loopen tills den når en mur. While-satsen gör det då möjligt att lösa det mer generella problemet för att laga vägen, så längre groparna förekommer vid alla jämnt numrerade avenyer och vägens slut är given av en mur. Klassen RoadRepairKarel som åstadkommer detta visas i Figur 13. Att lösa generella problem Hittills har de olika groplagningsprogrammen inte varit så realistiska för att de kräver vissa specifika villkor som till exempel jämnt fördelade gropar som troligen inte gäller i verkligheten. Om Du vill skriva ett mer generellt program som fyller gropar borde det fungera med färre restriktioner. Speciellt: Programmet bör fungera med vägar av godtycklig längd. Dessa program behöver ändå kunna veta när vägen tar slut. Groparna skall kunna förekomma i godtyckliga positioner längs vägen. Det skall inte finns några begränsningar vad gäller antalet gropar eller hur de är fördelade. En grop känns igen som en öppning i den mur som beskriver vägens yta. Befintliga gropar skall redan kunna vara lagade. Några gropar kan redan innehålla en beeper lämnad av ett tidigare arbetslag. I sådana fall bör Karel inte lämna ytterligare en beeper. För att ändra programmet så att det löser det mer generella problemet måste Du tänka nytt. Istället för att ha en loop i huvudprogrammet genom varje grop, behöver Du att Karel kollar varje korsning medan den går framåt. Om det finns en öppning vid en korsning bör Karel försöka fylla i gropen. Om det finns en mur kan Karel helt enkelt fortsätta till nästa korsing. Denna analys leder till att det generaliserade programmet bara KRÄVER en ändring i run metoden från Figur 13 while (frontisclear()) { if (rightisclear()) { fillpothole(); Men, som insekten vid koden antyder, är detta program inte riktigt rätt. Den innehåller ett logiskt fel den sort somprogrammerare brukar kalla för bugg. Buggen i detta exempel är ganska subtil och lätt att missa, trots att Du har testat programmet. Till exempel fungerar programmet rätt i följande värld, så som det visas i före-och-efter diagrammet 20

21 /* * File: RoadRepairKarel.java * * The RoadRepairKarel class fills a series of regularly * spaced potholes until it reaches the end of the roadway. import stanford.karel.*; public class RoadRepairKarel extends SuperKarel { while (frontisclear()) { fillpothole(); /** * Fills the hole beneath Karel s current position by * placing a beeper in the hole. For this method to * work correctly, Karel must be facing east immediately * above the hole. When execution is complete, Karel * will have returned to the same square and will again * be facing east. This version of fillpothole checks to * see if there is already a beeper present before putting * a new one down. private void fillpothole() { if (nobeeperspresent()) { turnaround(); Figur 13: Program för att laga en väg 21

22 I detta exempel verkar allt rätt. Om man låter bli att testa programmet vidare, skulle Du aldrig lägga märke till att om Du ändrar världen så att det finns en grop i sjunde avenyn så gör inte programmet rätt. I detta fall ser före-och-efter diagrammet ut så här: Karel slutar utan att fylla i sista gropen. Om Du kollar noggrant vad programmet gör, kommer Du att märka att Karel inte ens går ner i gropen för att kolla om den behöver fyllas. Vad är problemet? Om Du följer programmets logik kommer du att upptäcka att buggen finns i loopen inne i run metoden som ser ut så här: while (frontisclear()) { if (rightisclear()) { fillpothole(); Så fort Karel fyller i gropen i sjätte avenyn gör den ett move()-kommando och är tillbaka i headern på while-loopen. Då står Karel i korsningen mellan sjunde avenyn och andra gatan, där den är blockerad av gränsmuren. Eftersom frontisclear-testet ger falskt avslutas while-loopen utan att kolla sista segmentet längs vägen. Buggen i detta program är ett exempel på ett programmeringsproblem som kallas för staketstolpsfelet. Namnet kommer från det faktum att det tar en stolpe mer än det Du först tänker på för att inhägna ett visst avstånd. Hur många stolpar behöver Du, till exempel, för att bygga ett 100 meter långt staket om stolparna skall vara på 10 meters avstånd? Svaret är 11 som Du ser i följande diagram: Situationen i Karels världs har samma struktur. För att fylla i gropar längs en väg som har sju korsningar måste Karel kolla sju gropar men behöver flyttas bara sex gånger. Eftersom Karel börjar och slutar vid en gräns behöver den utföra ett move()-kommando mindre än antalet korsningar den måste kolla. När vi har väl upptäckt det, är det inte svårt att fixa felet. Innan Karel avslutar vid vägens slut, är allt som programmet måste göra att utföra ett extra test för en grop i sista korsningen, så som visas i Figur

23 /* * File: RoadRepairKarel.java * * This version of the RoadRepairKarel class fills an * arbitrary sequence of potholes in a roadway. import stanford.karel.*; public class RoadRepairKarel extends SuperKarel { while (frontisclear()) { checkforpothole(); checkforpothole(); /** * Checks for a pothole immediately beneath Karel s current * looking for a wall to the right. If a pothole exists, * Karel calls fillpothole to repair it. private void checkforpothole() { if (rightisclear()) { fillpothole(); /** * Fills the pothole beneath Karel s current position by * placing a beeper on that corner. For this method to * work correctly, Karel must be facing east immediately * above the pothole. When execution is complete, Karel * will have returned to the same square and will again * be facing east. This version of fillpothole checks to * see if there is already a beeper present before putting * a new one down. private void fillpothole() { if (nobeeperspresent()) { turnaround(); Figur 14: Program för att fylla i ojämnt sprida gropar 23

24 Kapitel 4: Stegvis förfining Vi kommer att diskutera det som presenteras här under kursens gång i samband med Java. Kapitel 5: Algoritmer Vi kommer att diskutera det som presenteras här under kursens gång i samband med Java. Kapitel 6: SuperKarel Så som den kommer från fabriken ligger Karel lite på den tråkiga sidan. Världen som speglar hårdvaran på den tid då Karel uppfanns är helt i svartvit. Mer än så, Karel uppträder alltid på ett deterministiskt sätt. Båda dessa saker gör det svårt att programmera Karel för att göra mer spännande saker. För att förenkla detta innehåller paketet stanford.karel en SuperKarel som har flera nya funktioner. Metoderna turnright och turnaround Som Du redan vet från Kapitel 2 innehåller klassen SuperKarel definitioner för turnright och turnaround. Även om det är lätt att definiera dem, kan det vara obekvämt att göra det i varje Karel-program. Och dessutom, SuperKarels implementation utnyttjar Karels interna metoder för att implementera dessa operationer på ett mer effektivt sätt. Om Du använder turnright i en klass som utvidgar SuperKarel kommer ditt program att göra en direkt höger vändning och inte gå genom processen att vända vänster tre gånger. Att använda färg Klassen SuperKarel låter Karel måla den korsning den står på genom instruktionen paintcorner(color); Värdet inom parenteserna som kallas för ett argument i programmeringsspråksterminologi kan vara en av följande Färgen null står för att korsningen inte har någon färg, vilket betyder att det lilla korset i mitten syns igenom. När Du skapar en ny Karel-värld har alla korsningar färgen null. SuperKarel förstår också ett nytt villkor cornercoloris(color), som är sant om den korsning som Karel står på har färgats med färgen color. Till exempel, Du skulle kunna färja Karels hörna röd med paintcorner(red); och sedan kan man utföra några kommandon bara i röda korsningar med if (cornercoloris(red)) { Satser som skall göras bara om korsningen är färgad röd 24

25 Slumpmässigt beteende SuperKarel definierar också ett nytt villkor random, som är sant hälften av tiden, men på ett oförutsägbart sätt. Till exempel, om Du exekverar följande satser if (random()) { paintcorner(yellow); else { paintcorner(magenta); Karel skall färga korsningen gul eller magenta, båda med lika sannolikhet. Om Du behöver större kontroll över hur ofta Karel utför en slumpartad händelse, kan randomvillkoret ta ett argument som är ett tal som anger sannolikheten för villkoret att vara sant. Såsom i statistik är sannolikheter tal mellan 0.0 och 1.0, där 0.0 anger att villkoret alltid ska vara falskt och 1.0 att det alltid ska vara sant. Om till exempel Du skulle vilja att Karel lägger ner en beeper 25% av tiden skulle Du kunna skriva if (random(0.25)) { Logiska operationer Allt eftersom Du skriver mer avancerade Karel-program kommer Du att upptäcka att det kan vara svårt att uttrycka vissa villkor när Du på svenska använder konnektiv som och och eller. Som ett exempel, försök skriva ett Karel while-sats som flyttar Karel tills den antingen blir blockerad av en mur eller finner en beeper. För att göra det enklare att skriva intressanta program tillåter Karel-språket användning av logiska operationer. Dessa är faktiskt en del av programmeringsspråket Java och inte en SuperKarel-utvidgning: && Motsvarar svenska ordet och. Motsvarar svenska ordet eller.! Motsvarar svenska ordet icke. Med dessa operationer är det lätt att skriva den föreslagna while satsen: while (frontisclear() && nobeeperspresent()) { 25

26 Appendix A: Karel Reference Card Hela Karel-språket på en sida. 26