[java] String converteren naar object

[EnsconcE]

Misschien maak ik hier wel een beginnersfout maar ik kom er niet uit. Op het internet heb ik verschillende oplossingen gevonden waaronder het gebruik van een tokenizer. De meest logische oplossing leek mij de volgende:

Java:

String word = command.getSecondWord();
String temp = currentRoom.getItem(word);
item = (Item) Class.forName(temp);

De getSecondword retourneerd een string, de getItem retourneerd de naam van het object en het item moet het object worden. De classe heet Item en zijn aangemaakt als volgt:

Java:

naamvanitem = new Item(String,int)

en vervolgens met naam in de klasse Room gestopt. Hier haal ik ze dus uit met

Java:

currentRoom.getItem(string)

Bij alles wat ik probeer geeft hij inconvertible types. En dat komt volgens mij omdat command.getSecondWord() er een string van maakt. Ik ben hier al twee dagen mee bezig maar boek geen enkele vooruitgang.

[Apie!]

Class.forName geetf een Class terug, geen object...

[EnsconcE]

Apie! schreef op donderdag 22 december 2005 @ 14:09:
Class.forName geetf een Class terug, geen object...

Ok, maar hoe moet ik het dan doen?

[Apie!]

search op Google: Class.forName

leverde me o.a. deze link op: http://www.javageeks.com/Papers/ClassForName/index.html

[Janoz]

Waarom maak je voor currentRoom niet gebruik van een Map?

[EnsconcE]

Je zegt net al dat ik er niks aan heb aangezien hij een Class retourneerd, ik moet een variabele hebben die ik als object kan gebruiken. Zie item = (Item) variabele. Dan heb ik toch niks aan Class.forName()?

[EnsconcE]

Janoz schreef op donderdag 22 december 2005 @ 14:13:
Waarom maak je voor currentRoom niet gebruik van een Map?

Omdat dat niet nodig is, die currentRoom is een variabele gekoppeld aan een object die al goed werkt. Item zou ook zo moeten werken. Als ik van currentRoom een map zou maken dan zou ik weer met hetzelfde probleem zitten als met item. Ik kan van een variabelen geen objecten maken, dat is mijn probleem.

[Janoz]

Een variabele IS een object tenzij je het over primitiven hebt. Daarnaast zeg ik niet dat je van currentRoom een map moet maken, maar dat je een map moet gebruiken.

Verder vermoed ik dat je daadwerkelijk een Map nodig hebt. Een room bevat items neem ik aan. Je wilt graag zo'n item terug krijgen. Elk item heeft een naam en je wilt per naam een item terug krijgen. Die naam gebruik je dus als key. Hieruit kan ik weinig anders concluderen dan het gebruik van een map.

Ik ben trouwens erg benieuwd hoe je Item en je Room class eruit zien.

[Apie!]

EnsconcE schreef op donderdag 22 december 2005 @ 14:15:
Je zegt net al dat ik er niks aan heb aangezien hij een Class retourneerd, ik moet een variabele hebben die ik als object kan gebruiken. Zie item = (Item) variabele. Dan heb ik toch niks aan Class.forName()?

ehm...ik zei niet dat je er niks aan hebt. Ik gaf je de stille hint dat Class.forName geen Object maar een Class teruggeeft. Ik had eigenlijk de hoop dat je dan wat javadoc zou gaan lezen. Ik gaf je zelfs een link waarin jouw probleem volgens mij wordt uitgelegd.

Als je de eerste pagina van de pdf op die site had bekenen, dan had je geweten dat je mbv Class.forName wel degelijk dynamisch classes kan laden, maar niet met Class.forName op zich. Je zult iets meer moeten doen. Ik kan hier de code wel posten, maar imo moet je dingen lezen en begrjipen voordat je ze toe gaat passen. Op pagina 2 staat zelfs een bruikbaar stukje code. Ik geef je nog een stille hint: java.lang.reflect

Verder sluit ik me bij Janoz aan en vraag ik me af of je met dynamic classloading aan de gang wilt of met dynamic classloading aan de gang moet omdat je een ontwerpfoutje hebt gemaakt.

[mcB]

Misschien dat je je startpost eens wat completer moet maken. Ik heb namelijk geen idee wat je wil bereiken met je code.
Wat ik wel zie is dat je een referentie naar een Item wilt ophalen aan de hand van een waarde opgeslagen in datzelfde Item. Dat gaat je niet lukken op de huidige manier, maar daar was je zelf ook al achter.

Aangezien je de Items heb aangemaakt bestaan ze ergens. Ergens heb je de referenties er naar opgeslagen. Daar waar die referenties opgeslagen zijn moet je de items stuk voor stuk bij langs om te kijken of de String waarde van het Item gelijk is aan de String die je zoekt.

[Nick_S]

Ik snap niet helemaal wat je bedoeld, maar het lijkt erop, dat je een Object terug krijgt uit currentRoom die je wilt converteren naar Item.

Java:

final Object temp = currentRoom.getItem(word);
final Item item = (Item) temp;

Als ik je bedoeling verkeerd begrepen heb, moet je het nog maar een keer proberen uit te leggen.

[EnsconcE]

Janoz schreef op donderdag 22 december 2005 @ 14:22:
Een variabele IS een object tenzij je het over primitiven hebt. Daarnaast zeg ik niet dat je van currentRoom een map moet maken, maar dat je een map moet gebruiken.

Verder vermoed ik dat je daadwerkelijk een Map nodig hebt. Een room bevat items neem ik aan. Je wilt graag zo'n item terug krijgen. Elk item heeft een naam en je wilt per naam een item terug krijgen. Die naam gebruik je dus als key. Hieruit kan ik weinig anders concluderen dan het gebruik van een map.

Ik ben trouwens erg benieuwd hoe je Item en je Room class eruit zien.

m'n room ziet er als volgt uit, let niet op de combinatie nl engels

Java:

import java.util.Set;
import java.util.HashMap;
import java.util.Iterator;
import java.util.ArrayList;

public class Room 
{
    private String description;
    private HashMap exits;
    private ArrayList items;

    /**
     * Create a room described "description". Initially, it has
     * no exits. "description" is something like "a kitchen" or
     * "an open court yard".
     */
    public Room(String description) 
    {
        this.description = description;
        exits = new HashMap();
        items = new ArrayList();
    }

    /**
     * Define the exits of this room.  Every direction either leads
     * to another room or is null (no exit there).
     */
    public void setExits(String direction, Room neighbour) 
    {
        exits.put(direction, neighbour);
    }
    
