[JAVA] Alle instanties van één klasse opvragen

[Nick The Heazk]

Even een situatie-schets:

Het is de bedoeling om te tellen hoeveel armors een held bij zich heeft. Deze held heeft een aantal anchors waaraan een (of geen) item kan bevestigd zitten. Verder heeft de held nog een apparte anchor voor de armor. Een van de items die een held kan meedragen is een rugzak. In deze rugzk kunnen opnieuw rugzakken en andere items zitten.

Een rechtdoorzee aanpak is om bij de held een methode countArmors() te maken, die vervolgens alle anchors doorloopt en met behulp van instanceof bepaald of het een rugzak is of een armor. (een countArmor() methode is niet echt zinnig voor geld, wapens, geldbeugels ...). Indien het een rugzak is wordt bij het totaal aantal getelde armors bijgeteld hoeveel armors er (indirect) in de rugzak zitten (met een recursieve methode, doch wederom met een instanceof om te bepalen of iets een rugzak is.)

Dit ziet er als volgt uit:

Java:

    
(Klasse: Hero)
public int countArmors() {
        int total = 0;
        if(this.getArmor() != null)
            total++;
            
        for(Anchor<Holdable> anchor : this.getAnchors()) {
            if(anchor.isOccupied()) {
                Holdable item = anchor.getHoldable();
                if(item instanceof Armor)
                    total++;
                if(item instanceof BackPack)
                    total += ((BackPack) item).countArmors();
            }
        }
        
        return total;
    }

Met nog een recursieve countArmors() methode in de klasse BackPack. Aangezien instanceof nu niet bepaald onderhoudbaar is, dacht ik eraan om de bidirectionele binding uit te buiten.

Ik kan namelijk aan een armor vragen wie zijn houder is. Dit kan ik dan eenvoudig vergelijken met de huidige instantie van de held. Het eerste wat bij me opkwam was om reflectie te gebruiken om alle instanties van de klasse Armor op te vragen, en over deze rij te itereren.

Ondertussen heb ik al een tijdje zitten zoeken in het java.lang.reflect package (vooral in de Class klasse), maar ik kan nergens een dergelijke methode vinden (getSigners() heb ik geprobeert, maar dat doet blijkbaar niet veel).

Ik vroeg me dan ook af of het nota bene wel mogelijk is om alle instanties van een klasse te bepalen (zonder zelf een gegevensstructuur te declareren die dat doet. De code komt daar niet voor in aanmerking aangezien het onbekend is hoeveel instanties er van een Armor zullen gemaakt worden.) ?

[jAnO!]

gokje:
de tijd die je hebt gespendeerd aan het uitzoeken is al meer dan je ooit zal moeten onderhouden aan de instanceof...

[Janoz]

Misschien is het handig om een interface te maken. Deze interface heeft een 'getArmor' methode. Deze laat je implementeren door backpack en armor. Bij armor geef je 1 (of de sterkte van dat armor)terug. Bij backpack ga je op alle items die erin zitten 'getArmor' aanroepen en deze bij elkaar optellen. Uiteindelijk krijg je dan de totale hoeveelheid armor terug.

Als het je echter om de armor instanties gaat, dan zou je de getArmor() niet een int, maar een list kunnen laten opleveren. Bij backpack merge je deze lijsten voordat je ze terug geeft en bij een armor object geeft deze een lijst met 1 element terug.

[Verwijderd]

Een interfaceje met daarin een methode "int itemCount()"
Al je relevante classes dat interfaceje laten implementeren. En de exacte telling dus overlaten aan de concrete implementaties... Voila

[DroogKloot]

Wil je nou alleen weten *hoeveel* instances van die class zijn aangemaakt, of heb je ook echt references naar die objecten nodig? In het eerste geval is wat je doet namelijk nogal omslachtig, hou gewoon een counter (numArmors ofzo) bij in je Anchor class en verhoog die wanneer er een Armor object aan wordt toegevoegd?

[Nick The Heazk]

