Vi vill komma igång snabbt! Otåliga som vi är bestämmer vi oss för att skapa en cirkelklass, utan att tänka så mycket på framtiden eller hur den ska kopplas till övriga formklasser.

1. Tidigare klasser låg i paketet se.liu.ida.dinadress.tddd78.lab2. Högerklicka på paketet tddd78, välj New | Package och skapa lab3. Detta ska hamna på samma nivå som lab1 och lab2 i klassträdet.

2. Skapa klassen Circle i paketet lab3.

3. Lägg till de publika (public!) int-fälten x, y och radius.

4. Lägg till ett publikt fält color av typen java.awt.Color.

   Abstract Window Toolkit (AWT) är Javas ursprungliga grafiksystem. Anledningen till att vi skriver hela java.awt.Color är att det finns många Color-klasser i olika paket och vi vill testa ett alternativt sätt att få fram exakt rätt klass. Om du ställer markören i java.awt.Color så kommer IDEA att visa en glödlampa till vänster. Klicka på den eller tryck Alt+Enter, och välj Replace with import, så kommer IDEA att istället importera klassen och vi kan använda namnet utan att ange paketdelen (java.awt).

5. Skapa en konstruktor som tar in parametrar och tilldelar värden till alla fält.

Vi gör nu ett första test av klassen. Även om vi är otåliga ska detta göras tidigt för att vi inte ska låta eventuella fel få nya följdfel när vi fortsätter programmera.

1. Skapa klassen TestCircle och en main()-metod i den.

2. I main() ska vi skapa en lista av Circle. Skriv new ArrayList<Circle>(), låt IDEA importera ArrayList, och testa IDEAs Extract Variable enligt nedan.

   Info: Extract Variable

   Genom att markera ett uttryck eller stå i en variabel kan man snabbt få IDEA att introducera en variabel som representerar detta. Man gör det med Refactor | Extract | Variable: Ctrl-Alt-V. Det är användbart t.ex. då man vill skapa en variabel snabbt. Anta att vi har skrivit i koden:

      new ArrayList<Circle>()

   Efter att vi trycker Ctrl-Alt-V och väljer namn på variabeln får vi:

      final ArrayList<Circle> circles = new ArrayList<>();

   IDEA har själv hittat på ett variabelnamn, som man givetvis kan byta ut. Notera att "<>" står för "samma typparametrar som tidigare på raden", dvs. "<Circle>".

   Extract Variable är också användbart om man har ett långt uttryck som man vill dela upp, t.ex. en if-sats där villkoret är väldigt långt. Genom att markera en del av den och ta extract variable skapas en variabel som tilldelas värdet av deluttrycket och sedan ersätts detta i if-satsen med variabeln.

3. Skapa ett par cirklar och lägg dem i listan (med listmetoden add()).

4. Använd live-template iter (iterate collection) för att skapa en for-loop som går igenom varje Circle i listan och för varje cirkel skriver ut dess x- och y-koordinater. När man fyller i en live-template kan man använda Tab för att navigera mellan variabler som namnges.

   Notera att iter använder en for-loop-variant som är mer lik Pythons:
   for (Type element : collection), som itererar en gång för varje element i en samling eller array.

5. Kör programmet och verifiera att du får ut rätt utskrifter.

1. Hoppa från TestCircle till Circle genom att använda Navigate | Class: Ctrl-N och skriva "Cir", som expanderas automatiskt när du trycker Enter. Detta är en mycket användbar genväg.

   Eftersom vi redan har en referens till Circle i närheten kan vi även ställa markören i Circle och trycka Ctrl-B för att snabbt hoppa till definitionen. Detta fungerar för alla klasser, metoder och fält, inklusive de från "språkets egna" klasser (t.ex. System).

2. Lägg till följande rader överst i Circle-konstruktorn:

       if (radius < 0) {
           throw new IllegalArgumentException("Negativ radie!");
       }
   

   Detta är en exception, ett undantag. Vi kommer att gå genom mer om exceptions i kursen, men hittills räcker det att veta att denna kod avbryter konstruktorn och signalerar ett fel till anroparen. Eftersom konstruktorn avbröts skapas heller inget cirkelobjekt!

Detta exemplifierar två viktiga programmeringsbegrepp.

• En klass har kontroll över sina objekt. Nu kan ingen skapa en cirkel med negativ radie.

• Defensiv programmering. Vi ska inte tänka att "ingen galning skulle få för sig att ge en negativ radie, så det fallet kan vi ignorera". Man vet aldrig hur radien räknas ut eller vad anroparen har missat att tänka på (eller hur galen någon är, för den delen). Vi tar hand om alla tänkbara och otänkbara fall, så får vi färre svårhittade buggar.

1. I klassen Circle, välj Refactor | Encapsulate Fields. Bocka för alla fält samt avmarkera Set Access och Use accessors even when field is accessible.

1. Skapa gränssnittet Shape i paketet lab3. Som förut högerklickar vi på paketet och väljer New | Java Class, men nu väljer vi Interface i drop-down-menyn som finns i fönstret Create New Class som kommer fram.

2. Nu ska vi se till att Circle implementerar Shape. På class-raden lägger vi därför till implements Shape.

   Eftersom Shape ännu inte har några metoder är detta tillräckligt för tillfället.

1. Lägg till en public metod som heter draw(). Den ska inte ha några inparametrar och inte heller lämna något returvärde (vad skriver man för att indikera detta?). Som alla metoder i gränssnitt ska den också sakna "kodkropp" ({...}).

2. Vi ser att draw() blir gul. Det finns nämligen klasser som säger sig implementera Shape men som saknar denna metod! Motsvarande varning kan ses när man går till Circle: IDEA stryker under "implements Shape" med röd färg.

   Placera markören någonstans i Circle där du vill ha de metoder som krävs för Shape. Tryck Alt+Insert och välj Implement Methods och sedan draw(). Då fyller IDEA i rätt metodbeskrivning.

   För enkelhets skull kommer vi inte att måla ut något än, utan bara skriva ut "innehållet" i de former som ska målas ut. Låt därför metoden skriva ut "Ritar: " + this.

   (Vad är "@Override", som IDEA genererar? Detta är en annotering som visar att detta implementerar eller override:ar en metod som är definierad längre upp i klasshierarkin. Ni får veta mer om detta under en senare föreläsning.)