    /**
     * Definieer de items voor de kamer
     */
    public void addItem(String description)
    {
        items.add(description);
    }
    
    /**
     * Het verkrijgen van de uitgangen van de kamer
     */
    public Room getExit(String direction)
    {
        return (Room)exits.get(direction);
    }

    /**
     * Return the description of the room (the one that was defined
     * in the constructor).
     */
    public String getDescription()
    {
        return description;
    }

    /**
     * Retourneer een string met daarin de uitgangen van de ruimte,
     * bijvoorbeeld "Uitgangen: noord west".
     */
    public String getExitString()
    {
        String returnString = "Exits:";
        Set keys = exits.keySet();
        for(Iterator iter = keys.iterator(); iter.hasNext(); ) {
            returnString += " " + iter.next();
        }
        return returnString;
    }
    
    /**
     * Retourneer een string met daarin de items in de ruimte
     * bijvoorbeeld "Items: item1 item2
     */
    public String getItemsString()
    {
        String returnString = "Items:";
        int aantal = items.size();
        for(int i = 0; i < aantal; i++) {
            returnString = returnString + " " + items.get(i);
        }
        return returnString;
    }
    
    public String getItem(String item)
    {
        String returnString = null;
        int aantal = items.size();
        
        for(int i = 0; i < aantal; i++) {
            String temp = (String)items.get(i);
            if(item.equals(temp)) {
                returnString = item;
            }
            else {
                returnString = null;
            }
        }
        return returnString;
    }
    
    /**
     * Retourneerd een lange omschrijving van deze ruimte, in de vorm:
     * Je bent in de keuken.
     * Uitgangen: noord west
     */
    public String getLongDescription()
    {
        return "You are " + description + ".\n" + getExitString () + ".\n" + getItemsString ();
    }
}

en m'n item ziet er als volgt uit

Java:

public class Item
{
    private String description;
    private int weight;

    /**
     * Het item krijgt hierbij een omschrijving en gewicht.
     */
    public Item(String description, int weight)
    {
        this.description = description;
        this.weight = weight;
    }

    public String getDescription()
    {
        return description;
    }
    
    public String getWeight()
    {
        return "" + weight;
    }
}

alle 2 worden aangemaakt in de classe game, die vervolgens het item in de desbetreffende kamer stopt. Als je dus in een kamer komt, moet je een item kunnen pakken. Dit gebeurt in de classe player:

Java:

import java.util.Stack;
import java.util.ArrayList;

public class Player
{
    private Stack history;
    private Room currentRoom;
    private Item item;
    private ArrayList items;
    private String length;
    private int maxWeight;

    /**
     * Geef een bescrijving aan de speler mee.
     */
    public Player()
    {
        currentRoom = null;
        item = null;
        history = new Stack();
        items = new ArrayList();
    }
    
    public void setProperties(int maxWeight)
    {
        this.maxWeight = maxWeight;
    }
    
    /**
     * Zet de speler in een nieuwe kamer.
     */
    public void setCurrentRoom(Room nextRoom)
    {
        currentRoom = nextRoom;
    }
    
    /**
     * Verander de speler van kamer en retourneer of het gelukt is
     * zo ja, geef dan de volledige beschrijving van de kamer mee.
     */
    public String goNextRoom(Command command)
    {
        if(!command.hasSecondWord()) {
            // if there is no second word, we don't know where to go...
            return "Go where?";
        }

        String direction = command.getSecondWord();

        // Try to leave current room.
        history.push(getCurrentRoom());
        Room nextRoom = currentRoom.getExit(direction);

        if (nextRoom == null) {
            return "There is no door!";
        }
        else {
            setCurrentRoom(nextRoom);
            return getCurrentRoomLongDescription();
        }
    }

    /**
     * De volgende retourneerd een waarde wanneer je een kamer terug wil
     * deze is opgeslagen in de history Stack.
     */
    public String goBackRoom()
    {
        if (!history.empty()) {
            setCurrentRoom((Room)history.peek());
            history.pop();
            return getCurrentRoomLongDescription();
        }
        else {
            return "You are at the start!";
        }
    }
    
    /**
     * Retourneerd de volledige beschrijving van de kamer
     * waar de speler zich bevind.
     */
    public String getCurrentRoomLongDescription()
    {
        return currentRoom.getLongDescription();
    }
    
    /**
     * Retourneerd de naam van de kamer
     * waar de speler zich bevind.
     */
    public Room getCurrentRoom()
    {
        return currentRoom;
    }
    
    public String take(Command command)
    {
        String returnString = "";
        
        if(!command.hasSecondWord()) {
            // if there is no second word, we don't know where to go...
            returnString = "Take what?";
        }
        else {
            String word = command.getSecondWord();
            String temp = currentRoom.getItem(word);
            item = (Item) Class.forName(temp);
        }
        return returnString;
    }
    
    public String showItems()
    {
        String returnString = "";
        int aantal = items.size();
        
        for(int i = 0; i < aantal; i++) {
            returnString += items.get(i);
        }
        return returnString;
    }
}

De player wordt ook aangemaakt in de classe game. Ik ga nu even het pdf document doorlezen, kijken of ik het kan toepassen.

[Mastermind]

Wil je een object maken met de waarde van een string?
Bijv.
String woord = "foo";
String temp = "bar";
Item (Object)temp.getValue = new Item();
// zodat je krijgt: Item bar = new Item();
bar.bla(woord,10);

??

[Janoz]

Hmm ... Vreemd.... Waarom wordt er in dit hele project met strings heen en weer gegooid ipv objecten? Op deze manier kun je natuurlijk nooit het daadwerkelijke item object krijgen en zul je zelf een nieuwe instantie van het item moeten maken. Echter kun je op die manier nooit het gewicht achterhalen.

Ikzelf zou verwachten dat getItem een item zou returnen ipv een string.

[zneek]

Als je nou in Room eens items verandert in

Java:

    private Map items;

En die in je constructor als volgt aanmaakt:

Java:

        items = new HashMap();

En de setItem en getItem als volgt aanpast

Java:

public void setItem(Item i)
{
  items.put(i.getDescription(), i);
}

public Item getItem(String description)
{
  return (Item)items.get(description); 
}

Dan kun je in Player dit doen

Java:

public String take(Command command) 
    { 
        String returnString = ""; 
         
        if(!command.hasSecondWord()) { 
            // if there is no second word, we don't know where to go... 
            returnString = "Take what?"; 
        } 
        else { 
            String word = command.getSecondWord(); 
            item = currentRoom.getItem(word); 
        } 
        return returnString; 
    } 