Janoz schreef op dinsdag 23 mei 2006 @ 11:57:
Misschien is het handig om een interface te maken. Deze interface heeft een 'getArmor' methode. Deze laat je implementeren door backpack en armor. Bij armor geef je 1 (of de sterkte van dat armor)terug. Bij backpack ga je op alle items die erin zitten 'getArmor' aanroepen en deze bij elkaar optellen. Uiteindelijk krijg je dan de totale hoeveelheid armor terug.

"Probleem" daarvan is dat het gebruik van de instanceof nog steeds niet verbannen is aangezien in een backpack ook andere dingen dan armors en backpacks kunnen steken. Je zorgt er natuurlijk wel voor dat je maar 1 instanceof overhoudt. Het zou allemaal veel eleganter kunnen indien je alle instanties van een bepaalde klasse kunt opvragen .

DroogKloot schreef op dinsdag 23 mei 2006 @ 12:03:
Wil je nou alleen weten *hoeveel* instances van die class zijn aangemaakt, of heb je ook echt references naar die objecten nodig?

Ik wil weten hoeveel instanties van een bepaalde klasse naar een bepaald object (dat niet voor elke instantie gelijk is) wijzen. In dat geval kan ik dus niet meer met een ordinaire teller werken.

[writser]

Concreet voorstel: hou in de hero bij hoeveel armors hij heeft. Pak je een nieuw item, kijk dan of het een armor is en verhoog de teller. Drop je een item, idem en verlaag de teller. In elk geval maak je het jezelf veel te moeilijk als je alleen geinteresseerd bent in het AANTAL armors.