3. Nu minns vi att standardutskriften för ett objekt inte var särskilt användbar. IDEA varnar till och med för detta genom att "this" blir gul ("Call to default 'toString' on 'this'").

   Använd IDEA för att generera en toString() (Alt+Insert toString()) som innehåller värdet på alla fält.

1. Alternativ 1 av 2: Lägg manuellt till metoddeklarationer för getX(), getY() och getColor() i Shape. Se till att de har samma returvärden och parametrar som i Circle, men saknar metodkropp. Vi kan ju inte implementera en fullständig getX() här uppe i Shape, eftersom gränssnittet själv inte har något x att returnera!

2. Alternativ 2: Gå till Circle. Använd Refactor | Pull Members Up. Se till att Shape är vald i den översta väljaren. Markera getX(), getY() och getColor() i medlemslistan.

   Men vad är det som ska flyttas upp? Om Shape hade varit en klass hade man kunnat välja att flytta hela implementationen av dessa metoder till Shape, om man till exempel ansåg att implementationen skulle vara samma för alla underklasser till Shape. Men nu är Shape ett gränssnitt, som inte ska innehålla någon kod – bara metodsignaturer. Därför är "Make abstract" automatiskt vald. Därmed gör IDEA en metodsignatur i Shape och låter själva implementationen finnas kvar i den ursprungliga klassen. Metoder i gränssnitt är alltid abstrakta == har ingen implementation.

   Vilken ordning metoderna hamnar i kan bero på i vilken ordning man väljer dem i listan!

   

   Välj Refactor. Detta skapar rätt metoddeklarationer i Shape och lägger också automatiskt till @Override på metoderna i Circle.

Nu har vi deklarerat att alla Shape-klasser måste ha dessa metoder.

Vi gör nu ett första test av gränssnittet och klassen tillsammans. Detta gör vi i en ny testklass.

1. Gå till TestCircle. Klona klassen med hjälp av F5. Kalla den nya klassen TestShapes. På det sättet får ni med strukturen i det gamla testprogrammet.

2. I TestShapes.main() ska vi inte skapa en lista av Circle, utan en lista av Shape där vi så småningom även ska kunna lägga in rektanglar och andra former.

   Vi måste också ändra loopen på motsvarande sätt, så att den plockar ut godtyckliga former och inte kräver att få cirklar.

   Variabler bör så klart också döpas om, så vi inte har en lista av former som heter "circles". Ställ markören i ett variabelnamn och välj Refactor | Rename:Shift+F6. Skriv in det nya namnet på variabeln (eller välj ett av förslagen som kommer upp) och tryck enter. IDEA byter automatiskt alla förekomster av variabelnamnet.

3. Nu bör slutet av koden se ut ungefär så här:

   	for (Shape shape : shapes) {
   	    System.out.println(shape.getX() + " " + shape.getY());
   	}

   Men nu har vi ju en riktig "ritmetod", så vi ersätter utskriftsraden med ett anrop till shape.draw().

4. Kör TestShapes och verifiera att du får ut rätt utskrifter. Även det gamla testprogrammet TestCircle ska fortfarande fungera!

Vår nästa form är en rektangel. Även den ska implementera gränssnittet Shape.

1. Skapa klassen Rectangle med de privata fälten x, y, width, height och color. Typerna vet ni sedan tidigare.

   Ge klassen en lämplig konstruktor.

   Skapa en toString()-metod.

2. Implementera gränssnittet Shape och de metoder som krävs i detta gränssnitt.

3. Utöka testprogrammet så det också lägger några rektanglar i listan. Testa.

Vår sista form är en text. Även den ska implementera gränssnittet Shape.

1. Skapa klassen Text med de privata fälten x, y, size (storleken i punkter), color och text (en String) samt en lämplig konstruktor och toString()-metod.

2. Implementera gränssnittet Shape och de metoder som ingår i gränssnittet.

3. Utöka testprogrammet på lämpligt sätt. Testa.

1. Skapa en ny "tom" klass public abstract class AbstractShape. Se till att den implementerar Shape – alla subklasser till AbstractShape ska ju vara Shapes.

2. Byt ut implements Shape mot extends AbstractShape i klasserna Circle, Rectangle och Text. Detta innebär att klasserna blir AbstractShape, men de kommer fortfarande också att vara Shapes eftersom detta gränssnitt implementeras av AbstractShape.

3. Nu är vi redo att flytta ut vissa definitioner till den abstrakta klassen.

   Navigera till Circle och välj Refactor | Pull Members Up. Välj att medlemmar ska dras upp till AbstractShape, inte Shape. Markera fälten x,y,color, som är gemensamma för alla former. Markera även motsvarande getters. Den här gången görs metoderna inte abstrakta: Implementationen ska följa med upp.

   Vi markerar inte radius eller getRadius(), eftersom bara cirklar har radier. Inte heller draw() eller toString(): De ska visserligen finnas i alla former men behöver ha en egen implementation i varje klass.

   Vilken ordning medlemmarna och konstruktorparametrarna hamnar i kan bero på i vilken ordning man väljer dem i listan! Blir det fel kan ni göra "undo" och göra om denna refactoring.

   

   Välj Refactor. IDEA gör nu några ändringar för att koden fortfarande ska fungera.

   1. De valda fälten blir protected i AbstractShape istället för private, så att subklasser fortfarande kan komma åt dem.

   2. IDEA skapar också automatiskt en konstruktor för AbstractShape.

   3. Eftersom fälten nu är flyttade är det upp till AbstractShape att hantera initialisering av dem. Vissa tilldelningar i konstruktorn för Circle ersätts därför med anropet super(x,y,color), som vidarebefordrar parametrarna från Circle upp till AbstractShape:s konstruktor. (Ett anrop till super() ligger alltid först i en konstruktor.)