Uiteraard hier en daar te voorzien van nullchecks. Als je nu een niet bestaand item probeert te "taken" dan zal Player.item null zijn na aanroep van take();

Of begrijp ik nou gewoon niet wat je eigenlijk wilt bereiken?

[ Voor 3% gewijzigd door zneek op 23-12-2005 08:30 ]

[Confusion]

Als je het op je oorspronkelijke manier wilt doen, dan zou je een lusje moeten schrijven dat de string temp vergelijkt met de description van alle bestaande items, om vervolgens te zeggen Item item = matchingItem. Maar zoals anderen al aangeven is het rondpasseren van strings terwijl de 'real life' objecten items zijn erg onhandig.

[H!GHGuY]

Java:

Class.forName(name).getConstructor(new Class[] { String.class, Integer.class }).newInstance(new Object[] { stringParameter, integerParameter });

dit is wat jij zoekt. (eventueel kan het zijn dat die 2de parameter niet van het type Integer moet zijn)

een andere mogelijkheid is zoals hierboven al aangehaald

Java:

MyItem
{
   MyItem(String a, int b) {...}
}

interface MyFactory
{
   Object newInstance(String a, int b);
}

MyItemFactory implements MyFactory
{
    public Object newInstance(String a, int b) { return new MyItem(a,b); }
}

Hashmap<String, Object> map = new Hashmap<String, Object>();
map.add("MyItem", new MyItemFactory());
...
...
MyFactory f = (MyFactory)map.get(MyValue);
if (f != null)
   Object o = f.newInstance(myString, myInt);

note: alles uit de losse pols

[ Voor 5% gewijzigd door H!GHGuY op 23-12-2005 09:42 ]

[Janoz]

HIGHGuY schreef op vrijdag 23 december 2005 @ 09:42:

Java:

Class.forName(name).getConstructor(new Class[] { String.class, Integer.class }).newInstance(new Object[] { stringParameter, integerParameter });

dit is wat jij zoekt. (eventueel kan het zijn dat die 2de parameter niet van het type Integer moet zijn)

Dat is wat hij vraagt, niet wat hij zoekt . Maar dat komt natuurlijk omdat hij de verkeerde vraag stelt.

[Knowuse]

In de getItem methode zou je nog even een break in je for loop moeten zetten. Anders wordt er altijd null gereturned als je te vinden item niet als laatste in de lijst staat.

Java:

 
public String getItem(String item)
    {
        String returnString = null;
        int aantal = items.size();
        
        for(int i = 0; i < aantal; i++) {
            String temp = (String)items.get(i);
            if(item.equals(temp)) {
                returnString = item;
            }
            else {
                returnString = null;
            }
        }
        return returnString;
    } 

[H!GHGuY]

Knowuse schreef op vrijdag 23 december 2005 @ 13:13:
In de getItem methode zou je nog even een break in je for loop moeten zetten. Anders wordt er altijd null gereturned als je te vinden item niet als laatste in de lijst staat.

Java:

 
public String getItem(String item)
    {
        String returnString = null;
        int aantal = items.size();
        
        for(int i = 0; i < aantal; i++) {
            String temp = (String)items.get(i);
            if(item.equals(temp)) {
                returnString = item;
            }
            else {
                returnString = null;
            }
        }
        return returnString;
    } 

break = bad programming habbit...

een return binnen een for-loop voor efficientie redenen eigenlijk ook, maar het is wel duidelijker en mooier.

[Confusion]

HIGHGuY schreef op vrijdag 23 december 2005 @ 13:18:
een return binnen een for-loop voor efficientie redenen eigenlijk ook, maar het is wel duidelijker en mooier.

Wanneer heb jij voor het laatste een programma geschreven waarbij efficientie een probleem was en dit soort minimaatregelen de doorslag gaven? Als een return mooie leesbare code geeft, ga dan in godsnaam voor de return en niet voor de halve milliseconde tijdswinst.

[bigbeng]

HIGHGuY schreef op vrijdag 23 december 2005 @ 13:18:
[...]


break = bad programming habbit...

...

Waarom? Kun je dit onderbouwen?

Confusion schreef op vrijdag 23 december 2005 @ 13:36:
[...]

Wanneer heb jij voor het laatste een programma geschreven waarbij efficientie een probleem was en dit soort minimaatregelen de doorslag gaven? Als een return mooie leesbare code geeft, ga dan in godsnaam voor de return en niet voor de halve milliseconde tijdswinst.

Halve milliseconden? Dat hangt er een beetje vanaf wat er allemaal gebeurt in 1 iteratie en van het aantal iteraties. Ik kan me voorstellen dat in dit geval er weinig tijdswinst te behalen valt, maar bij grotere lijsten waar je doorheen loopt kan het wel degelijk schelen. Zeker als er string vergelijkingen worden gedaan. Persoonlijk vind het het fraaier om een loop te stoppen zodra je gevonden hebt wat je zocht, dit zou on average (uitgaande van een gelijkmatige uitvraging van je lijst) een snelheidswinst van 50% bewerkstelligen t.o.v. de loop door laten gaan. Nou zijn er natuurlijk ook andere methoden om snel gegevens uit je lijst te halen, bijvoorbeeld het gebruik van een Collection die geoptimaliseerd is voor het doorzoeken ipv een array, maar das weer een andere discussie

[Nick_S]

Dan kun je beter je loop aanpassen ipv. een break gebruiken.

code:

for (int i = 0; i < list.length || returnValue != null; i++) {
//do your stuff
}

Ik heb ook geleerd dat break bad practice is.

[EnsconcE]

zneek schreef op vrijdag 23 december 2005 @ 08:30:
Als je nou in Room eens items verandert in

Java:

    private Map items;

En die in je constructor als volgt aanmaakt:

Java:

        items = new HashMap();

En de setItem en getItem als volgt aanpast

Java:

public void setItem(Item i)
{
  items.put(i.getDescription(), i);
}

public Item getItem(String description)
{
  return (Item)items.get(description); 
}

Dan kun je in Player dit doen

Java:

public String take(Command command) 
    { 
        String returnString = ""; 
         
        if(!command.hasSecondWord()) { 
            // if there is no second word, we don't know where to go... 
            returnString = "Take what?"; 
        } 
        else { 
            String word = command.getSecondWord(); 
            item = currentRoom.getItem(word); 
        } 
        return returnString; 
    } 

Uiteraard hier en daar te voorzien van nullchecks. Als je nu een niet bestaand item probeert te "taken" dan zal Player.item null zijn na aanroep van take();

Of begrijp ik nou gewoon niet wat je eigenlijk wilt bereiken?