En nu de theorie: als je van een klasse alle mogelijke instanties wil bijhouden doe je dat met statische objecten / methodes. Voorbeeldje (snel in elkaar geprutst, ben niet zo'n Java held )

Java:

class Item {
  Item() {
    allInstances.add(this);
  }

  ~Item() {
    allInstances.remove(this);
  }

  static List<Item> allInstances;
};

[ Voor 4% gewijzigd door writser op 23-05-2006 13:52 ]

[Robtimus]

writser schreef op dinsdag 23 mei 2006 @ 13:50:
Concreet voorstel: hou in de hero bij hoeveel armors hij heeft. Pak je een nieuw item, kijk dan of het een armor is en verhoog de teller. Drop je een item, idem en verlaag de teller. In elk geval maak je het jezelf veel te moeilijk als je alleen geinteresseerd bent in het AANTAL armors.

En nu de theorie: als je van een klasse alle mogelijke instanties wil bijhouden doe je dat met statische objecten / methodes. Voorbeeldje (snel in elkaar geprutst, ben niet zo'n Java held )

Java:

class Item {
  Item() {
    allInstances.add(this);
  }

  ~Item() {
    allInstances.remove(this);
  }

  static List<Item> allInstances;
};

Java heeft geen expliciete destructors. In plaats daarvan zul je de finalize() method moeten overriden:

Java:

protected void finalize() throws Throwable {
    allInstances.remove(this);
    super.finalize();
}

[writser]

Ah prima. Dat wist ik niet, mijn voorbeeld was half in C++ . Maar deze methode zou wel moeten werken.

[ Voor 78% gewijzigd door writser op 23-05-2006 14:00 ]

[Janoz]

Je zou de hoeveelheid armor die een item bied ook een propertie van Holdable maken. Bij niet armor geeft deze dan 0 terug. Dan ben je van je instanceOf af. Globaal bijhouden lijkt me een slecht idee. Op dat moment lekt als het ware je implementatie uit de scope. Bepaalde functionaliteit wordt ergens anders geimplementeerd en niet op de plek waar je het verwacht. Onderhoud wordt dan een stuk lastiger. Daarnaast krijg je bijvoorbeeld ook problemen wanneer je bv een multiplayer versie gaat maken. Dan zul je je globale 'alle armor' lijst ineens weer per speler bij moeten gaan houden en uiteindelijk heb je 2x een item lijst. 1x via de anchors en 1x via een instantie lijst.

@droogkloot:
Een counter bijhouden zorgt wel voor wat administratief werk. Je kunt dan niet je backpack objecty pakken en daar wat items uit wegflikkeren omdat de anchor counter dan niet automatisch geupdate wordt. Bij die implementatie zul je de backpack dus were 'aware' moeten maken van de anchor waar hij aan zit of de backpack waar hij in zit.

[Gerco]

Het "instanceof" probleem hoeft niet zo groot te zijn als het nu lijkt. Als je nu werkt met een interface "IArmour", deze hoeft niet per-se methods te hebben, maar het kan wel. Alle objecten die die interface implementeren zijn dus armour en je kunt dus "instanceof IArmour" gebruiken.

Dan is het nog steeds mogelijk om overal armour van te maken of nieuwe armours toe te voegen aan je spel, zonder al die instanceof's te gaan veranderen. Laat het IArmour implementeren en het werkt. Voor je rugzak zou je dan een Container interface kunnen maken die een "getObjectsOfType(Class type)" heeft.

Op die manier kun je zoiets doen:

Java:

interface IArmour {
}

interface IContainer {
  public int countObjectsOfType( java.lang.Class type );
}

class Rugzak implements IContainer {
  public int countObjectsOfType( java.lang.Class type ) {
    int count=0;

    for each eenObject in deze rugzak {
      if(type.isInstance(eenObject)) {
        count++;
      } else if(eenObject instanceof IContainer) {
        count+=((IContainer)eenObject).countObjectsOfType(type);
      }
    }
  }

  return count;
}

class Speler implements IContainer {
  ...
}

class Spel {
  public telAantalArmours() {
    System.out.println(Speler.countObjectsOfType(IArmour.class));
  }
}

instanceof gebruik je dan nog steeds, maar je hoeft niet steeds de instanceof bij te werken als een ander object wat armour gaat geven aan de speler. Je hoeft je containers niet van tevoren te weten (alles kun je een container maken) en je hebt ook geen aparte methods nodig voor alle soorten voorwerpen. Je kunt net zo makkelijk containers of wapens tellen als armours (ok, niet met deze code, dan tel je te weinig containers).

[ Voor 16% gewijzigd door Gerco op 23-05-2006 14:05 ]

[Verwijderd]

Om mezelf maar even te quoten:

Verwijderd schreef op dinsdag 23 mei 2006 @ 11:59:
Een interfaceje met daarin een methode "int itemCount()"
Al je relevante classes dat interfaceje laten implementeren. En de exacte telling dus overlaten aan de concrete implementaties... Voila

Oftewel:

code:

interface Countable {
    int count();
}

class Armor implements Countable {
   int count() {
      return 1;
   }
}

class Bagpack implements Countable {
   int count() {
      int count = 0;
      for(Countable c: countables) count += c.count();
      return count;
   }
}

[Gerco]

@mark platvoet:
Op die manier kun je alleen het totaal aantal Countables in een andere Countable bepalen, niet het aantal Armours. Als je wapens ook wilt counten, moet je het weer gaan veranderen.

[Verwijderd]

Waarom wil je de armor in de backpack ook mee laten tellen?
Alleen wat hij aan heeft telt toch alleen maar?

Denk dat je anchor constructie rammelt.
Je weet toch al dat iemand armor draagt en de rest in een backpack heeft.
Maak dan 2 lijsten gebaseerd op dezelfde klasse waar items ook gebaseerd op een gemeenschappelijke klasse in kunnen. Een wearing lijst en een carrying lijst bijv. Met elk hun toegevoegde specifieke implementatie.
En zoals anderen voorheen al zeiden een aparte lijst voor je armor kan ook al metteen een totaalsom bevatten als extra attribuut. En is ook handiger om uit te breiden later als je verschillende type damage en modifiers gaat gebruiken.
Interface gebruiken doe je juist voor de klasse die instanties van een van beide klassen wilt gaan benaderen en zullen die klassen implementaties zijn van een interface of interfaces. Interfaces kun je ook laten overerven als je dat makkelijker lijkt.

Dit als aanvulling op wat Mark postte.

[Knutselsmurf]

Maar je kunt dan toch datgene dat je wilt tellen als parameter meegeven?

code:

interface Countable {
    int count( string item);
}

class Armor implements Countable {
   int count(string item) {
      (if item=="Armor") {return 1;} else {return 0;}
   }
}

class Bagpack implements Countable {
   int count(string item) {
      int count = 0;
      for(Countable c: countables) count += c.count(item);
      return count;
   }
}

Mijn java-skill zijn heel beperkt, maar ik hoop dat de bedoeling duidelijk is

[Verwijderd]

Gerco schreef op dinsdag 23 mei 2006 @ 14:11:
@mark platvoet:
Op die manier kun je alleen het totaal aantal Countables in een andere Countable bepalen, niet het aantal Armours. Als je wapens ook wilt counten, moet je het weer gaan veranderen.

Ik post het enkel als patroon, niet als concrete implementatie. Om het een stapje dichter bij een conctrete implementatie te gooien.
- Een duidelijke interface naam
- Een instanceof check of het van een dergelijke interface is (let op dit lijstje groeit nu niet)
- Logica van tellen verplaatsen naar diegene die er iets over weten

En als je echt helemaal af wilt van instanceof meuk, dan pas je het Visitor Pattern toe.

[Nick The Heazk]

Verwijderd schreef op dinsdag 23 mei 2006 @ 14:13:
Waarom wil je de armor in de backpack ook mee laten tellen?
Alleen wat hij aan heeft telt toch alleen maar?

De bedoeling/opgave is dat de held maximaal 2 armors met zich kan meedragen. Deze armors mogen echter eender waar zitten. In zijn anchors (handen, rug, hoofd, whatever) of in backpacks (die op hun beurt in eender welke achor kunnen zitten). De held is ook niet verplicht om een armor te dragen.

[Gerco]

Verwijderd schreef op dinsdag 23 mei 2006 @ 14:19:
- Een instanceof check of het van een dergelijke interface is (let op dit lijstje groeit nu niet)

Wel toch? Anders kun je geen verschil maken tussen "Weapon implements Countable" en "Armor implements Countable". Ze zijn allemaal Countable en tellen dus mee. Als je een verschil wilt maken tussen die dingen, moet je nog steeds meerdere Interfaces gebruiken.

[Verwijderd]

@Gerco:
de bedoeling is toch het tellen van Armor?
Ik zou dus een interface Armor (oid) maken die de methode count heeft. Alle items die door kunnen gaan als Armor implementeren deze interface. Of dat dus een rugzakkie is of een magnum .7 half automaat, dat maakt niet uit.

Een container implementatie, zoals rugzak, hoeft zodoende enkel te controleren of de items in zijn rugzak van het type Armor is en zodoende de count methode daarover aanroepen. Zodoende houd je maar 1 instanceof, die je niet meer hoeft uit te breiden.

[Gerco]

Verwijderd schreef op dinsdag 23 mei 2006 @ 14:29:
@Gerco:
de bedoeling is toch het tellen van Armor?

Nu wel ja, en morgen?

Zodoende houd je maar 1 instanceof, die je niet meer hoeft uit te breiden.

Over dat niet meer uitbreiden heb ik zo mijn twijfels. Ik kan me zomaar voorstellen dat de held morgen of volgende week een beperkt aantal wapens, food items of rugzakken bij zich mag dragen.

[Verwijderd]

Gerco schreef op dinsdag 23 mei 2006 @ 14:32:
Over dat niet meer uitbreiden heb ik zo mijn twijfels. Ik kan me zomaar voorstellen dat de held morgen of volgende week een beperkt aantal wapens, food items of rugzakken bij zich mag dragen.

Het gaat TS volgens mij om tellen van Armors en de eventuele uitbreidingen van type Armor. Tenminste, zo heb ik het begrepen. Op deze manier zal voor je Armor het instanceof lijstje niet meer groeien, dat is gewoon een feit.

Als het gaat om andere type items tellen dan is een andere aanpak gewenst (als je dolgraag af wilt van instanceof). Zoals bijvoorbeeld het visitor pattern.

[Gerco]

Daar heb je uiteraard gelijk in mark platvoet. Ik zat aan een ander soort uitbreidbaarheid te denken dan jij en wat betreft het uitbreiden van het aantal en soort Armours hoeft dat inderdaad niet meer.

[The - DDD]

Inderdaad gewoon marken met een Armor interface en tellen met instanceof.

Een groot deel van de andere suggesties krijg ik de bibbers van.

Een methode die 0 of 1 terug geeft naar gelang het een armor is. Niet doen als je het mij vraagt, dat wordt pas niet onderhoudbaar.

Een statische collection bijhouden met references naar alle instanties. Lost niet het probleem op, en de finalize methode gebruiken werkt niet. Immers de lijst wijst nog naar het object en zodoende zal het object nooit gefinalized worden.

Sowieso is kunst en vliegwerk voor het tellen van objectreferenties een beetje overbodig. Immers het is een simpel lineair probleem, dus waarom moeilijk doen als je het waarschijnlijk toch niet efficienter kunt doen. Ergens zal toch bepaald moeten worden of iets van een bepaald type is, hetzij expliciet hetzij impliciet.

Als je echt flexibel wilt zijn dan maak je wel een Backpackable interface. Met daarop een methode waarmee je het item gewicht kunt uitvragen. Dit kun je dan weer leuk combineren met de draagkracht van je hero. Zodoende kan een held tenminste een beetje realistisch 3 zwaarden of 50 kilo kruiden meeslepen. Kan iets in de rugtas? Dan implementeert het Backpackable, enkel nog even kijken hoe zwaar het item is om te zien of de tas niet al vol zit. De Backpack beschikt dan over een lijst met Backpackable items. Slechts een suggestie.

[Verwijderd]

De bedoeling/opgave is dat de held maximaal 2 armors met zich kan meedragen. Deze armors mogen echter eender waar zitten. In zijn anchors (handen, rug, hoofd, whatever) of in backpacks (die op hun beurt in eender welke achor kunnen zitten). De held is ook niet verplicht om een armor te dragen.

Zeker een programmeeropdracht he. Die gasten kunnen van die lekkere kromme regels bedenken altijd.
Je instanceof verhaal werkt wel en is redelijk rechtoerechtaan.
Je zou kunnen beargumenteren dat de max van 2 armor voor de held geldt en het dus een attribuut van die held maken en als hij een item pakt/dropt via een instanceof uitvragen of het armor is adhv een constante MAX waarde van die klasse. Want dan kun je die check van max al metteen in je pak methode stoppen. En scheelt weer een lijstdoorfietsen om te tellen.

[JKVA]

Ik snap niet waarom je het uberhaupt zo wil oplossen. Referenties tellen kan niet, want als je er dan eentje verwijdert, klopt het niet meer, aangezien je geen destructor hebt.

Finalize werkt ook niet, want je weet niet zeker of die gedraaid wordt wanneer een object gedelete wordt. (misschien zelfs pas wanneer je het programma afsluit)

Bovendien, waarom de moeilijke oplossing? Je houdt die armors toch bij in een Collection of als Decorator ofzo? Bij de eerste is het niks meer dan collection.size() en bij de tweede kun je het ook bepalen.

Ps. Ik heb niet helemaal alles gelezen, maar zag zo snel niet waarom deze oplossing niet kan. Tis iig redelijk standaard Java.

[writser]

Er zijn in elk geval genoeg oplossingen gegeven ondertussen. De oplossing die je uiteindelijk kiest hangt af van je precieze doel. Dat komt uit je posts nog niet helemaal naar voren. Wil je alleen Armors bijhouden? Of generalizeren naar alle item? Wil je alleen aantallen bijhouden? Of ook de instanties van objecten zelf kunnen bereiken? Wordt deze methode alleen ter initialisatie aangeroepen? Of in elk frame van je spel?etc.

[Cuball]

offtopic:
aan ts misschien is handig om er een boek over design patterns op na te slaan (gof), staat vol mooie patterns die je wellicht goed zal kunnen gebruiken in het verder verloop van je spel. Als ik instanceof zie in code dan krijg ik altijd al een kriebel in men maag, en dat is 'meestal' een teken dat er iets verkeerd is met design

[Verwijderd]

Cuball schreef op dinsdag 23 mei 2006 @ 20:49:

offtopic:
Als ik instanceof zie in code dan krijg ik altijd al een kriebel in men maag, en dat is 'meestal' een teken dat er iets verkeerd is met design

offtopic:
Cuball krijgt behoorlijke kriebels van equals methodes
(ja ik heb je aanhalingstekens gezien)

[.oisyn]

IceManX schreef op dinsdag 23 mei 2006 @ 13:56:
[...]
Java heeft geen expliciete destructors. In plaats daarvan zul je de finalize() method moeten overriden:

Java:

protected void finalize() throws Throwable {
    allInstances.remove(this);
    super.finalize();
}

Leuk bedacht, maar dat gaat natuurlijk niet werken . Ten eerste is de destruction in java niet deterministisch, de finalize wordt pas aangeroepen als de garbage collector heeft besloten dat het object opgeruimd kan worden (dit kan heel lang duren, of zelfs pas gebeuren als je de applicatie afsluit). Daarnaast zal de garbage collector het object sowieso nooit opruimen aangezien er nog een referentie naar het object bestaat in de allInstances container. Als je het op die manier wilt aanpakken zul je dus zelf tegen het object moeten zeggen dat hij niet meer nodig is.

Dit illustreert overigens mooi dat memory leaks weldegelijk in Java bestaan, en dat het dus van belang is dat je bij dergelijke concepten weak references gebruikt.

[ Voor 10% gewijzigd door .oisyn op 23-05-2006 23:18 ]

[The - DDD]

.oisyn schreef op dinsdag 23 mei 2006 @ 23:15:
[...]

Leuk bedacht, maar dat gaat natuurlijk niet werken . Ten eerste is de destruction in java niet deterministisch, de finalize wordt pas aangeroepen als de garbage collector heeft besloten dat het object opgeruimd kan worden (dit kan heel lang duren, of zelfs pas gebeuren als je de applicatie afsluit). Daarnaast zal de garbage collector het object sowieso nooit opruimen aangezien er nog een referentie naar het object bestaat in de allInstances container. Als je het op die manier wilt aanpakken zul je dus zelf tegen het object moeten zeggen dat hij niet meer nodig is.
...

Eindelijk iemand die het ook ziet.

[Verwijderd]

The - DDD schreef op woensdag 24 mei 2006 @ 09:14:
Eindelijk iemand die het ook ziet.

offtopic:
pluim? veer? lintje? ....nee? wat anders dan?

[.oisyn]

The - DDD schreef op woensdag 24 mei 2006 @ 09:14:

Eindelijk iemand die het ook ziet.

Alleen jammer dat niemand daarbij een woord heeft gerept over weak references.

[The - DDD]

Ghehe, ik dacht er wel aan, maar dat noemen is vragen om problemen.

[Robtimus]

.oisyn schreef op dinsdag 23 mei 2006 @ 23:15:
[...]

Leuk bedacht, maar dat gaat natuurlijk niet werken . Ten eerste is de destruction in java niet deterministisch, de finalize wordt pas aangeroepen als de garbage collector heeft besloten dat het object opgeruimd kan worden (dit kan heel lang duren, of zelfs pas gebeuren als je de applicatie afsluit). Daarnaast zal de garbage collector het object sowieso nooit opruimen aangezien er nog een referentie naar het object bestaat in de allInstances container. Als je het op die manier wilt aanpakken zul je dus zelf tegen het object moeten zeggen dat hij niet meer nodig is.

Dit illustreert overigens mooi dat memory leaks weldegelijk in Java bestaan, en dat het dus van belang is dat je bij dergelijke concepten weak references gebruikt.

Dat had ik later ook door (dankzij The - DDD), maar ik gaf dan ook de best mogelijke vertaling van de destructor.