4. Tyvärr vet inte IDEA att den ska göra motsvarande ändringar i de andra klasserna.

   Navigera till Rectangle. Ta bort fälten x/y/color, ta bort motsvarande getters, och ta bort initialiseringen ur konstruktorn.

   Lägg sedan till super()-anrop motsvarande det i Circle-konstruktorn. Ta bort de tre getter-implementationer som nu blev onödiga eftersom samma kod redan ärvs ner från AbstractShape.

   Gör samma sak för Text.

Som ni märker kan det krävas lite jobb för att hålla koden i god form. Det är lätt hänt att man undviker det, men det förlorar man ofta på i det långa loppet. I projektet kommer vi att ge komplettering för duplicerad kod av den här typen.

Vi vill poängtera att vi inte införde den abstrakta klassen bara för att "spara kod", utan att det faktiskt fanns ett naturligt sammanhang mellan klasserna också: De är olika sorters former.

1. Skapa klassen Queue.

2. Skapa ett privat fält List<Person> elements och initialisera detta till en ny ArrayList<Person>. Eftersom varje Queue har sina egna element får detta fält inte vara statiskt.

3. Det finns metoder i ArrayList som vi vill göra tillgängliga för användaren av Queue. size() är en sådan metod. Eftersom elements håller koll på antalet element den innehåller, skriver vi helt enkelt bara en size()-metod i Queue som returnerar resultatet av elements.size(). Vi delegerar alltså det egentliga arbetet till elements-listan. (IDEA kan hjälpa till – läs vidare!)

   Vi delegerar arbetet till elements även för metoderna isEmpty(), clear() och contains() på precis samma sätt, genom att ha en metod som direkt anropar och returnerar svaret från motsvarande metod i elements.

   Delegering är så pass vanligt att IDEA kan automatisera det åt oss. Genom att välja Code | Delegate Methods och sedan välja elements kan man därefter välja precis vilka metoder man vill delegera.

4. Vi behöver även några "egna" metoder. Lägg till:

   • enqueue(), som tar en person som parameter och lägger till den sist i kön, och
   • dequeue(), som hämtar personen som är först i kön, tar bort den ur kön (listan), och returnerar den.

   Dessa ska använda sig av metoderna elements.add() och elements.remove(int index) för att ta ut första elementet i elements och stoppa in ett element sist i listan.

   Tänk på att t.ex. enqueue ska lägga till ett element i en specifik kö (ett specifikt Queue-objekt), inte i kö-klassen i sin helhet. Metoderna du skriver här ska alltså inte vara statiska.

5. Nu är Queue färdig och det är dags att skapa Stack. Klasserna är lika på alla punkter utom var objekt läggs till/tas ut. Därför kan man använda IDEAs funktion clone class som man kommer åt genom att trycka F5 när markören står i klassnamnet. Ange bara namnet Stack så skapas en ny klass som ser precis ut som Queue. Byt namn på enqueue/dequeue till push/pop och ändra koden i dem så att Stack beter sig som en stack.

6. Skriv ett testprogram.

   Skapa en stack, lägg i tur och ordning in 5 olika personer i denna, och plocka sedan ut och skriv ut element i den ordning de kommer. Vi kunde använda en for-loop, men vi har egentligen inget behov av att veta vilken position vi är på – bara om det finns fler element kvar eller inte. Därför använder vi istället en while-loop som itererar så länge stacken inte är tom.

   Gör även samma sak med en kö.