Ja je zit in de buurt, ik heb het alleen anders gedaan(of eigenlijk mijn projectgroepgenoot).

Java:

    public String getItem(String searchItem)
    {
        String returnString = "Item not found";
        int index = currentRoom.findItem(searchItem);
        
        if(index >= 0) {
            Item item = currentRoom.getItem(index);
            int weigth = item.getWeight();
            
            if(canPickUp(weigth)) {
                items.add(item);
                currentRoom.removeItem(index);
                returnString = "The " + searchItem + " is picked up.";
            }
            else {
                returnString = "You are to heavy packed at the moment";
            }
        }
        return returnString;
    }

waarbij deze methode wodt aangeroepen in de classe Room:

Java:

    public int findItem(String itemName)
    {
        int index=-1;
        String name="";
        
        for(int i=0; i < items.size(); i++){
            Item item = (Item)items.get(i);
            name = item.getName();
            if(name.equals(itemName)){
                index = i;
            }
        }
        return index;
    }
    
    public Item getItem(int index)
    {
        Item item = (Item)items.get(index);
        return item;
    }
    
    public void removeItem(int index)
    {
        items.remove(index);
    }

en nu is mijn hele euvel omzeilt omdat de naam van het item in de item zelf opgeslagen wordt. Dit was ook mijn eerste idee, maar heb het niet gedaan vanwege het gebruik van 1 woord 2x. En wat jij zei Janoz over het heen en weer gegooi van strings, de reden dat ik dat deed was omdat een string wel te vergelijken was met die command.getSecondWord(). In m'n huidige versie worden de objectnamen in de arraylist gestopt i.p.v. dat deze naam eerst wordt omgezet naar een string.

Nick_S schreef op vrijdag 23 december 2005 @ 15:57:
Dan kun je beter je loop aanpassen ipv. een break gebruiken.

code:

for (int i = 0; i < list.length || returnValue != null; i++) {
//do your stuff
}

Ik heb ook geleerd dat break bad practice is.

je kan ook dit doen:

Java:

for (int i = 0; i < list.length; i++) {
//do your stuff
    i = list.length;
}

met een if statement natuurlijk, maar of dat nou een goede oplossing is weet ik niet, het werkt iig wel en snel.

[ Voor 3% gewijzigd door EnsconcE op 23-12-2005 17:43 ]

[H!GHGuY]

break is uit het tijdperk van BASIC en vroege C afaik...

break, goto enz geven sneller aanleiding tot spaghetti-code...
We zagen op de hogeschool vorig jaar een optimalisatie van een recursieve functie dmv goto, break en andere... (recursie werd eruit gehaald)
uiteindelijk was die functie 100% onleesbaar, maar "correct"

meer dan 1 controle wordt ook afgeraden binnen een for-loop, hoewel een kleine boolean of 1 extra testje het geheel meestal niet onleesbaarder maakt. bovendien verwacht een programmeur die code leest dat een for van de vorm
for (int i = 0; i < waarde; i++)
is en zal die bij een extra controle in de for-lus er zo goed als zeker over kijken.

Wanneer heb jij voor het laatste een programma geschreven waarbij efficientie een probleem was en dit soort minimaatregelen de doorslag gaven? Als een return mooie leesbare code geeft, ga dan in godsnaam voor de return en niet voor de halve milliseconde tijdswinst.

excuseer, dat is net wat ik zeg:

C++:

for (int i = 0; i < 1000000; i++)
{
  if (strings[i] == "blah")
     return i;
}

vind ik net iets performanter als

C++:

for (int i = 0; i < 1000000; i++)
{
  if (strings[i] == "blah")
     retval = i;
}
return retval;

en net iets mooier als

C++:

for (int i = 0; i < 1000000; i++)
{
  if (strings[i] == "blah")
  {
     retval = i;
     break;
  }
}
return retval;

ik gebruik break nooit, ik weet wat het ongeveer doet (breakt uit een for-lus)
maar de vraag is:

code:

for (int i = 0; i < 1000000; i++)
{
   cout<<i<<endl;
   for (int j = 0; j < 1000000; j++)
   {
      cout<<j<<endl;
      if (i%j == 999999)
           break;
   }
   cout<<i<<endl;
}

