[JAVA] Zoeken in een arraylist

[Mattie112]

Hai

Ik vul een arraylist op deze manier:

code:

int id = 1;
Bom bom1 = new Bom(id, xpos, ypos); 
add(bom1);
bomLijst.add(bom1);

Nou wil ik later dat object weer opzoeken en verwijderen:

code:

int id = 1;
int index = bomLijst.indexOf(id);
Bom b1 = bomLijst.get(index);
b1.setVisible(false);
b1.remove(b1);
bomLijst.remove(index);

Helaas krijg ik de error dat "id" niet bestaat.
"java.lang.ArrayIndexOutOfBoundsException: -1"

Ik heb al diverse "zoek in de arraylist" manieren gepprobeerd maar die werken somehow allemaal niet.

(oa http://www.java-examples....nt-java-arraylist-example | http://www.java-examples....ch-java-arraylist-example )

Ik wil dus:
het object uit de arraylist "bomLijst" zoeken welke de id waarde "1" heeft meegekregen tijdens het maken.
hoe kan dit?

(zoeken naar "1" (als string) ivp als int hielp ook niet)

[Barbaar]

Je hebt een ArrayList met Bommen erin. Met bomLijst.indexOf(id) probeer je te kijken of er een int (met waarde 1 in dit geval) in de array zit. Deze kan hij niet vinden en zal -1 teruggeven. Vervolgens zal bomLijst.get(index) inderdaad een ArrayIndexOutOfBoundsException geven, omdat index -1 niet bestaat.

Je zult dus je zoekmethode moeten aanpassen om niet direct op id te zoeken, maar naar Bommen met dat id. Succes

[RobIII]

^^ Wat hij zegt. En tevens moet je dus gaan (leren?) debuggen: Debuggen: Hoe doe ik dat?

[HMS]

Met een beetje debugging en kijken op welke line die exception gethrowed wordt, zou je ook een eind gekomen zijn (denk ik)

[Mattie112]

Bedankt!
Ik had ook wel door dat hij die '1' niet kon vinden maar de manier waarop schoot me maar niet te binnen.

Ik heb het opgelost door in die klasse Bom een

code:

public int getID()
{
return ID;
}

te maken en daar op te zoeken.

(o, en het kan best zijn dat dit een noob vraag was maar ik programmeer nog niet zo lang in java)

[Janoz]

Als het van belang is dat je je bom (snel) terug wilt kunnen vinden op basis van ID is het misschien handiger om een Map te gebruiken ipv een List

[Mattie112]

eeh, ik ken Map niet.
Ik zal dr eens even naar googelen.
bedankt voor de tip!

[Domdo]

Je zou ook een methode equals(int i) in je classe Bom kunnen maken dan kun je indexOf(object o) wel gebruiken afaik.

[Herko_ter_Horst]

@Dombo: je kunt niet de signature van equals() aanpassen. Je kunt wel binnen de equals op ID vergelijken.

Maar waarom heeft een bom eigenlijk een ID?

Ik heb vanwege het voorbeeld het gevoel dat de TS iets Stratego-achtigs aan het maken is, klopt dat? Zo ja, dan is een ID toch helemaal niet van belang? Je wilt dan waarschijnlijk bommen op Position terug kunnen vinden. Dat zou je voor elkaar kunnen krijgen door ze op basis van een Position in een Map te stoppen.

Maar misschien zit ik er helemaal naast voor wat betreft het eigenlijke probleem

[Haan]

Ik denk eerder aan mijnenveger. Maar daarvoor geldt opzich hetzelfde argument ja.

[truegrit]

Waarom moeilijk doen met een Map als je dan ook simpelweg een 2-dimensional array kan maken?

[Herko_ter_Horst]

truegrit schreef op zaterdag 10 april 2010 @ 12:23:
Waarom moeilijk doen met een Map als je dan ook simpelweg een 2-dimensional array kan maken?

Vandaar de vraag aan de TS wat het echte probleem is

[Domdo]

nvm

[ Voor 99% gewijzigd door Domdo op 10-04-2010 15:10 ]

[hellfighter87]

truegrit schreef op zaterdag 10 april 2010 @ 12:23:
Waarom moeilijk doen met een Map als je dan ook simpelweg een 2-dimensional array kan maken?

Simpelweg omdat bepaalde collecties voor bepaalde doeleinden worden gemaakt
En daarbij dus efficiënter zijn

Maar heeft een arraylist niet een contains functie?

[Hydra]

hellfighter87 schreef op zaterdag 10 april 2010 @ 15:15:
Simpelweg omdat bepaalde collecties voor bepaalde doeleinden worden gemaakt
En daarbij dus efficiënter zijn

Maar heeft een arraylist niet een contains functie?

Ja, maar die indexOf werkt ook gewoon op basis van de equals methode. Als 'ie die override zodat hij Bom classes (of eventueel Bom <> int ids) kan vergelijken kan 'ie op die manier prima zoeken. Op dit moment heeft 'ie dat niet gedaan en zal de Bom.equals() alleen true teruggeven als het exact hetzelfde object betreft.

Hij zal hoe dan ook die equals methode moeten overriden. Of een Map gaan gebruiken.

[Remus]

truegrit schreef op zaterdag 10 april 2010 @ 12:23:
Waarom moeilijk doen met een Map als je dan ook simpelweg een 2-dimensional array kan maken?

Ligt eraan: waarom zou je een array van n^2 aanmaken als er maar enkele voorwerpen in zitten om te localiseren. Een map is dan simpeler en neemt minder ruimte in. En daarnaast is een Map wat mij betreft niet 'moeilijk doen'.

[truegrit]

Ik ging even uit van de opmerking dat het een spelletje zoals mijnenveger zou zijn, waar een 2 dimensionale array toch wel bestaansrecht heeft. Maar zoals eerder gezegd, zonder meer gegevens van de TS over de context is het niet nuttig om hier over te gaan discusseren.

[Mattie112]

Bedankt voor de reacties, ik zal even een en ander verduidelijken.

Ik ben bezig om het spel bomberman in java te maken. De reden dat ik voor ID gekozen hebt is omdat ik moet weten bij welke 'speler' de bom hoort.

Ik maak gebruik van een 2d array die het level (deels random) vult.

Indien gewenst kan ik wel even al mijn code uploaden (maar schrik niet want ik werk dus nog niet zo lang met java en de docent legt niks uit dus google is mn enige hulp )

[Hydra]

Mattie112 schreef op dinsdag 13 april 2010 @ 11:02:
Indien gewenst kan ik wel even al mijn code uploaden (maar schrik niet want ik werk dus nog niet zo lang met java en de docent legt niks uit dus google is mn enige hulp )

Daar hebben meer docenten last van. In veel gevallen lopen die docenten niet of nauwelijks voor op hun studenten kwa kennis. Da's het nadeel van HBO (zelf HBO-I, vroeger HIO gedaan).

Wat betreft het posten van je code: beste het bij de relevante stukken te houden. Welke problemen loop je nu nog tegen aan?

[michiel_]

Mattie112 schreef op dinsdag 13 april 2010 @ 11:02:
De reden dat ik voor ID gekozen hebt is omdat ik moet weten bij welke 'speler' de bom hoort.

Waarom geen referentie naar het Speler object in de bom?

Java:

private Player owner;

[Mattie112]

atm werkt alles wat volgens mn code zou moeten werken.

Alleen vraag ik me nog steeds af of die manier die ik gebruik nou wel de handigste manier is

puur voor de geintereseerde hier mn code
http://upload.mattie-syst...ads/25724-bomberman18.rar

BombermanApp = main
Level = alles wat je ziet
Bomberman = de bomberman's (spelers)
RandomLevel = de klasse die alleen de 'blokjes' level tekent (Level zelf geeft door WAT er gemaakt moet worden)
Explosie = als de bom ontploft is een rood vakje maken (is dus nog niet af)
Bom = het tekenen van een bom
Botsing = gemaakt door een docent (die ik niet heb helaas) om te chekken of 2 vensters elkaar raken
RechterPaneel = het groene wat je ziet, doet nog niks atm maar krijg later (hopelijk) oa de status v/d spelers


nogmaals:
ik werkt dus PAS een half jaartje met java (wel heel leuk trouwens)


edit: @michiel_
En hoe zou ik daar dan naar moeten refereren? Ik heb namelijk (max) 4 spelers welke objecten zijn van de klasse bomberman.

Dan zou ik bij het maken van een bom door moeten geven van welk object het komt?

[ Voor 11% gewijzigd door Mattie112 op 13-04-2010 11:25 ]

[Hydra]

Je hebt code om je zaken op 't scherm te tekenen in je Bom / Bomberman etc. classes zitten. Kennelijk heb je nog niks geleerd over het MVC model

Dus ja, ik zou een hoop dingen anders doen maar dat is onderdeel van je leerproces en als je daar fouten in gemaakt hebt hoor je dat wel. M'n eerste java apps waren ook bagger. Al doende leert men

Mattie112 schreef op dinsdag 13 april 2010 @ 11:18:
Dan zou ik bij het maken van een bom door moeten geven van welk object het komt?

Elementary my dear Watson

[ Voor 24% gewijzigd door Hydra op 13-04-2010 11:27 ]

[Salandur]

Alle collection objecten hebben ook de methode 'contains'. hiermee kan je controleren of een object al voorkomt in je collection. als je hier gebruik van maakt dan krijg je geen 'ArrayIndexOutOfBoundsException's meer.

[Hydra]

Salandur schreef op dinsdag 13 april 2010 @ 11:31:
Alle collection objecten hebben ook de methode 'contains'. hiermee kan je controleren of een object al voorkomt in je collection. als je hier gebruik van maakt dan krijg je geen 'ArrayIndexOutOfBoundsException's meer.

Als 'ie niet het originele object heeft maar alleen een id, zal 'ie toch echt die equals methode moeten overriden, zoals eerder uitgelegd is.

[Salandur]

Hydra schreef op dinsdag 13 april 2010 @ 11:35:
[...]


Als 'ie niet het originele object heeft maar alleen een id, zal 'ie toch echt die equals methode moeten overriden, zoals eerder uitgelegd is.

Als je het originele object niet hebt, kan je ook geen gebruik maken van indexOf. Om van indexOf en contains goed gebruik van te kunnen maken moet je van de class hashCode en equals overschrijven en de mogelijkheid hebben een dummy object te maken waarmee je dan kan indexen.

[Hydra]

Salandur schreef op dinsdag 13 april 2010 @ 13:40:
Als je het originele object niet hebt, kan je ook geen gebruik maken van indexOf. Om van indexOf en contains goed gebruik van te kunnen maken moet je van de class hashCode en equals overschrijven en de mogelijkheid hebben een dummy object te maken waarmee je dan kan indexen.

Anders lees je de rest van het topic ff? Ik zei eerder al dat zowel indexOf als contains onderhuids gewoon de equals methode aanroepen, en die dus moet overriden.

[Salandur]

Hydra schreef op dinsdag 13 april 2010 @ 13:43:
[...]


Anders lees je de rest van het topic ff? Ik zei eerder al dat zowel indexOf als contains onderhuids gewoon de equals methode aanroepen, en die dus moet overriden.

Net even het hele topic doorgelezen, maar je kan indexOf niet gebruiken bij een Map als je alleen het ID hebt. Op het moment dat je equals override, moet je je ook aan het contract houden van equals. Dat houdt in dat als x.equals(y), y.equals(x) hetzelfde resultaat geeft. Als je alleen het ID hebt (van type Integer) dan kan je die nooit met equals vergelijken, immers als Bom.equals(Integer) true geeft als het Integer het Id is, geeft Integer.equals(Bom) false terug, omdat dit nou eenmaal zo gedefinieerd is. Tevens ben je, by contract, verplicht hashCode() te overriden als je equals() override, omdat het volgende in de Java API staat:

Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

[Hydra]

Salandur schreef op dinsdag 13 april 2010 @ 14:24:
Net even het hele topic doorgelezen, maar je kan indexOf niet gebruiken bij een Map als je alleen het ID hebt.

Het ging om arrays en arraylists. Niet om maps. ArrayLists gebruiken de hashcode niet en het is dus niet perse nodig deze te overriden. Wil je dit wel doen dan doe je dit gewoon door als hashcode de integer ID terug te geven, aangezien dat ook al de ID van dat object is.

En lees de volgende keer eerst ff de reacties. Beetje irritant als iemand 3 dagen later precies hetzelfde komt melden.

[DutchCommando]

Hydra schreef op dinsdag 13 april 2010 @ 11:26:
Je hebt code om je zaken op 't scherm te tekenen in je Bom / Bomberman etc. classes zitten. Kennelijk heb je nog niks geleerd over het MVC model

Wat mij betreft is de desbetreffende tekencode netjes encapsulated. De view observed het model en kan best op het moment dat de data in het model aangepast wordt aan dit model vragen om zichzelf opnieuw te tekenen.

[Janoz]

Hydra schreef op dinsdag 13 april 2010 @ 15:25:
[...]


Het ging om arrays en arraylists. Niet om maps. ArrayLists gebruiken de hashcode niet en het is dus niet perse nodig deze te overriden. Wil je dit wel doen dan doe je dit gewoon door als hashcode de integer ID terug te geven, aangezien dat ook al de ID van dat object is.

En lees de volgende keer eerst ff de reacties. Beetje irritant als iemand 3 dagen later precies hetzelfde komt melden.

Toch heeft Salandur gelijk. Dat je je Bomb class aanpast tegen de geldende confenties in omdat een compleet andere class toevallig geen gebruik maakt van de hashcode om vervolgens een methode uit die class te gaan misbruiken voor functionaliteit die op een veel nettere manier zelfs efficienter op te lossen is dan ben je niet echt heel slim bezig.

@TS: Tipje: Je bent aan het programmeren. Je werkgeheugen is geen relationele database. Probeer dan ook het idee te laten varen dat je alles middels ID's en foreign keys aan elkaar wilt knopen.

Hoort een Bomb bij een Player? Gooi dan niet een PlayerID in de Bomb, maar neem in de Bomb gewoon een referentie naar Player op. Wil je eigenlijk vooral achterhalen welke Bomb's een player heeft? Neem dan een lijstje Bombs op in Player. Het toekennen maakt geen kopie. Het blijft gewon hetzelfde object.

[Hydra]

Janoz schreef op dinsdag 13 april 2010 @ 16:01:
Toch heeft Salandur gelijk. Dat je je Bomb class aanpast tegen de geldende confenties

Tegen welke conventies gaat het in om als een object gedentificeerd wordt aan de hand van een id de equals methode dat id te laten vergelijken? Dat is exact hoe je zorgt dat jouw objecten zich 'goed' gedragen in collections in dit soort situaties.

Ik vind het ook netter gewoon een referentie bij te houden maar daar ging het me niet om.

[.oisyn]

Hydra schreef op dinsdag 13 april 2010 @ 16:19:
[...]


Tegen welke conventies gaat het in om als een object gedentificeerd wordt aan de hand van een id de equals methode dat id te laten vergelijken? Dat is exact hoe je zorgt dat jouw objecten zich 'goed' gedragen in collections in dit soort situaties.

Tegen de conventie dat x.equals(y) <=> y.equals(x). X is hier Bomb, y is Integer. Integer.equals() mag je niet aanpassen. Kun jij garanderen dat een container alleen element.equals(searchkey) doet, en niet searchKey.equals(element)? Er is geen enkele reden om dat gedrag in een container vast te leggen, want er zijn immers duidelijke conventies omtrent equals()

[Janoz]

Hydra schreef op dinsdag 13 april 2010 @ 16:19:
[...]


Tegen welke conventies gaat het in om als een object gedentificeerd wordt aan de hand van een id de equals methode dat id te laten vergelijken?

Quote

public boolean equals(Object obj)
Indicates whether some other object is "equal to" this one.
The equals method implements an equivalence relation on non-null object references:

• It is reflexive: for any non-null reference value x, x.equals(x) should return true.
• It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.
• It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.
• It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.

For any non-null reference value x, x.equals(null) should return false.
The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any non-null reference values x and y, this method returns true if and only if x and y refer to the same object (x == y has the value true).

Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

[Hydra]

.oisyn schreef op dinsdag 13 april 2010 @ 16:36:
Tegen de conventie dat x.equals(y) <=> y.equals(x). X is hier Bomb, y is Integer. Integer.equals() mag je niet aanpassen. Kun jij garanderen dat een container alleen element.equals(searchkey) doet, en niet searchKey.equals(element)? Er is geen enkele reden om dat gedrag in een container vast te leggen, want er zijn immers duidelijke conventies omtrent equals()

Oh, dan begrepen jullie niet wat ik bedoelde. Ben er mee eens dat direct vergelijken met een Integer niet hoort maar dat was niet wat ik in gedachte had. Bedoelde dit:

Java:

public class Bom
{
   private int id;
   public Bom(int id)
   {
       this.id = id;
   }

   public boolean equals(Object o)
   {
      if(p instanceof Bom)
         return ((Bom)o).id == this.id;
      else
         return false;
   }
}

(Rest ff weggelaten)

Sorry dat ik dat niet helemaal duidelijk gemaakt had.