7. När vi nu tar en sista titt på vad vi har gjort upptäcker vi ett par saker:

   • Stack och Queue har något gemensamt: De är en sorts listmanipulatorer som behandlar saker i listor. Då kan det kanske finnas anledning för detta att synas även i typhierarkin, genom att klasserna implementerar ett gränssnitt eller ärver från en gemensam abstrakt klass.

   • De har också en del gemensam kod, för att lagra saker i listor och vidarebefordra anrop till listor. Detta skulle man kunna flytta upp till en gemensam abstrakt klass.

   Gör detta! Skapa en superklass med något lämpligt namn, t.ex. ListManipulator. Flytta de gemensamma implementationerna dit. Här kan IDEAs Extract Superclass vara till hjälp.

   (Var detta nödvändigt? Kanske inte till 100 procent i just detta fall. Men det är bra att lära sig hitta förbättringsmöjligheter och att öva på att göra förbättringarna. I projektet är det inte ovanligt att bedömningar dras ner av strukturella problem där man t.ex. bör införa lämpliga klasser som representerar delade egenskaper.

1. Skapa equals()-metoder i AbstractShape. Använd IDEA som hjälp via Code | Generate | equals() and hashCode(): Alt+Insert. Vi är egentligen bara intresserade av equals(), men IDEA skapar också hashCode(). Denna metod används för vissa datastrukturer men är inte relevant för oss just nu.

   IDEA frågar: "Accept subclasses as parameter to equals() method?". Kryssa inte i den rutan. Vi vill bara att två objekt ska kunna anses lika om de har exakt samma klass.

   Därefter får du välja vilka fält du anser vara relevanta för att två objekt ska vara lika. Om två AbstractShape-objekt har samma koordinater men olika färg, ska de då anses vara likadana eller inte? Det avgör du själv utifrån programmets behov. Normalt anger man exakt samma fält när IDEA frågar vad som ska vara med i hashCode().

   Om det finns icke-primitiva fält, t.ex. color som är en objektpekare, kommer IDEA att fråga om de kan garanteras att inte vara null. Detta är för att inte generera onödiga null-jämförelser som kan ta någon extra nanosekund. Om du är osäker så ange att fälten kan vara null (detta kan vara något mindre effektivt men ger alltid rätt resultat).

2. Titta på de skapade equals()-metoderna. Verkar de rimliga? Man kan aldrig vara säker på att automatgenererad kod helt överensstämmer med vad man själv tänkte.

1. Skapa någonstans en Timer som kör en handling med regelbundna mellanrum, en gång i sekunden. Handlingen ska slumpa om spelplanen (inte byta ut Board-objektet utan ändra i det!) på motsvarande sätt som du gjort tidigare, och visa resultatet i textarean som du skapade i en tidigare uppgift. Handlingen behöver alltså på något sätt få tillgång till både spelplan och textarea. Slutresultatet ska helt enkelt bli att du ser en enkel "animering" på skärmen medan programmet körs. Du behöver inte kunna stoppa timern.

2. Testkör och se att spelplanen slumpas om.

1. Vi kallar en uppsättning former för ett diagram. Skapa därför ny klass, DiagramComponent, enligt följande mönster. Detta ska bli en grafisk komponent som vet hur man ritar upp ett helt diagram på skärmen.

   import javax.swing.*;
   import java.awt.*;
   
   public class DiagramComponent extends JComponent
   {   
       @Override protected void paintComponent(final Graphics g) {
   	super.paintComponent(g);
   
   	// Senare ska vi rita upp alla former här!
       }
   }

2. Lägg till ett privat fält shapes som innehåller en lista av former.

   Skapa en konstruktor som sätter shapes till en ny lista (detta har ni gjort förr!).

   Lägg till metoden public void addShape(Shape s), som ska addera en ny form till listan.

1. Just nu har varje Shape-klass en draw()-metod, men den var ju bara en platshållare som just nu skriver ut lite text. Den metoden måste göras om för att rita med hjälp av ett Graphics-objekt. Det betyder i sin tur att metoden måste skrivas om för att få ett Graphics-objekt som parameter.

   Även här kan IDEA hjälpa till. Ställ markören i ordet draw och tryck Ctrl-F6: Refactor | Change Signature. Tryck det gröna plusset och fyll in type Graphics, name g. Det talar om att metoden ska få en ny parameter, både i Shape och i alla tre konkreta implementationer. Klicka sedan i "use any var", vilket gör att IDEA också lägger till en parameter till anropen till draw() om det finns en Graphics-variabel tillgänglig där anropet sker. Tryck sedan Refactor.

   Denna refactoring kan även användas för att byta ordning på parametrar i metoddeklaration och alla metodanrop.

   

2. Nu undrar vi om det här införde några problem. Tryck Ctrl-F9 för att kompilera. Jodå: TestShapes fungerar inte längre, eftersom den anropar draw() utan parametrar. Vi kommer snart att testa detta i vår nya grafiska klass istället, så vi kommenterar bort anropet och kompilerar om igen.

3. Ändra implementationerna av draw() i alla tre konkreta formklasser. Kommentera bort utskrifterna och använd istället följande kodrader som ledning till hur man kan rita ut olika typer av former eller text:

       g.setColor(color);
       g.drawOval(x, y, width, height); // calc. from radius!
       g.drawRect(x, y, width, height);
       g.setFont(new Font("serif", Font.PLAIN, size));
       g.drawString(text, x, y);

4. Nu behöver vi till slut ett fönster som kan visa upp diagramkomponenten. Vi diskuterar hur detta fungerar på GUI-föreläsningarna. För tillfället nöjer vi oss med att basera koden på denna exempelkod för klassen DiagramViewer. Den slumpar fram ett antal former som visas på skärmen. Fungerar den som den är, eller behöver den justeras?

   package shapes;
   
   import javax.swing.*;
   import java.awt.*;
   import java.util.List;
   import java.util.Random;
   
   
   public class DiagramViewer
   {
       private final static List<Color> COLORS =
   	    List.of(Color.BLACK, Color.RED, Color.GREEN, Color.BLUE,
   		    Color.CYAN, Color.YELLOW, Color.MAGENTA);
   
       // Set a fixed seed 0 so you always get the same
       // shapes (for debugging)
       private final static Random rnd = new Random(0);
   
       private static Color getRandomColor() {
   	return COLORS.get(rnd.nextInt(COLORS.size()));
       }
   
       private static Circle getRandomCircle() {
   	return new Circle(rnd.nextInt(400), rnd.nextInt(400),
   			  rnd.nextInt(200), getRandomColor());
       }
   
       private static Rectangle getRandomRectangle() {
   	return new Rectangle(rnd.nextInt(400), rnd.nextInt(400),
   			     rnd.nextInt(200), rnd.nextInt(200),
   			     getRandomColor());
       }
   
       private static Text getRandomText() {
   	return new Text(rnd.nextInt(400), rnd.nextInt(400),
   			"Hello");
       }
   
       public static void main(String[] args) {
   
   	DiagramComponent comp = new DiagramComponent();
   
   	final Random rnd = new Random(0);
   
   	for (int i = 0; i < 10; i++) {
   	    switch (rnd.nextInt(3)) {
   		case 0:
   		    comp.addShape(getRandomCircle());
   		    break;
   		case 1:
   		    comp.addShape(getRandomRectangle());
   		    break;
   		case 2:
   		    comp.addShape(getRandomCircle());
   		    break;
   	    }
   	}
   
   	JFrame frame = new JFrame("Mitt fönster");
   	frame.setLayout(new BorderLayout());
   	frame.add(comp, BorderLayout.CENTER);
   	frame.setSize(800, 600);
   	frame.setVisible(true);
       }
   }
   

   Gör klart klassen, starta, och se ditt nya slumpmässiga konstverk!

1. Vi kommer att förändra TetrisViewer så pass mycket att det kan vara av intresse att spara undan den. En version borde så klart vara incheckad i versionshanteringen, men just i det här fallet kan vi också spara den nuvarande versionen som en kopia. Högerklicka på TetrisViewer och välj Refactor -> Copy och döp den till TetrisViewer_v1, så har ni lättare att använda den igen om ni skulle vilja.

2. Skapa en TetrisComponent-klass som är subklass till JComponent.

3. Låt TetrisComponent ha en pekare till det Board som den visar. Den behöver alltså ett fält som pekar på ett Board, och den behöver en konstruktor som tar ett Board som parameter.

4. Implementera metoden getPreferredSize() så att den returnerar den storlek du helst vill ha för den grafiska visaren. Enheten är pixlar. Om du vill anpassa komponentstorleken till skärmstorleken har vi gått genom på föreläsningarna hur man får fram skärmupplösningen. Tänk bara på att TetrisComponent-komponenten inte kan vara riktigt så stor, eftersom menyer, knappar, ramar och annat också kan ta plats.

1. Implementera paintComponent() enligt beskrivningen ovan.

2. Ändra i det tidigare GUIt så att TetrisComponent nu används istället för JTextArea plus BoardToTextConverter.

3. Ändra i testklassen, eller skriv en ny testklass, så att den Timer som introducerades tidigare ber din TetrisComponent att rita om sig istället för att manipulera den textarea vi brukade använda. Slutmålet är att brädet ska slumpas om med regelbundna mellanrum och att varje ny konfiguration ska visas på skärmen i TetrisComponent-komponenten som finns i en JFrame. För tillfället kan du be din TetrisComponent att rita om sig indirekt genom att timerhandlingen direkt anropar repaint() i TetrisComponent-objektet (som din TetrisViewer har en pekare till). I en kommande uppgift ska vi använda ett mer principiellt sätt att få TetrisComponent att uppdatera sig vid ändringar.

1. Skapa ett interface BoardListener med en metod public void boardChanged();

2. Lägg till i klassen Board ett privat fält som innehåller en lista av BoardListeners. Lägg också till en metod public void addBoardListener(BoardListener bl) som adderar den givna lyssnaren till listan. I detta spel kommer vi inte att behöva något sätt att ta bort lyssnare, även om man så klart kan lägga till även en sådan metod för att vara mer fullständig.

3. Skapa i Board en privat metod private void notifyListeners() som loopar över alla element i lyssnarlistan och anropar deras boardChanged()-metoder.

4. Se till att alla publika metoder i Board som ändrar på spelplanen anropar notifyListeners() på slutet. Detta inkluderar metoder som t.ex. ändrar koordinater på det block som håller på att ramla ner. Du måste också se till att göra på samma sätt i nya metoder du lägger till senare.

5. Ändra TetrisComponent så att den implementerar gränssnittet BoardListener. Implementera metoden boardChanged() så att den anropar repaint().

6. Se till att timerhandlingen som driver animeringen framåt inte längre anropar repaint() själv, som i tidigare lösning. Ändra istället på era testklasser så att TetrisComponent-objektet du skapar adderas som en lyssnare på spelplanen.

1. Ändra spelet så att det utgår från en tom spelplan istället för en framslumpad spelplan.

2. Implementera Board.tick(), som behöver titta om spelplanen just nu innehåller ett block (Poly) som håller på att ramla ner. I så fall flyttar den det blocket ett steg nedåt. Annars slumpar den fram en blocktyp (T, L, ...) och placerar ett nytt block av den typen överst på spelplanen, centrerat. (Mer spelmekanik tillkommer senare.)

3. Se till att tick() anropas från timerhandlingen enligt ovan.

1. Som diskuterats ovan vill vi att Board ska innehålla "logiken" för alla de "drag" man kan göra. Implementera alltså metoder i Board som anropas vid "draget" sidledsförflyttning. Dessa metoder ska helt enkelt flytta det nedfallande blocket ett steg åt sidan. Än så länge finns inget som kan vara "i vägen", så vi bryr oss inte om kollisionshantering just nu.

   Precis som alla andra metoder som ändrar på speltillståndet behöver denna metod anropa notifyListeners() för att informera alla intresserade BoardListeners om att något har ändrats. Däribland finns den grafiska komponenten som därmed ritas om varje gång ett block har flyttats i sidled.

2. Använd key bindings (se ovan) för att anropa metoderna för sidledsförflyttning när man trycker pil vänster respektive pil höger. Ni kan även anropa dem från andra tangenter om ni vill, men pilarna måste fungera.

3. Testa. Prova även att skicka blocket utanför spelplanens kanter. Om detta leder till en krasch är det än så länge helt OK.

Glöm inte att inspektera koden igen, om det var ett tag sedan du gjorde det senast. Använd Analyze | Inspect Code i menyn. Se till att inspektionsprofilen "TDDD78-2019-v1" är vald och tryck OK. Gå genom de varningar du ser. Fråga handledaren om du inte förstår en varning eller tycker att den är omotiverad.

1. Lägg till OUTSIDE som ett nytt enum-värde i SquareType.

2. Se till att konstruktorn lägger till en ram runt spelplanen enligt bilden ovan. Det ska vara två "OUTSIDE" på varje sida, eftersom detta underlättar när vi senare implementerar rotation av block. Arrayens storlek ska alltså vara 4 större än den width och height som anges. Tänk på att samma gamla värde ska fortfarande lagras i width och height, eftersom dessa fält representerar spelplanens "egentliga" storlek.

3. Eftersom andra klasser inte ska vara medvetna om ramen måste gettern för squares ändras så att den indexerar "förbi" ramen. När någon ber om blocket på logisk position (0,0) ska gettern alltså returnera blocket på position (2,2) i arrayen. Testa att det fungerar precis som tidigare.

   Om du valt att behålla BoardToTextConverter i projektet behöver du eventuellt hantera en symbol för OUTSIDE för att undvika varningar.

4. Skriv en metod hasCollision() som returnerar true om det fallande blockets nuvarande position resulterar i att en icke-tom ruta i blocket överlappar en icke-tom ruta på spelplanen. Bara SquareType.EMPTY räknas som tomt.

5. Vi kan nu använda hasCollision() för att förhindra kollision i sidled. Metoden som förflyttar blocket när spelaren trycker pil vänster eller höger måste testa om detta resulterar i en kollision. I så fall måste metoden flytta tillbaka blocket eftersom förflyttningen var omöjlig. Implementera detta.

6. Lägg till en kontroll i tick så att om blocket efter förflyttning nedåt kolliderar skall det flyttas tillbaka upp och stoppas in i brädet. Fältet falling skall i detta läge sättas till null.

7. Vi kan nu implementera "game over" genom att direkt göra en kollisionskontroll då ett nytt block slumpats fram. Om det nya blocket omedelbart kolliderade med något, var det omöjligt att lägga till ett nytt block på spelplanen. Implementera detta test samt en flagga som håller koll på om det är "game over" och om så är fallet ser till att tick inte gör något.

Glöm inte att inspektera koden igen, om det var ett tag sedan du gjorde det senast. Använd Analyze | Inspect Code i menyn. Se till att inspektionsprofilen "TDDD78-2019-v1" är vald och tryck OK. Gå genom de varningar du ser. Fråga handledaren om du inte förstår en varning eller tycker att den är omotiverad.

1. Lägg till en rotate()-metod i Board och se till att den roterar det block som just nu håller på att falla ner.

   Om det inte finns något nedfallande block ska metoden inte krascha utan helt enkelt inte göra något alls.

   Innan man "sparar" det roterade blocket måste man testa om detta skulle krocka med någon ruta som redan är upptagen – i så fall är rotationen förbjuden och måste avbrytas, och man måste gå tillbaka till den Poly man startade med. Det enklaste sättet att göra detta är troligen att man sparar undan det ursprungliga blocket, gör en roterad kopia, ser om kopian krockar, och därefter väljer vilket av de två blocken man ska behålla.

2. Lägg till kod för tangentbordsstyrning så att rotationsfunktionen i Board anropas då man trycker "pil upp"-tangenten. Ni kan även anropa funktionen från andra tangenter om ni vill, men pil upp måste också fungera för handledarens skull.

1. En av grundtankarna bakom Tetris är att en rad kvadrater "försvinner" om den blir helt full. Implementera detta, så att du kanske kan spela lite längre innan spelet tar slut!

   När din nya Board-metod tar bort alla fulla rader och flyttar ner övriga rader: Kom ihåg att inte flytta med OUTSIDE-värdena!

   Blir det svårt att fylla en rad? Testa att tillfälligt tvinga spelet att bara skapa kvadrater ("O"), så kan du testa borttagningen enklare. Då testar du även att spelet kan ta bort två rader samtidigt.

1. Lägg till menyer i spelet enligt vanliga lösningar. Se minst till att det finns en meny med valet "Avsluta". Lägg till fler val efter behov och önskemål.

2. Se till att "Avsluta" gör att en dialogruta visas med hjälp av JOptionPane, där man får bekräfta att man vill sluta. Se vanliga lösningar. Vid bekräftelse ska spelet avslutas via System.exit(0).

1. Skapa mappen pics på samma nivå som src och libs i din projektkatalog.

2. Högerklicka pics i IDEA och välj Mark Directory as | Resources Root. Detta gör att filerna i pics inte bara kommer att finnas i din källkatalog, utan även kommer att kopieras över till det kompilerade resultatet.

3. Lägg in en bildfil i pics, från kursen eller var som helst, och addera den till Git. Ta gärna hänsyn till vad andra kan tycka är trevligt att se...

4. Skapa en ny GUI-klass som kan visa en "startbild" för ditt Tetris-program. Klassen ska läsa in startbilden med hjälp av ImageIcon och ClassLoader.getSystemResource() så som diskuteras under andra delen av GUI-föreläsningen. Klassen ska sedan visa bilden på något sätt, lämpligen i ett par sekunder, och sedan stängas. Att det blir snyggt är inte viktigt, eftersom vi fokuserar på just resurshanteringen.

   Om du har lagt bilden foo.png direkt i pics ska du ange namnet /foo.png. Det är bara om du har lagt den i en underkatalog till resurskatalogen pics som du ska ange en katalog som del av resursnamnet.

5. Använd den nya GUI-klassen i ditt Tetris-spel så att bilden visas en kort tid innan spelet startar.

Inför poänghantering i spelet enligt poängsättningen ovan.

1. Bestäm en lämplig plats där nuvarande poäng kan lagras.

2. Se till att poängen uppdateras enligt ovan.

3. Se till att nuvarande poäng hela tiden visas (grafiskt) någonstans i spelet.

1. Vi ska inte lagra highscorelistan i en fil förrän i nästa uppgift. För att highscorelistan ändå ska fungera och vara meningsfull måste man kunna fortsätta spela en ny omgång när ett spel är över. Man kan t.ex. skapa ett nytt Board och en ny GUI-komponent som visar denna. Eftersom GUI-programmering inte är ett fokus kan man till och med (för enkelhetens skull) skapa ett helt nytt fönster som visar upp det nya spelet (och helst ta bort det gamla genom att anropa dess dispose()-metod). Se till att detta fungerar.

2. Skapa en Highscore-klass som lagrar antal poäng plus namn på den som fick poängen.

3. Skapa en HighscoreList-klass. Den ska innehålla funktionalitet för att lagra highscores, lägga till highscores samt få fram samtliga highscores som finns i listan.

4. När man kör igång spelet ska det skapa en enda HighscoreList en gång för alla. Detta bör inte ske i Board, utan den kan t.ex. vara den som skapar Board som också skapar listan. Annars skulle ju highscores "nollställas" varje gång man skapar ett nytt Board som har en egen ny HighscoreList!

5. Så snart en spelomgång avslutas ska programmet fråga användaren efter ett namn. Ett Highscore-objekt med rätt namn och poäng ska skapas och läggas till i highscorelistan. För tillfället behöver listan inte sorteras i rätt ordning.

6. Därefter ska programmet visa åtminstone de 10 första personerna i highscorelistan, och vänta på en knapptryckning eller liknande innan nästa spel börjar. Listan kan t.ex. visas med drawString(), som en sträng i en textkomponent, eller som en sträng i en dialogruta. Vi fokuserar inte på hur snygg visningen är.

1. Skapa en jämförarklass, en ScoreComparator, enligt ovan.

2. Använd denna för att se till att highscores sorteras (antingen vid visning eller varje gång en highscore läggs till i listan).

3. Testa!

Första steget blir att skriva highscores till fil efter ett avslutat spel.

1. Spara Gson-biblioteket någonstans i ditt projekt. Du kan t.ex. skapa en ny libs-katalog bredvid din src-katalog och spara biblioteket där.

   Addera filen till Git så det checkas in tillsammans med övriga filer.

   Högerklicka den i IDEA, välj "Add project library" och tryck OK:

   

2. Testa att använda Gson genom att skriva ut (på skärmen) en sträng för en highscorelista efter varje avslutat spel. Fungerar det? Ser det ut som du förväntade dig? Varför / varför inte?

3. Skriv en metod, kanske i HighscoreList, som sparar nuvarande highscorelista på fil i Gson-format. Spara t.ex. i nuvarande katalogen, eller i hemkatalogen: System.getProperty("user.home").

   Se till att denna metod anropas varje gång highscorelistan ändras. Om du t.ex. gör detta i metoden som lägger till nya highscores (som du kanske har kallat addScore) måste du tänka på att detta ändrar metodens kontrakt: Den kommer nu att betyda att man ska lägga till poäng i minnet och att de ska sparas på fil.

   Filhantering finns inte med på föreläsningarna, men i kursböcker (t.ex. Java Tutorial) och i gamla föreläsningsbilder. Att på egen hand kunna utforska de enklaste grunderna inom detta område är en del av det högre kravet för betyg 4.

   Tips: Använd PrintWriter för att skriva text till en fil, med korrekt konvertering av teckenkodning. Använd try-with-resources för att garantera att denna fil stängs om något går fel (en exception kastas).

   Hur ska man hantera de exceptions som kan uppstå? Just nu är det OK att göra det på godtyckligt sätt, och till och med att ignorera dem, så länge som programmet går att kompilera och fungerar i de fall man inte får exceptions. Felhanteringen ska vi snart titta närmare på.

4. Testa. Spela ett spel, skriv in en highscore, och titta manuellt på filen så att den faktiskt sparas och ser ut som den ska.

5. Se till att highscores kan läsas in igen vid uppstart av programmet. Detta kan göras genom att läsa in en sträng som man konverterar enligt exemplet ovan. Det kan också göras genom att ge fromJson() en godtycklig Reader, t.ex. en FileReader, som den själv kan läsa in strängen från (det behöver inte vara en JsonReader).

   Glöm inte att det ska fungera även om highscorelistan inte finns när du startar programmet första gången! Här kan man t.ex. prova att öppna filen, och om FileNotFoundException kastas vet man att filen inte finns och att man alltså behöver skapa en ny lista istället.

   (Det går inte att lägga inläsningskoden i konstruktorn för HighscoreList -- inläsningen skapar själv en ny HighscoreList, så det skulle leda till en oändlig loop.)

6. Testa. Radera den gamla highscorefilen och testa att programmet fungerar även då. Spela ett spel så att highscorelistan sparas, stäng av, starta upp programmet igen, och testa att gamla highscores läses in och finns kvar.

1. Se till att de undantag som kan uppstå när man sparar highscores i en fil, eller läser tillbaka dem, inte fångas upp i samma metod. Skicka istället vidare undantagen till anroparen.

   Detta borde göra att programmet inte längre går att kompilera, eftersom anroparen inte tar hand om undantagen. Kontrollera om den ska göra det eller om den också borde skicka vidare undantagen. Fortsätt till du hittar en lämplig plats att fånga undantagen, och se till att de faktiskt fångas där.

2. När undantagen fångas behöver du hantera dem på något sätt. I detta fall är det rimligast att informera användaren om felet

   Hur ska man informera? Om detta vore ett kommandoradsprogram kunde man informera via en vanlig utskrift, men nu är det ju ett GUI-program och där tittar användaren kanske inte ens i ett terminalfönster. Alltså ska man använda sig av en dialogruta!

   Dialogrutan ska visa ett lämpligt felmeddelande och fråga om man ska försöka igen.

3. Se till att faktiskt försöka igen, om användaren ber om det (om man t.ex. har ordnat mer utrymme för filen, fixat felaktiga skrivrättigheter i katalogen, eller liknande). Det ska gå att försöka igen godtyckligt antal gånger.

4. Testa att koden fortfarande fungerar när inga fel uppstår.

5. Testa att provocera fram fel! Du kan till exempel ändra åtkomsträttigheterna så att katalogen där highscores ska sparas inte blir skrivbar (chmod 000 katalogen). Se till att felhanteringskoden faktiskt fungerar!

Se till att det går att göra en paus i spelet, och att fortsätta efter pausen. Det kan till exempel finnas en grafisk knapp att trycka på, eller en tangent man kan trycka.

Avgör själv hur detta ska lösas: Genom att manipulera timern eller genom att styra vad som händer när timern "tickar". Se till att lösningen blir välstrukturerad, så att inte fel delar av programmet behöver känna till varandra.

Se till att spelet långsamt går snabbare och snabbare. Tick-takten kan t.ex. öka något för varje minut som går, eventuellt med en gräns där den inte ökar mer. Testa att ökningen känns lagom.

1. Se till att highscorelistor sparas på säkert sätt, enligt ovan.

2. Testa att detta verkligen fungerar, t.ex. genom att ändra filrättigheterna för katalogen där filerna sparas så att du (och därmed programmet) inte får skapa nya filer.

1. Skapa ett gränssnitt som heter FallHandler. Detta ska ta över en del av funktionaliteten som just nu ligger i Board och bör därför ligga nära den klassen.

2. Lägg till en signatur för en hasCollision()-metod motsvarande den du nu har i Board (men utan själva implementationen, eftersom detta är ett gränssnitt).

3. Låt din nya hasCollision()-metod få en ny parameter, av typ Board. Fallhanteraren måste ju veta vilket spelbräde den ska leta efter kollisioner i!

4. Skapa en klass som heter DefaultFallHandler som implementerar FallHandler. Flytta implementationen av hasCollision() från Board till den nya klassen. Lägg även här till den nya parametern.

   Den kod du just flyttade försöker titta på spelbrädesinformation i this, men this är ju numera en fall- och kollisionshanterare, inte ett Board. Därför behöver koden skrivas om en del så att den nya hasCollision() får information från det Board som den fick som parameter.

   Om du tidigare har implementerat hasCollision() så att den direkt använder sig av den interna representationen (SquareType[][]-arrayen) kan detta bli lite knepigt, eftersom vi inte vill att externa klasser som DefaultFallHandler ska ha tillgång till den representationen. Då får man istället skriva om den nya hasCollision() så att den använder sig av existerande, och kanske nya, getter-metoder för att hämta ut den information som krävs.

   Förtydligande: Skapa inte en metod som plockar ut den interna SquareType[][]-arrayen, utan använd mer finkorniga metoder såsom getWidth(), getHeight() och getSquareAt()!

5. Ge Board ett privat fält av typ FallHandler. Sätt detta fält till ett objekt av typ DefaultFallHandler. Se till att Board anropar hasCollision() i detta objekt, istället för att försöka anropa hasCollision() i "sig själv".

6. Testa! Om allt är korrekt ska spelet fortfarande fungera exakt som tidigare.

Nu är det dags att skapa en första powerup – ett första alternativ till DefaultFallHandler.

Din första powerup ska låta en Poly falla rakt ner, genom existerande kvadrater, ända till den når botten. Där kan den "täppa till" hål som har uppstått nära botten.

1. Skapa klassen Fallthrough som implementerar FallHandler.

2. Kopiera hasCollision()-koden från DefaultFallHandler.

3. Modifiera koden så att:

   • Om den fallande brickan överlappar OUTSIDE, detekteras en kollision.

   • Om den fallande brickan överlappar någon annan kvadrat, ignoreras detta.

   När brickan har nått botten ska dess kvadrater ersätta det som fanns på den tidigare positionen. Detta är ungefär vad som har hänt tidigare när en bricka faller. Skillnaden är att det som ersätts inte bara är EMPTY utan även kan vara andra kvadrater.

4. Hitta på ett sätt att trigga denna Powerup. Till exempel kan man få en Fallthrough var tionde Poly, eller varannan gång man har tagit bort en rad, eller något annat villkor. (Ofta får man powerups när man "plockar upp" dem någonstans på skärmen, men detta kan vara onödigt komplicerat att implementera.)

   När Board triggar en Powerup ska den alltså helt enkelt sätta om fallhanteraren till en new Fallthrough(). När nästa Poly har fallit ner ska Board sätta tillbaka fallhanteraren till en new DefaultFallHandler().

   Se till att skärmen hela tiden visar om man har en powerup, och i så fall vilken. Man kan t.ex. lägga till en metod getDescription() i FallHandler, så att varje FallHandler (inklusive default) kan ge en egen beskrivning av sig själv.

5. Testa!

6. Fick DefaultFallHandler och Fallthrough onödigt mycket gemensam, repeterad kod? Öva gärna på att skapa en gemensam (abstrakt) superklass där det gemensamma kan representeras. Duplicerad kod kan ge komplettering.

För att verkligen utforska det här sättet att programmera borde vi skapa en powerup till.

Skapa en powerup där den Poly som faller är extremt tung, så att den knackar loss underliggande kvadrater och trycker dem nedåt. Detta kan vara en väldigt kraftfull powerup, eftersom ett tryck på rätt plats kan få många rader att bli fulla på samma gång.

1. Vi vill att en Poly ska kunna trycka ner kvadrater när den flyttas nedåt, men inte när den flyttas i sidled.

   Just nu vet inte kollisionshanteraren hur falling har flyttats, bara vilken position falling har just nu. Som förberedelse behöver detta åtgärdas. Till exempel kan man ändra hasCollision() så att den får blockets gamla position som parameter. Här kan man med fördel använda refactoring i IDEA.

2. Skapa en ny sorts fallhanterare: Heavy. Se till att den "trycker ner" kvadrater enligt följande:

   • Om den fallande brickan inte har fallit rakt nedåt, används de vanliga kollisionsreglerna. Se till att den koden inte behöver upprepas utan att alla som vill ha "vanlig kollisionshantering" kan anropa samma kod!

   • Annars har vi alltså ett fall rakt nedåt jämfört med förra positionen. Om den fallande brickan då överlappar OUTSIDE, detekteras en kollision.

   • Om den fallande brickan överlappar någon annan sorts kvadrat, vill vi se om detta kan "fixas" genom att samtliga överlappande kvadrater "trycks ner".

     Man behöver alltså först testa om det för samtliga överlappande kvadrater finns tomma hål längre ner i samma kolumn.

     Om detta är falskt, detekterar vi en kollision så att den fallande brickan fastnar (översta bilden nedan).

     Om det istället är sant, ska samtliga överlappande gamla kvadrater tryckas ner ett steg (mittersta bilden nedan) och ingen kollision rapporteras. Detta kan i sin tur trycka ner andra kvadrater ett steg, men bara fram till nästa hål i denna kolumn (mittersta bilden visar hur två kvadrater trycks ner ett steg på samma gång).

     Sedan går spelet automatiskt vidare och försöker flytta brickan ytterligare ett steg nedåt, vilket kan trycka ner kvadrater ytterligare steg om det finns flera hål (tredje bilden nedan).

     

     OBS: Tänk på vad vi har sagt om vad som behöver göras i vilken ordning. Man behöver t.ex. verkligen vara säker på att samtliga överlappande kvadrater kan tryckas ner innan man börjar med att flytta vissa kvadrater. Annars kan man trycka ner en del kvadrater och sedan upptäcka att en annan del av den fallande brickan faktiskt har stöd.

3. Denna hanterare kommer också att behöva kollapsa rader, om de kvadrater som "lossnar" ramlar ner och fyller rader. I exemplet nedan bildar de gröna brickorna en sådan rad.

   

   Detta kan göras genom att man inför en särskild metod i Board för att kollapsa en given rad, och anropar detta från fallhanteraren.

4. Se till att Heavy kan triggas på något sätt.

5. Testa och iterera till du är nöjd!