breakt de for uit beide lussen of enkel uit de binnenste ?
zowiezo vind ik het dus maar wat ambigu, en blijf ik er liever af... je hebt snel spaghetticode, en bovendien is een return binnen een for net iets mooier (je weet nl dat de functie dan direct gedaan is zodat je niet moet lopen zoeken waarheen nu net gebreakt wordt en welke code er dan uitgevoerd wordt (en of die code dan wel geldig is!!)

[ Voor 4% gewijzigd door H!GHGuY op 23-12-2005 20:02 ]

[bigbeng]

Ik kan me iets voorstellen bij het spaghetti-code argument, maar ik vind een break niet hetzelfde als een goto. Dat een return handiger is dan een break, omdat duidelijk is wat er gebeurt kan ik me wel in vinden, maar soms kan het handig zijn om twee for-lussen achterelkaar te doorlopen en dan kan een break weer handig zijn. En natuurlijk kan je zo'n blok dan opsplitsen in meerdere functies. maar ik ben niet zo'n fan van functienesting. Aan de ene kant maakt het code helderder, maar als je op zoek bent naar een bug moet je soms wel flink diep graven voor je bij het werkelijke probleem bent.

Oh ja tenslotten nog even, het vermogen om spaghetticode te creeeren ligt meer aan de programmeur dan aan de taal die hij gebruikt, mits ende tenzij we het hebben over 3+ generatietalen.

offtopic:
ps: waar in basic vind jij een break statement? of was dat alleen voor de goto-analogie?
pps: een break breakt uit de binnenste lus

[Confusion]

HIGHGuY schreef op vrijdag 23 december 2005 @ 20:01:
break is uit het tijdperk van BASIC en vroege C afaik...

Er zijn situaties zijn waarin je niet zonder kan: je krijgt juist totale spaghetti code zonder break of continue, met de ene na de andere test om te kijken of je niet een 'beëindig-lus" vlag moet zetten. Ik ken bijna geen C++, maar in Java is de break eenvoudig: je breakt uit de binnenste lus, tenzij je er de naam van een label achter plakt: dan break je naar het label. Labels mogen alleen bij het begin van een lus staan. Voor continue geldt hetzelfde.

Wat betreft returns zitten we op één lijn denk ik, maar wat dat voorbeeld vooral mist is teolicting, in de vorm van betekenisvolle variabelenamen, constantes en commentaar. De lus is eigenlijk helemaal niet moeilijk:

C++:

// Lust om van elk bankrekeningbedrag tussen 0 en MAX_MONEY te achterhalen 
// in porties van welke grootte je het moet verdelen om REMAINING_MONEY over 
// te houden.
for (int money = 0; money < MAX_MONEY; money++)
{
   for (int portionSize = 0; portionSize < MAX_PORTIONS; portionSize++)
   {
      if (money%portionSize == REMAINING_MONEY) {
         break;
      }
   }
}

Maargoed, het blijft een kunstmatig voorbeeld weinig te redden, die cout's slaan volgens mij helemaal nergens op .

[EnsconcE]

Confusion schreef op vrijdag 23 december 2005 @ 20:57:
[...]

C++:

// Lust om van elk bankrekeningbedrag tussen 0 en MAX_MONEY te achterhalen 
// in porties van welke grootte je het moet verdelen om REMAINING_MONEY over 
// te houden.
for (int money = 0; money < MAX_MONEY; money++)
{
   for (int portionSize = 0; portionSize < MAX_PORTIONS; portionSize++)
   {
      if (money%portionSize == REMAINING_MONEY) {
         break;
      }
   }
}

Maargoed, het blijft een kunstmatig voorbeeld weinig te redden, die cout's slaan volgens mij helemaal nergens op .

Waarom een break als je portionSize gelijk kan maken aan MAX_PORTIONS en je op die manier niet breakt maar de code wel stopt? Daarnaast kun je er ook nog die || van een aantal posts hierboven gebruken. De code blijft overzichtelijk en qua programmeren zijn het nette oplossingen.

[brama]

EnsconcE schreef op zaterdag 24 december 2005 @ 00:04:
[...]


Waarom een break als je portionSize gelijk kan maken aan MAX_PORTIONS en je op die manier niet breakt maar de code wel stopt? Daarnaast kun je er ook nog die || van een aantal posts hierboven gebruken. De code blijft overzichtelijk en qua programmeren zijn het nette oplossingen.

Als je extra condities wilt checken, zou ik eerder een while-loop gebruiken:

C++:

int portionSize = 0;

while (portionSize < MAX_PORTIONS && money%portionSize != REMAINING_MONEY)
{
  portionSize++;
}

Bovendien, portionSize de waarde van MAX_PORTIONS geven lijkt me niet zinnig, aangezien je zeer waarschijnlijk de waarde van portionSize wilt weten na die loop.

[ Voor 13% gewijzigd door brama op 24-12-2005 00:36 ]

[Confusion]

EnsconcE schreef op zaterdag 24 december 2005 @ 00:04:
Waarom een break als je portionSize gelijk kan maken aan MAX_PORTIONS en je op die manier niet breakt maar de code wel stopt?

Ehmm, ik deed een demonstratie van overzichtelijkheid door betekenisvolle variabelenamen en commentaar toe te voegen. Ik heb niet inhoudelijk opgelet of het ook nog daadwerkelijk zinvol was en misschien op een andere manier beter zou kunnen .

[H!GHGuY]

^^ with brama

gebruik liever een while ipv for + break of for met meerdere condities

@confusion:
bovendien kun je je de vraag stellen of je code wel goed geschreven is als ze commentaar vereist om begrepen te worden.
zelfdocumenterende code is meestal beter van kwaliteit ...

let op: ik bedoel het documenteren van de code, niet van het algoritme...

[ Voor 62% gewijzigd door H!GHGuY op 24-12-2005 11:18 ]

[brama]

Nick_S schreef op vrijdag 23 december 2005 @ 15:57:
Dan kun je beter je loop aanpassen ipv. een break gebruiken.

Java:

for (int i = 0; i < list.length || returnValue != null; i++) {
//do your stuff
}

Ik heb ook geleerd dat break bad practice is.

Een paar opmerkingen over die code om een item uit een kamer te getten:

Het doel van classes is om objecten te representeren, waarbij je zo weinig mogelijk aan de gebruikers van die classes laat weten *hoe* de data die bij die objecten hoort opgeslagen wordt.

In dit geval is het daarom niet netjes als je 2 publieke functies hebt om een item op te vragen, nl. eentje om de index bij een string op te zoeken, en eentje om het juiste element adhv de index op te vragen. Een gebruiker van die Room classe wil helemaal niet weten dat zo'n item in een list zit, maar wil gewoon dat item getten!

Ik zou die functies daarom private maken, en een publieke functie maken in class Room:

Java:

public Item getItem(String description)
{
  int idx = findItem(description);

  if (idx == -1)
  {
    return null;
  }

  return getItem(idx);
}

Ik zag dat je al iets dergelijks gemaakt had, maar dan met een string als returnwaarde, en ik zag niet in welke class je die gezet had.

Die oplossing waarbij jij een string als returnwaarde van de functie teruggeeft, is ook niet netjes. Je kunt beter het Item object retourneren, omdat je item later misschien wel veel meer functionaliteit gaat krijgen dan alleen die description. Misschien wel een korte en lange beschrijving, kleur, ... In de code die het Item nodig heeft (bijv. de player), roep je vervolgens gewoon item.getDescription() aan om de omschrijving te krijgen.

Overigens zou ik de items en de room nog anders implementeren. Je wilt namelijks er altijd naar streven om functionaliteit zoveel mogelijk in de class te implementeren waar de functionaliteit om gaat.

In dit geval is de functionaliteit het zoeken naar een object a.d.h.v. een woord wat een user intikt. Nu gaat de room bepalen of een item uit de lijst van items die het heeft matcht. Echter, deze 'matching' code zou ik dus in het item stoppen:

Java:

//we zitten in class item
public boolean matchQuery(String desc)
{
  return this.description.equals(desc));
}

En dan de functie getItem in je room:

Java:

  //class Room implementation, items are now Items in a list, not strings!
  List<Item> Items = new ArrayList();

  //...

  public Item getItem(String desc)
  {
    Iterator<Item> it = Items.iterator();

    while (it.hasNext())
    {
      Item myItem = it.next();
      if (myItem.matchQuery(desc)
      {
        return myItem;
      }
    }

    return null; //item not found
  }

Die <Item> notatie is java 1.5 specifiek (Generics interface), indien je 1.4 gebruikt, gewoon objecten casten naar Item.

Nu je de matching in het item zelf hebt gestopt, kun je later een fatsoelijk match-algoritme implementeren dat niet alleen voor items in een room werkt, maar ook items in je player's inventory (die je vast ook gaat willen hebben . En waarschijnlijk wil je op een gegeven moment ook wel een betere match-implementatie die ook dingen als 'all green apples' snapt.

Wat zijn jullie trouwens aan het maken; een text-RPG of een MUD?

[Confusion]

HIGHGuY schreef op zaterdag 24 december 2005 @ 11:14:
bovendien kun je je de vraag stellen of je code wel goed geschreven is als ze commentaar vereist om begrepen te worden.
zelfdocumenterende code is meestal beter van kwaliteit ...

Dus dat hele Javadoc is maar onzin? Nee, zelfdocumenterende code en commentaar vervullen twee verschillende rollen. Het voordeel van goed commentaar is dat je de code helemaal niet hoeft te lezen om te weten wat bijvoorbeeld een methode doet. Dat scheelt enorm veel tijd. Goede code is ervolgens ook nodig, zodat iemand gemakkelijk de onvermijdelijke bugs in je code kan vinden of er snel aanpassingen in kan doen.

[H!GHGuY]

Confusion schreef op zaterdag 24 december 2005 @ 11:30:
[...]

Dus dat hele Javadoc is maar onzin? Nee, zelfdocumenterende code en commentaar vervullen twee verschillende rollen. Het voordeel van goed commentaar is dat je de code helemaal niet hoeft te lezen om te weten wat bijvoorbeeld een methode doet. Dat scheelt enorm veel tijd. Goede code is ervolgens ook nodig, zodat iemand gemakkelijk de onvermijdelijke bugs in je code kan vinden of er snel aanpassingen in kan doen.

we praten naast elkaar.

jij schreef commentaar bij een for-loop, niet bij een functie...
commentaar bij een functie is good-practice... bij een normale for-loop hoort geen commentaar... dat doe jij net wel met je "break" want je introduceert niet-standaard gedrag. de gemiddelde functie is 90% zelfdocumenterend als ze goed is geschreven.

C++:

// mijnFunctie berekent ....
// parameter1: betekent ....
// parameter2: betekent ....
// opmerking: deze functie maakt gebruik van het algoritme van ...
// meer info over dit algo is te vinden op http://...
int mijnFunctie(int parameter1, int parameter2)
{
    for (...)
   {
      for (...)
      {
           /// .... code
              break;                        // deze break wordt aangeroepen als...
          /// ... code
      }
      /// ... code
      break;     // deze break wordt gebruikt als...
      /// code
   }
   // hier komt men enkel als ...
}

tot en met de functieheader vind ik de functie prima.
dat je echter commentaar nodigt hebt om speciale condities van een simpele for te beschrijven vind ik totaal overbodig. hiervoor bestaat een while.

for betekent zoveel als: voor elke X in verzameling Y
while betekent zoveel als: zolang voorwaarde X voldaan

maw je misbruikt de for-loop. je creert extra condities in een for-loop en die kunnen overal verspreid staan:

C++:

for (int i = 0; i < 1000; i++)
{
   if (i%500 && andere_conditie)
      break;
   // veel code
   if (i%750 && nog_een_andere_conditie)
      break;
   /// nog veel meer code
   if (i > 800 && een_speciale_conditie)
     break;
}

hier heb je 4 condities die de for-loop beeindigen. als deze ver uit elkaar staan heb je veel documentatie nodig om dit goed te maken... bad code dus

als je dit vervangt door een while (of meerder whiles als nodig) dan heb je op 1 plaats alle condities.
de functie wordt terug zelfdocumenterend en zal beter begrijpbaar zijn.

[Confusion]

HIGHGuY schreef op zaterdag 24 december 2005 @ 13:29:
jij schreef commentaar bij een for-loop, niet bij een functie...

Als een for-loop complex genoeg is om commentaar nodig te hebben, dan maak je er een aparte functie van. Dan is het functiecommentaar eigenlijk for-loop commentaar . Zo'n kort-maar-complex kunstmatig voorbeeld helpt niet echt bij het verduidelijken.

maw je misbruikt de for-loop. je creert extra condities in een for-loop en die kunnen overal verspreid staan:

Goed, je moet je problemen niet oplossen door lukraak breaks neer te smijten, zeker niet ver van elkaar. Dat betekent nog niet dat de break een overbodig taalelement is. Als je deze voorbeelden zo uit je mouw schudt, kan je volgens mij kan ook prima een voorbeeld bedenken van een loop die door gebruik van een break of continue juist overzichtelijker blijft. Die dingen zijn er niet alleen voor efficientie.

[RayNbow]

Dit is wel offtopic, maar goed... over het hele break's/goto's gebeuren:
Go To Statement Considered Harmful
"GOTO Considered Harmful" Considered Harmful
Goed leesvoer

[Michali]

Grappig. In het boek Code Complete wordt juist beweert (en uitgelegd) dat het toevoegen van een extra controle in de while loop in plaats van het gebruik van een break statement de code juist moeilijker leesbaar maakt. Het punt daarbij is dat je daarmee geneste if statements in de loop kunt voorkomen en de code erin dus wat vlakker houdt. Uiteraard is het verspreiden van een verschillende breaks door de hele loop niet goed, maar dat duid ook vaak op dat je de loop voor meer dan 1 taak gebruikt en dat maakt hem zeker moeilijk leesbaar.

[H!GHGuY]

Michali schreef op zaterdag 24 december 2005 @ 14:53:
Grappig. In het boek Code Complete wordt juist beweert (en uitgelegd) dat het toevoegen van een extra controle in de while loop in plaats van het gebruik van een break statement de code juist moeilijker leesbaar maakt. Het punt daarbij is dat je daarmee geneste if statements in de loop kunt voorkomen en de code erin dus wat vlakker houdt.

je kan nog altijd je condities groeperen in logische stukken

C++:

while ( (conditie1 && conditie2) || (conditie3 && conditie4) || conditie5)
{


}

imo is de enige plaats waar break toegelaten is in de switch-case structuur.
mensen die regelmatig goto, break, continue gebruiken vervallen al snel in slechte code die helemaal niet meer te ontwarren is.

bovendien werkt het bugs in de hand.
als je de code mathematisch moet bewijzen, wil ik niet degene zijn die pre/post condities moet samenstellen bij jouw lus en al zeker niet degene die die condities dan ook nog eens moet verifieren.

het is gewoon bad practice imo. jij doet maar wat jij wil, maar ik zal blij zijn als ik nooit een letter van jouw code moet lezen.

[Michali]

En wat doe je in het geval van een constructie waarbij de exit conditie in het midden staat? Dan heb je toch echt een break nodig.

Dan bedoel ik dus zoiets:

code:

while ( true )
{
  // statement A
  // statement B
  if ( conditie ) break;
  // statement C
  // statement D
}

Dat is imo netter dan iets als dit:

code:

// statement A
// statement B
while ( !conditie )
{
  // statement C
  // statement D
  // statement A
  // statement B
}

Bovendien moet je loops gewoon lekker simpel houden. Als een break statement er echt voor zorgt dat een loop moeilijk leesbaar wordt, dan ben je nodig aan refactoring toe.

Met foreach loopjes wil ik ook nog wel eens een break gebruiken. Ik heb er zelf nooit problemen mee.

[ Voor 14% gewijzigd door Michali op 24-12-2005 18:07 ]

[D-Raven]

Gooeeedd... Ik zal hier even een toevoeging op maken

offtopic:
Het programma wat de TS aan het maken is is een onderdeel van opdracht uit het Bluej java lesboek.
De opdracht heet Zuul, en is in feite een serie van opdrachten om tot een primitief text based rpg spel te komen. Maar dat is niet de essentie van de opdracht.
De essentie van de opdracht is het leren refactoren. Vandaar dat er ontwerp beslissingen inzitten die misschien niet helemaal handig zijn. De TS heeft alleen tijd over en is verder gaan hobbyen
Ik ben klasse assistent in de klas waar de TS zit (je player klasse heeft je weggegeven joh , of er moet iemand anders zijn die precies dezelfde klasse geschreven heeft ).
Om even aan te geven hoever deze leerlingen zijn: Het volgende hoofdstuk zal over overerving en subklasses gaan.

De bedoeling van deze post is om aan te geven dat de TS er niks aan heeft als hier een discussie lostbarst over wat "nettere" code is. Waar de TS oneindig veel meer aan heeft zijn posts zoals die van Brama.

@ TS: Mocht je nog meer probleempjes tegenkomen of ergens inzicht over nodig willen hebben. Ik heb die opdracht ook gemaakt dus kan je misschien wel een eind op weg helpen mail me maar zouk zeggen. Of open een nieuw topic ofcourse

[Confusion]

HIGHGuY schreef op zaterdag 24 december 2005 @ 15:49:
het is gewoon bad practice imo.

Ik waardeer de honest opinion van de schrijver van Code Complete hoger dan de jouwe. Hij beargumenteert zijn stellingen overdadig met voorbeelden en onderzoeksgegevens en ik was het met die sectie grondig eens. Zoals ik al zei: het is triviaal om voorbeelden te bedenken waarin breaks of continues tot onleesbare code leiden. Het is net zo triviaal om voorbeelden te bedenken waarin een break of continue tot beter leesbare code leidt, omdat het de gedachtegang beter weergeeft.

[EnsconcE]

code:

break;

Daarmee aangevende dat het hele break gebeuren misschien interessant is, maar geheel niet ontopic. Als moderator zou je toch beter moeten weten(no flame intended). Hiermee aangevende dat, zoals eerder al is gezegd, het onderwerp beter ergens anders besproken kan worden.


[ONTOPIC]
Brama; je bent een schat. Het boek Bluej, waarover deathraven al sprak, is enigsinds duidelijk in het zwak afhankelijk zijn van de klassen. Zoals jij het omschrijft heb ik daarin een klein beetje gefaald. Daarnaast moet ik zeggen dat als ik geen eerdere ervaring had met programeertalen, dan had ik het zeker niet zo makkelijk gehad als nu. Ik bedoel hiermee te zeggen dat het boek om sommige plekken tekort schiet. Daarom zal ik tweakers nog wel een aantal keer aanschieten .

Deathraven, ik ken je niet en de opdracht is dan wel van uit het boek, school heeft me gevraagd dit verder uit te werken zodat het voldoet aan de eisen die school aan deze opdracht heeft gesteld. Het gaat uiteindelijk ook om de efficientie van de code.
[offtopic]

Ik zit btw in groningen op school.

@brama
Kweenie wat je bedoelt met een MUD maar het is gewoon een text-adventure waar je items kan oppakken, gebruiken, sommigen lezen, sommigen kan combineren en sommigen niet kan oppakken.

[ Voor 10% gewijzigd door EnsconcE op 26-12-2005 01:05 ]

[Confusion]

EnsconcE schreef op zondag 25 december 2005 @ 23:45:
Daarmee aangevende dat het hele break gebeuren misschien interessant is, maar geheel niet ontopic. Als moderator zou je toch beter moeten weten(no flame intended).

Als de probleemstelling van de draad besproken en opgelost is, dan is een subdiscussie naar aanleiding van de hoofddiscussie naar mijn mening geen probleem. Jij moet geen identificatiestrings gaan rondsturen als je net zo makkelijk de objecten zelf kan rondsturen, waardoor je het hele constructieprobleem uit de topicstart niet hebt. Brama gaat net zo goed volkomen offtopic.

[D-Raven]

EnsconcE schreef op zondag 25 december 2005 @ 23:45:
[ONTOPIC]
Brama; je bent een schat. Het boek Bluej, waarover deathraven al sprak, is enigsinds duidelijk in het zwak afhankelijk zijn van de klassen. Zoals jij het omschrijft heb ik daarin een klein beetje gefaald. Daarnaast moet ik zeggen dat als ik geen eerdere ervaring had met programeertalen, dan had ik het zeker niet zo makkelijk gehad als nu. Ik bedoel hiermee te zeggen dat het boek om sommige plekken tekort schiet. Daarom zal ik tweakers nog wel een aantal keer aanschieten .

Deathraven, ik ken je niet en de opdracht is dan wel van uit het boek, school heeft me gevraagd dit verder uit te werken zodat het voldoet aan de eisen die school aan deze opdracht heeft gesteld. Het gaat uiteindelijk ook om de efficientie van de code.
[offtopic]

Ik zit btw in groningen op school.

Ow lol ok... ik zit zelf in Den Bosch, dus dan kan t niet nee.
Maar gezien het feit dat ook jij je player klasse op die manier had opgebouwd duid wel aan dat het boek inderdaad duidelijk tekort schiet. Ikzelf had een vorige druk van het boek en daar zat het hoofdstuk overerving en subklasses nog net voor het hoofdstuk refactoring. Wat wel enigsinds hielp.
Mjah er zitten veel leuke dingen in die zuul opdracht. Wacht maar todat je traps gaat verzinnen als je dat uberhaupt gaat doen. (transporter trap??) Kom je weer hele leuke problemen tegen

[brama]

EnsconcE schreef op zondag 25 december 2005 @ 23:45:
Brama; je bent een schat. Het boek Bluej, waarover deathraven al sprak, is enigsinds duidelijk in het zwak afhankelijk zijn van de klassen. Zoals jij het omschrijft heb ik daarin een klein beetje gefaald. Daarnaast moet ik zeggen dat als ik geen eerdere ervaring had met programeertalen, dan had ik het zeker niet zo makkelijk gehad als nu. Ik bedoel hiermee te zeggen dat het boek om sommige plekken tekort schiet. Daarom zal ik tweakers nog wel een aantal keer aanschieten .

Graag gedaan hoor. Ik doe het na jaren ervaring met OO talen ook nog wel fout hoor. De kunst is om niet te snel na te denken over de implementatie van de data in de objecten op het moment dat je het ontwerp aan het maken bent.

@brama
Kweenie wat je bedoelt met een MUD maar het is gewoon een text-adventure waar je items kan oppakken, gebruiken, sommigen lezen, sommigen kan combineren en sommigen niet kan oppakken.

Een MUD is een text-adventure wat je online kan spelen met (of soms tegen) anderen. Dat lijkt hier dus heel sterk op

[EnsconcE]

brama schreef op maandag 26 december 2005 @ 19:43:
[...]


Graag gedaan hoor. Ik doe het na jaren ervaring met OO talen ook nog wel fout hoor. De kunst is om niet te snel na te denken over de implementatie van de data in de objecten op het moment dat je het ontwerp aan het maken bent.


[...]


Een MUD is een text-adventure wat je online kan spelen met (of soms tegen) anderen. Dat lijkt hier dus heel sterk op

Bedankt voor het advies, dat kan ik zeker gebruiken. Het is een text-adventure maar geen online multiplayer, eigenlijk al helemaal geen multiplayer(ondanks dat de basis er wel inzit maar dat is meer het leren van OO programmeren).

D-Raven schreef op maandag 26 december 2005 @ 12:04:
[...]


Ow lol ok... ik zit zelf in Den Bosch, dus dan kan t niet nee.
Maar gezien het feit dat ook jij je player klasse op die manier had opgebouwd duid wel aan dat het boek inderdaad duidelijk tekort schiet. Ikzelf had een vorige druk van het boek en daar zat het hoofdstuk overerving en subklasses nog net voor het hoofdstuk refactoring. Wat wel enigsinds hielp.
Mjah er zitten veel leuke dingen in die zuul opdracht. Wacht maar todat je traps gaat verzinnen als je dat uberhaupt gaat doen. (transporter trap??) Kom je weer hele leuke problemen tegen

Wat bedoel je met een transporter trap?

[D-Raven]

Nou, wij kregen de opdrachten om vallen te implementeren in het spel.
Dat zou je als volgt kunnen implementeren (is maar een voorbeeld, er zijn natuurlijk andere oplossingen)
Een val (of Trap) klasse maken, en daarvan subklasses maken, afhankelijk van het type val wat je wilt hebben.
Ik had ontworpen dat je maximaal een val per kamer hebt, waarbij bij het starten van het spel een of meerdere random val(len) werd(en) geinstantieerd (Door middel van een factory dezign pattern) en die aan een random kamer werd gehangen, op het moment dat de speler een kamer binnenkomt gooi je er een kansberekening op die bepaald of de val afgaat of niet (indien er een val inzit).

Ik had een zogenaamde transporter trap bedacht. Die je naar een random kamer in het spel gooit als hij afgaat.
Afhankelijk van hoe je je kamers opslaat in het spel (linked list of een hashMap zoals eerder aangegeven in dit topic) is dit relatief eenvoudig, of zeer moeilijk. (tip: het is makkelijker als je kamers in bv een hashmap zitten, bij mij waren het aantal kamers statisch, alleen de plattegrond opbouw was dynamisch)
Eitherway is het een leuke uitdaging .
Ik had ook al vijanden er in zitten die je aanvielen en echt damage deden. In dat geval was een frost-trap niet leuk (bij mij hield dit in dat je 2 seconden niks kon doen).

[ Voor 19% gewijzigd door D-Raven op 29-12-2005 21:09 ]

[EnsconcE]

D-Raven schreef op donderdag 29 december 2005 @ 21:05:
Nou, wij kregen de opdrachten om vallen te implementeren in het spel.
Dat zou je als volgt kunnen implementeren (is maar een voorbeeld, er zijn natuurlijk andere oplossingen)
Een val (of Trap) klasse maken, en daarvan subklasses maken, afhankelijk van het type val wat je wilt hebben.
Ik had ontworpen dat je maximaal een val per kamer hebt, waarbij bij het starten van het spel een of meerdere random val(len) werd(en) geinstantieerd (Door middel van een factory dezign pattern) en die aan een random kamer werd gehangen, op het moment dat de speler een kamer binnenkomt gooi je er een kansberekening op die bepaald of de val afgaat of niet (indien er een val inzit).

Ik had een zogenaamde transporter trap bedacht. Die je naar een random kamer in het spel gooit als hij afgaat.
Afhankelijk van hoe je je kamers opslaat in het spel (linked list of een hashMap zoals eerder aangegeven in dit topic) is dit relatief eenvoudig, of zeer moeilijk. (tip: het is makkelijker als je kamers in bv een hashmap zitten, bij mij waren het aantal kamers statisch, alleen de plattegrond opbouw was dynamisch)
Eitherway is het een leuke uitdaging .
Ik had ook al vijanden er in zitten die je aanvielen en echt damage deden. In dat geval was een frost-trap niet leuk (bij mij hield dit in dat je 2 seconden niks kon doen).

Okee dan, nee zo ver gaan wij niet, althans nog niet. Wat wij wel doen is een random room en die is idd het makkelijkst met een hashmap. Waar ik ook aan zat te denken was een wrapperklasse en de room's een integer als id mee te geven. Je random functie kun je dan aanroepen op het moment dat je kamers worden aangemaakt en daar kan je dan ook je limiet instellen. Maar daar zijn we nog niet. Eerst moeten alle monsters een "geobjecteerd" worden.

De factory design pattern ken ik niet, overigens bijna geen een design pattern. Bluej praat daar niet over, iig niet tot en met H8 en van wat ik verder heb gelezen ook niet. Design patterns lijken me wel handig, misschien maar es een boek aanschaffen daarover.

[D-Raven]

EnsconcE schreef op vrijdag 30 december 2005 @ 13:42:
[...]

Design patterns lijken me wel handig, misschien maar es een boek aanschaffen daarover.

Niet alleen misschien. Als je echt hierin verder wilt, dan is het verplichte kost.