Java problem

Det går om du skickar med en referens till förälderobjektet, men det är oftast inte vad du vill..

Objektorienterad programmering går i stort ut på att undvika såna här situationer. Objekten bör i så lång utsträckning som möjligt hantera sig själva utan information utifrån. När man börjar knyta samman klasser försvinner meningen med uppdelningen. Ta ett cykeldäck som exempel: däcket vet om ifall det är pumpat, vilken färg det har och dess lufttryck, men det vet inte om ifall det är monterat på en tandemcykel, sitter uppskruvat på en vägg eller studsar ner för en backe. Om däcket programmeras att vara beroende av denna information (var finns jag, vem använder mig?) omintetgörs samtidigt möjligheten att använda klassen i andra situationer. På samma sätt vet däckets ekrar om hur långa de är men inte om de sitter i ett cykelhjul.

edit: Vänder på frågan: varför vill Inventory komma åt information i Main?

Är det verkligen karaktären som ska ha en inventory då? Informationen om att han har en apekatt och en handgranat ska kanske ligga i karaktär, men själva inventory-rutan tillhör väl GUI:t snarare än karaktären.

Fallet JPanel => World: Ritas något mer på panelen? Är det kanske så att World ÄR en JPanel, snarare än ett barn till JPanel (extend istället för inkapsling)

Om World innehåller abstrakt data som inte härrör till grafik så är det inte heller Worlds uppgift att rita om sig själv. Istället kan JPanelens paint-metod fråga World om dess storlek och sedan rita ut bakgrunden.

edit: när du MÅSTE knyta samman två objekt kan du göra det genom konstruktorn:

class Foo {
   Bar myBar;
   public Foo() {
      myBar = new Bar(this);
   }
}

class Bar {
   Foo myFoo;
   public Bar(Foo foo) { myFoo = foo; }
}

Ja det är krångligt faktiskt, körde fast där själv och håller bara på med teoretisk Javaprogrammering nu för tiden Ofta blir det att man stoppar in alldeles för mycket funktionalitet i en klass, den ska täcka hela behovet liksom..

Bara för att leka lite med tanken på hur en alternativ struktur ser ut har jag pillat ihop ett litet exempel som kan ses som brainstorming. I detta fallet skulle man kanske kunna dela upp allting ganska enkelt. Alla informationsobjekt som bara modellerar data heter som du redan har namngett det:

• World

• '-> Character

• *'-> Inventory

En World har en Character som har ett Inventory.
Dessa innehåller information som namn, hälsa, innehåll. Rent datainnehåll, ingen information om hur dessa ska ritas ut.
Sen har du konkreta klasser som styr grafikritning:

• GameWindow (extends JFrame)

• '-> GamePanel (extends JPanel, overrides paintComponent())

• * '-> InvetoryView (behöver inte vara en JComponent utan får Graphics g direkt från GamePanel och använder den för att rita direkt på GamePanel)

• * '-> Minimap (samma som InventoryView. Har ingen egen modell utan hämtar information direkt från World pch Character (karaktärens position bestämmer vad som syns i minimapen))

GameWindow håller ihop GUI:t och skapar GamePanel som i sin tur skapar InventoryView och Minimap. Sedan måste naturligtvis InventoryView på något sätt få tillgång till datan i Inventory. Denna data kan vara publikt tillgänglig från World. På detta vis är GameWindow direkt beroende av World och dess barn, medan World är helt ovetandes om hur den presenteras.

Egentligen behöver du faktiskt inte ha en InventoryView heller så länge som det bara finns en inventory. Så länge projektet inte blir jättestort så kan GamePanel hantera uppritningen av inventoriet direkt istället. Det är snarare om du ska ha flera olika inventories som du behöver en fristående view för den..

Det beror som sagt på om Character har egna rutiner för att rita grafik. Är Character ett grafiskt objekt eller är det data om en spelkaraktär? Säg att du skulle vilja porta spelet till console, hur mycket skulle du då behöva skriva om? När du har datamodellen separerad är du fri att skapa views som presenterar datan hur du vill. Ponera följande..

