| ... | ... | @@ -6,16 +6,14 @@ En del vanlige feil lar seg best avsløre med testing. |
|
|
|
|
|
|
|
* Det er vanlig å gjøre feil i implementasjonen av add() i GameMap (når man skal legge til sortering), så denne er det lurt å teste grunding. Du må ikke bare teste at tingene ligger i sortert rekkefølge, men også at add() faktisk legger til ting (og bare legger dem til én gang). Se eksempler på dette i [koden fra forelesning 13. mars](https://retting.ii.uib.no/inf101.v19.oppgaver/inf101.v19.sem1/blob/forelesning-13-3/src/inf101/v19/rogue101/tests/GameMapTest.java).
|
|
|
|
|
|
|
|
* Siden vi har rotet til attack()-metoden i Game, er det kanskje lurt å lage tester også for denne, slik at vi kan både oppdage feilen og være rimelig sikker på at den er fikset. Du kan se [eksempel på dette her](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/blob/forelesning-13-3/src/inf101/v18/rogue101/tests/GameTest.java) (har fikset litt på testen, slik at den nå ikke er avhengig av å ha en Player og at Player har implementert angrep riktig – i stedet har den to kaniner og kaller attack() direkte)
|
|
|
|
* Siden vi har rotet til attack()-metoden i Game, er det kanskje lurt å lage tester også for denne, slik at vi kan både oppdage feilen og være rimelig sikker på at den er fikset. Du kan se [eksempel på dette her](https://retting.ii.uib.no/inf101.v19.oppgaver/inf101.v19.sem1/blob/forelesning-13-3/src/inf101/v19/rogue101/tests/GameTest.java) (har fikset litt på testen, slik at den nå ikke er avhengig av å ha en Player og at Player har implementert angrep riktig – i stedet har den to kaniner og kaller attack() direkte)
|
|
|
|
|
|
|
|
* Vi har også vist på forelesningen [litt kode for å teste om en Player faktisk angriper](https://retting.ii.uib.no/inf101.v19.oppgaver/inf101.v18.sem1/blob/forelesning-13-3/src/inf101/v18/rogue101/tests/PlayerTest.java); dette er litt tricky (med mindre vi kan være *helt* sikker på at angrepet alltid lykkes) så eksempelkoden krever at vi legger til litt ting i [Game](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/blob/forelesning-13-3/src/inf101/v18/rogue101/game/Game.java) / [IGame](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/blob/forelesning-13-3/src/inf101/v18/rogue101/game/IGame.java) slik at det går an å sjekke siste beskjeden som ble vist på skjermen / evt. siste tingen som ble gjort.
|
|
|
|
* Vi har også vist på forelesningen [litt kode for å teste om en Player faktisk angriper](https://retting.ii.uib.no/inf101.v19.oppgaver/inf101.v19.sem1/blob/forelesning-13-3/src/inf101/v19/rogue101/tests/PlayerTest.java); dette er litt tricky (med mindre vi kan være *helt* sikker på at angrepet alltid lykkes) så eksempelkoden krever at vi legger til litt ting i [Game](https://retting.ii.uib.no/inf101.v19.oppgaver/inf101.v19.sem1/blob/forelesning-13-3/src/inf101/v19/rogue101/game/Game.java) / [IGame](https://retting.ii.uib.no/inf101.v19.oppgaver/inf101.v19.sem1/blob/forelesning-13-3/src/inf101/v19/rogue101/game/IGame.java) slik at det går an å sjekke siste beskjeden som ble vist på skjermen / evt. siste tingen som ble gjort.
|
|
|
|
|
|
|
|
~~Du *kan* prøve å flette det vi gjorde på forelesningen inn i ditt eget prosjekt, men det er fare for at du vil få konflikter om du har gjort mange endringer i de samme filene selv. I såfall går du til [forsiden for upstream-utgaven av sem1-prosjektet](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1), klikker “New Merge Request" som før, og fyller inn grenen "forelesning-13-3" på venstre side og "*BRUKERNAVN*/inf101.v18.sem1" "master" til høyre:~~ (Dette går visst ikke an å gjøre på denne måten! Burde funke å gjøre noe liknende til [hva vi har foreslått](https://retting.ii.uib.no/inf101/inf101.v18/wikis/kode-fra-forelesninger#oppsett) for å følge med på forelesningene, bare med `inf101.v18.oppgaver/inf101.v18.sem1` i stedet for `inf101/inf101.v18`)
|
|
|
|
|
|
|
|
## API-utvikling / finne gulrøtter på kartet (fra forelesning 15. mars)
|
|
|
|
## API-utvikling / finne gulrøtter på kartet
|
|
|
|
|
|
|
|
### Bakgrunn – API
|
|
|
|
* *API (Application Programming Interface):* Et API beskriver hvordan du bruker en programkomponent (en klasse/interface, en pakker, et programbibliotek) – hvilke objekter du lager, hvilke metoder du kaller, hvilke typer du bruker på variablene dine. Det er vanlig å bruke ordet på ting av forskjellige størrelser: “JavaSE-APIet” vil være tusenvis av klasser og metoder som følger med den vanlige utgaven av Java (det finnes også en “Enterprise Edition (EE)”, og mindre varianter for mobile enheter og slikt) – altså det du som Java-programmør forholder deg til når du skriver Java-kode. “Collections APIet” er et lite subsett av dette. På samme måte kan vi snakke om “grid-APIet i semesteroppgaven” (alle tingene i `inf101.v18.grid`-pakken, inkludert location og area og slikt), eller “map view APIet” (metodene som er definert i `IMapView` i semesteroppgaven).
|
|
|
|
* *API (Application Programming Interface):* Et API beskriver hvordan du bruker en programkomponent (en klasse/interface, en pakker, et programbibliotek) – hvilke objekter du lager, hvilke metoder du kaller, hvilke typer du bruker på variablene dine. Det er vanlig å bruke ordet på ting av forskjellige størrelser: “JavaSE-APIet” vil være tusenvis av klasser og metoder som følger med den vanlige utgaven av Java (det finnes også en “Enterprise Edition (EE)”, og mindre varianter for mobile enheter og slikt) – altså det du som Java-programmør forholder deg til når du skriver Java-kode. “Collections APIet” er et lite subsett av dette. På samme måte kan vi snakke om “grid-APIet i semesteroppgaven” (alle tingene i `inf101.v19.grid`-pakken, inkludert location og area og slikt), eller “map view APIet” (metodene som er definert i `IMapView` i semesteroppgaven).
|
|
|
|
* *Grensesnitt:* Et API er et grensesnitt (i bred forstand) – et sett med regler for hvordan du bruker/interagerer med noe. Et Java `interface` definierer et API (det er ikke tilfeldig at ordet *interface* dukker opp både i `interface` og i *Application Programming Interface*), men et API trenger ikke nødvendigvis bestå av Java `interface`s (eller bestå av metoder, eller gjøre bruk av Java i det hele tatt).
|
|
|
|
* *Mer innkapsling:* Vi har tidligere sett at innkapsling av objekter er sentralt – som “bruker” av et objekt forholder du deg bare til et sett av metoder (grensesnittet / APIet til objektet, som forhåpentligvis er relativt godt dokumentert), uten å vite om implementasjonen (hvilke feltvariabler objektet har, hvordan metodene er implementert). Samme skillet mellom grensesnitt (hvordan du bruker ting) og implementasjon (hvordan det virker) vil vi som regel også prøve å opprettholde når vi har større kodeenheter. Så koden som implementerer grid-APIet og grafikk-APIet er innkapslet, slik at vi f.eks. kan endre implementasjonen uten at de som bruker APIet må endre sin kode – og slik at du som bruker APIet ikke trenger å forstå implementasjonsdetaljene.
|
|
|
|
* *Ikke-API kode:* Et programbibliotek kan inneholde ting som strengt tatt ikke er med i APIet – ting som hører til implementasjonsdetaljene, men som likevel kanskje er tilgjengelig for den som bruker APIet. Det er gjerne av tekniske eller praktiske grunner. F.eks. har `Game` en `setCurrent`-metode som ikke er med i `IGame`-grensesnittet. Det er ikke meningen at f.eks. kaninene skal kalle denne metoden (selv om de kan lure seg til å gjøre det hvis de virkelig vil) – men vi trenger den fordi den er praktisk når vi skal lage tester for spillet. Java kommer f.eks. med en haug med klasser som er helt nødvendige men som ikke er del av Java APIet. De har har navn på formen `com.sun.*` (f.eks. ligger implementasjonen av grafikksystemet vi bruker i `com.sun.prism`) og du kan ikke stole på at de er kompatible på tvers av Java-versioner.
|
| ... | ... | @@ -39,15 +37,6 @@ Vi kan tenke oss noen muligheter: |
|
|
|
* En metode `getFirst(loc, Carrot.class)` som finner det første objektet på feltet `loc` som er av klassen `Carrot`. Her bruker vi *klasse-objekter* – `Carrot.class` vil være et objekt som representerer klassen Carrot mens programmet kjører. Alle deler av programkoden til `Carrot.java` er faktisk tilgjengelig her (gjennom et litt kompliset API) – det vi er interessert i er bare metoden `isInstance()` som kan fortelle oss om et objekt er av (eller er kompatibel med) en klasse.
|
|
|
|
* En metode `getFirst(loc, /* predikat som sier om dette er objektet vi leter etter */)` – den mest generelle løsningen, hvor du kan fylle inn din egen kodesnutt (f.eks. et *lambdauttrykk* `(item) -> item instanceof Carrot`) som skal avgjøre om et item er interessant eller ikke.
|
|
|
|
|
|
|
|
Du kan se eksempler på dette på grenen [forelesning-15-3 i inf101.v18.opppgaver/inf101.v18.sem1](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/tree/forelesning-15-3). I tillegg inneholder [IMultiGrid](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/blob/forelesning-15-3/src/inf101/v18/grid/IMultiGrid.java) noen eksempler på predikat/lamdauttrykk. De aktuelle filene er:
|
|
|
|
* [GameMap.java](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/blob/forelesning-15-3/src/inf101/v18/rogue101/map/GameMap.java)
|
|
|
|
* [IMapView.java](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/blob/forelesning-15-3/src/inf101/v18/rogue101/map/IMapView.java)
|
|
|
|
* [IGame.java](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/blob/forelesning-15-3/src/inf101/v18/rogue101/game/IGame.java)
|
|
|
|
* [Game.java](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/blob/forelesning-15-3/src/inf101/v18/rogue101/game/Game.java)
|
|
|
|
* [Rabbit.java](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/blob/forelesning-15-3/src/inf101/v18/rogue101/examples/Rabbit.java)
|
|
|
|
|
|
|
|
Du kan se [alle endringene vi gjorde på forelesningen her](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/commit/7a91baad6dd61496c29c401495465da69f5055dc).
|
|
|
|
|
|
|
|
#### Klasse-objekt
|
|
|
|
Her er et eksempel på bruk av klasse-objekt for å se om det ligger et objekt av en gitt klasse/type på en location. *(Dette er i praksis veldig hendig for å få løst situasjoner som dette, men det er ikke noe vi forventer at du kan på INF101-eksamen.)*
|
|
|
|
|
| ... | ... | @@ -152,6 +141,4 @@ Siden dette er en én-metoders klasse kan vi også bruke lambdauttrykk, og få e |
|
|
|
Collections.sort(list, (a, b) -> Integer.compare(loc.gridDistanceTo(a), loc.gridDistanceTo(b)));
|
|
|
|
```
|
|
|
|
|
|
|
|
Se hele eksemplet i [getNeighbourhood() i GameMap.java](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/blob/forelesning-15-3/src/inf101/v18/rogue101/map/GameMap.java#L303).
|
|
|
|
|
|
|
|
(Du vil se en god del mer av denne måten å programmere på i INF122, hvis du tar det. Det er relativt nytt i Java (bare med i Java 8 og nyere), så det blir gjerne ansett som en “avansert” teknikk, selv om det i praksis gjør ganske mye en del enklere.) |
|
|
\ No newline at end of file |