class Boll {
   public String färg;
   public double studsFaktor;

   // ...
}

Utan att krångla till det med metoder och dylikt. Denna kod kan ritas upp både grafiskt...

... extends JPanel {
   public void paintComponent(Graphics g) {
      String färg = minBoll.färg;
      if (färg.equals("röd")) then setColor(Color.RED);
      // ...
}

och med text...

   public void describeBall() {
      String studs;
      if (minBoll.studsFaktor > 0.5) {
         studs = "bra";
      } else {
         studs = "dålig";
      }
      System.out.println("Bollen du håller i din hand är " + minBoll.färg + " och har " + studs + " studs.");
   }

Om man istället hade låtit bollen ärva från JComponent och sålunda ha sin egen paintComponent-metod så hade man knutit koden till ett grafiskt gränssnitt. Koden hade förvisso kunnat ha färginformation och liknande men det hade kunnat resultera i bloat. Ett enkelt spel behöver egentligen inte mer än en klass, då slipper man ju problem med värdeåtkomst från olika delar av programmet. Om man vill skapa en klasstruktur är det viktigt att tänka igenom den noga.

För det första tycker jag inte att du ska ha hasXxx-metoder på din inventory eftersom föremål kan komma att läggas till eller tas bort, och då behöver du uppdatera din inventory-klass samt alla has-anrop som finns.

Vidare tycker jag fortfarande inte att karaktären ska rita sig själv, eller världen. Du har ännu inte berättat var du tänker spara positionsdata om karaktär/värld, så jag utgår ifrån att du har det i samma klasser? Då kan den problematik du beskriver uppstå, eftersom objekten ska rita sig själva men bara har tillgång till sin egen begränsade information.

Utifrån den samlade information du gett skulle jag haft en GamePanel-klass som hade tillgång till all nödvändig data och ritade datan därefter. Samma klass kan styra input och öppna nya frames. Man kan alltså dra det så långt att man slår samman kontroll och vy i en klass. För enkelhets skull kan vi kalla den Game (extends JPanel).

Då blir strukturen istället såhär:[list="1"]
[*]spelaren trycker höger piltangent för att flytta gubben i den riktningen;
[*]Game hämtar positionsdata från Character och jämför med World. Finns det någon vägg åt höger? Uppdatera Character-position om flytt är godkänd;
[*]Game ritar om sig. Detta är en stor funktion som hämtar data från alla aktörer och ritar dem.
[*]Efter ett tag trycker spelare på 'i'. Game skapar en InventoryPanel och ett nytt fönster, sätter InventoryPanel:n som contentPane och ger fokus till fönstret. Datan till InventoryPanel hämtas från karaktärens inventory (.getInventory(), returnerar en lista med GameItems eller dylikt). Samtidigt sätts en boolean i Game så att spelet pausas, kanske ritas en halvtransparent svart ruta över den andra grafiken så man får intrycket av att fönstret inte är aktivt?
[/list=1]
Problemet i detta läget är att Game blir en så kallad God-class: All information flödar genom Game, men det är kanske inte ett lika stort problem i detta läget..

Det borde bara vara att sätta Game som InventoryPanels fönsters Action/WindowListener. Kommer close från inventoryWindow så stänger Game fönstret.

edit: WindowStateListener passar nog bra.

WindowStateListener är ett Interface. Du kan sätta den på vilken klass som helst; även class Dummy implements WindowStateChange { ... är legitimt. Det enda den gör är att försäkra att klassen kan lyssna till WindowStateChange-events. Du kan sålunda ha class Game extends JPanel implements WindowStateListener { .... När du skapar ditt inventory-fönster så knyter du det till game-klassen innan du lämnar över..

class Game ... { 
boolean inventoryIsOpen = false;
...

JFrame inv = new InventoryFrame(myCharacter.getInventory());
inv.addWindowStateListener(this); // sätter Game som WindowStateListener till inventory-fönstret
inv.pack();
inv.show();
inv.focus();

inventoryIsOpen = true; // påverkar hur Game ritar om sig/hanterar key inputs/focus.

Precis, där har du problemet med logik centraliserad till en klass: tar du bort klassen finns det egentligen ingenting kvar av programmet. I detta fall skulle du ha kvar datamodeller utan funktion eller form.

Du berör en annan intressant punkt nu, nämligen att Character och Arrow har delade attribut. När man får två eller fler klasser som delar egenskaper kan det vara bra att skapa en superklass till dem som de båda ärver av.

Säg att du har ett antal klasser: Arrow, Rocket, Cloud, Dog. Alla ska röra sig. I din programkod har du följande:

rockets[] Rocket;
arrows[] Arrow;
clouds[] Cloud;
dogs[] Dog;

...

while (gameIsRunning == true) {
   for (int i=0; i<rockets.length; i++) {
      rockets[i].move();
   }
   for (int i=0; i<arrows.length; i++) {
      arrows[i].move();
   }
// etc...
}

Ovan nämnda klasser har alla en .move()-metod som kan flyttas till en [abstrakt] superklass, vi kallar den här för Actor. Du kan sedan omstrukturera såhär:

actors[] Actor;

while(gameIsRunning == true) {
   for (int i=0; i<actors.length; i++) {
      actors[i].move(); // spelar ingen roll om actors[i] är en Rocket, Arrow eller Dog
   }
}

En annan sak du kan göra för att strukturera ditt spel är att flytta bitar av objektrelaterad spelkod från game-klassen till nyskapade mindre klasser med samma målsättning. Exempelvis kan du skapa två nya klasser för din Character, en CharacterController och en CharacterView (observera att namnen här är riktigt dåliga). Utifrån sett hanterar bara din karaktär genom en av klasserna, Controllern. Du säger åt controllern att du vill flytta karaktären (charController.move()) och den i sin tur hämtar positionsdata från modellen och skickar till viewen så att den kan rita upp gubben. Det är precis så här Swing fungerar: Du har säkert skapat hundratals JFrames utan att tänka på att det i bakgrunden ligger en JFrameModel (obs, heter med största sannolikhet inte så). Olika Themes bestämmer sedan hur din JFrame ska se ut med ramar osv (detta är JFramens View).

Nä inte riktigt så. Views innehåller inte information som syns (bilder, färger osv) utan bestämmer HUR ett objekt visas.

I ditt fall kan man säga att Game har blivit både Controller och View för samtliga klasser då den sköter både dataflödet (hämta position, färg, ikon, har något krockat? Ta bort fiende) och bestämmer hur all slutgiltig information ska presenteras (ritas på en JPanel i detta fall).

Nej. När Game känner av VK_LEFT säger den åt Character (som är en kontroller) att den ska flytta sig till vänster. Controllern (Character) kontaktar sedan själv sin modell och hämtar/ändrar data, och säger åt sin View att rita om sig.

Game vet inte om att det finns en CharacterModel och CharacterView. Den bryr sig inte och ska inte behöva bry sig om detta.

Nej, du missuppfattar igen. Om du vill dela upp din nuvarande struktur mer så ska inte ikonerna skötas av Game. charController ska inte ha positionsdata, det ska modellen ha. Jag krånglade kanske till det för dig när jag började snacka om de här MVC-begreppen.

Det enklaste är att fortsätta ha Game som huvudklass i den utsträckning det nu går. Stöter du på fler problem går det alltid att omstrukturera. Om du vill läsa lite mer om Model-View-Controller-mönstret finns information på Wikipedia och google

Ja det låter rätt
JPanel ur ditt exempel ovan behöver inte vara en JPanel, men råkar vara det denna gång (fast det förstod du nog, ville förtydliga för säkerhets skull.)

Det är alltså Character's (i samverkan med dess modell/view) uppgift att rita sin animation och avgöra hur den ser ut, men den som säger till Character att animera/röra sig/göra något är alltså i detta exempel Game.

På så sätt kan du ha flera underklasser till Character som alla har move()-metoden men som animerar sig på olika vis.