[PHP5] OOP (groepje beertjes :P )

[Verwijderd]

hey, even een snel (en simpel?) vraagje

Neem deze link als voorbeeld.
Hierin wordt leuk OOP beschreven met een paar voorbeeltjes met beren en dit is verder allemaal relatief straightforward.

Maar nu zat ik te denken, wat nou als je een groep beren wilt aanmaken van die classe (b.v. een family). Welke manier zouden jullie dan kiezen, en waarom? Een nieuwe classe die bear extends en daarin functies aanmaakt als next, previous enzo om door de groep beren te wandelen? Of gewoon een array van die classe met beren erin, zonder verdere OOP? Of iets anders?

Dank iig voor de uitleg! Ik snap namelijk wel hoe OOP werkt enzo, maar ben nog een beetje aan het uitvinden wat 'best-practise' hierin is...

[GX]

Ik zou waarschijnlijk iets als

PHP:

$bears[] = new bear(troep hier..);

gedaan hebben.

En dan die bears array maar misbruiken.

[JHS]

Nieuwe class, collection en collectionIterator, is veel over te vinden .

[Michali]

Je kunt idd kiezen voor een array waarin je de beren zet. Je zou ook kunnen kiezen voor een eigen gemaakte collectie class / array wrapper die de zaken voor je regelt:

PHP:

class BearCollection
{
  private $bears = array();
  public function add(Bear $bear) { ... }
  public function remove(Bear $bear) { ... }
}

Op die manier dan. Ik kan je ook wel aanraden om eens naar deze pagina te kijken.

[eamelink]

Bovenstaande ideeen zijn okee, maar Bear gaan extenden is niet de way to go

[Verwijderd]

Als ik nou in eerste instantie alleen geinteresseerd ben de groep met beren dan kan ik toch beter nog een class aanmaken met een enkele bear en daar een Collection van maken? ( lijkt me wel )

En een collection lijkt me meer OOP gebaseerd dan de bear array, correct? Mocht ik dan later een dierentuin willen maken dan kan ik gewoon de bearCollection daarvoor gebruiken? Op een onderstaande manier ofzo?

PHP:

class Zoo
{
  public $bears = new BearCollection();
  public $penguins = new PenguinCollection();
  public $lions = new LionCollection();

  ( ... functions etc ... )
}


// met iets dergelijks als
$zoo->bears->add("johnny bear");
$zoo->bears->currentBear->feed();
$zoo->bears->next();
$zoo->bears->currentBear->feed();

toch? of gaat/hoort dit niet zo?

Edit:
hmmm, een beer voed zichzelf niet een dierentuin medewerker voed een beer, dus eigenlijk zit die functie helemaal niet in beer en is het voorbeeld al niet goed

[ Voor 14% gewijzigd door Verwijderd op 12-06-2005 14:31 ]

[Michali]

Zo zou je het kunnen gebruiken idd, maar vanuit OO opzicht is het niet echt netjes. Beter is nog om de implementatie van de Zoo te verbergen middels accessor functies richting de collection (of eventueel een functie die de gehele collectie returned, als de interface van je collectie stabiel genoeg is). Het is iig vrijwel nooit een goed plan om member vars public te maken.

PHP:

class Zoo
{
  private $bears = new BearCollection();
  public function addBear($name) { $this->bears->add(new Bear($name)); }
  public function getBears() { return $this->bears; }
}

$zoo = new Zoo();
$zoo->addBear('johnny bear');
$bears = $zoo->getBears();
print $bears->getCurrent()->getName();

Of iets dergelijks.

[NMe]

Verwijderd schreef op zondag 12 juni 2005 @ 14:21:
Als ik nou in eerste instantie alleen geinteresseerd ben de groep met beren dan kan ik toch beter nog een class aanmaken met een enkele bear en daar een Collection van maken? ( lijkt me wel )

En een collection lijkt me meer OOP gebaseerd dan de bear array, correct? Mocht ik dan later een dierentuin willen maken dan kan ik gewoon de bearCollection daarvoor gebruiken? Op een onderstaande manier ofzo?

[..]

toch? of gaat/hoort dit niet zo?

Lijkt me wel. Maar intern hebben die collections dus wel gewoon een array of andere lijstvorm die de beren bijhoudt, en vervolgens heb je ook een array pointer/index nodig om door die beren heen te kunnen lopen. Beide zijn private variabelen van de collectieklasse.

[Verwijderd]

Michali schreef op zondag 12 juni 2005 @ 14:29:
Zo zou je het kunnen gebruiken idd, maar vanuit OO opzicht is het niet echt netjes. Beter is nog om de implementatie van de Zoo te verbergen middels accessor functies richting de collection (of eventueel een functie die de gehele collectie returned, als de interface van je collectie stabiel genoeg is). Het is iig vrijwel nooit een goed plan om member vars public te maken.

[...]

Of iets dergelijks.

Hmm, ik snap prima wat je bedoelt, maar ik zie nog niet helemaal in waarom dat beter is? Want eigenlijk bouw je de functies die je eerder in de bearCollection hebt gebouwd opnieuw, welliswaar roep je die van bearCollection aan, maar toch. Waarom zou je de beren niet rechtstreeks te benaderen maken? Omdat je dan minder controle op de classie eronder kunt uitvoeren ofzo? Dat er eenvoudiger iets fout kan gaan?

[Zoijar]

OOP gaat niet om implementatie... Een beer "is" geen familie beren; een familie beren "bestaat uit" beren. Als alle beren dood zijn, dan is er ook geen familie meer; als de familie verdwijnt zijn de beren ook weg. De familie heeft ownership over de beren. Een duidelijk geval van aggregation dan. Dat kan je ventueel implementeren met een BearFamily class en een array van beren in die class.

Maar stel dat het bv om een "bear faction" gaat, waar een beer bij een andere factie kan gaan, of als de factie wordt ontbonden dat de beren dan nog wel in leven zijn. Dan is het een associatie. De implementatie gaat ongeveer gelijk, alleen heb je nu dan een array van references (associaties) naar beren. De collectie heeft geen ownership nu.

[Michali]

Verwijderd schreef op zondag 12 juni 2005 @ 14:49:
[...]


Hmm, ik snap prima wat je bedoelt, maar ik zie nog niet helemaal in waarom dat beter is? Want eigenlijk bouw je de functies die je eerder in de bearCollection hebt gebouwd opnieuw, welliswaar roep je die van bearCollection aan, maar toch. Waarom zou je de beren niet rechtstreeks te benaderen maken? Omdat je dan minder controle op de classie eronder kunt uitvoeren ofzo? Dat er eenvoudiger iets fout kan gaan?

Dat is beter omdat je dan gemakkelijker wijzigingen in je design/opbouw kunt uitvoeren. Stel dat je de bear collectie verplaatst naar nog een andere class, waarvan ook een instantie een member in Zoo is. Met directe toegang tot de bear collectie zou je dan alle plaatsen waar deze collectie wordt gebruikt moeten aanpassen. Met een functie hoef je hier alleen maar binnen Zoo rekening mee te houden. Wijzigingen kun je in zulke gevallen dan puur het de server laten (Zoo in dit geval) en kun je de client gewoon met rust laten. Die hoeft deze informatie niet te hebben.

Verder kun je ook controleren wat voor acties er allemaal uitgevoerd mogen worden op de bear collectie. Nu heb je er in het Zoo object geen weet van wat er allemaal mee gebeurt. Met simpele accessor functies kun je gemakkelijk checks toevoegen en controleren wat je wilt. Bovendien vermindert een werkwijze als deze ook nog eens code duplicatie, omdat je dezelfe functionaliteit vaak op meerdere plaatsen nodig hebt.

[ Voor 18% gewijzigd door Michali op 12-06-2005 14:59 ]

[Verwijderd]

Erg verhelderend allemaal dank!

Kijk het punt is dat ik momenteel voor de eerste maal in mijn php scripts eigen gemaakte objecten gebruik. Ik had voordat ik deze topic starte een aantal bedenkingen aan mijn eigen classe, en probeer een beetje het juiste OOP-gevoel te krijgen.
Ik heb namelijk de volgende code:

PHP:

<?php
class IngredientsClass {
    public $id;
    public $description;
    public $name;
    public $amount;
    public $optional;
    public $unity;
    public $type;
    
    private $_ingredients;
    private $_index;

    public function __construct($id=0) {
        $this->_ingredients = array("No ingredients");
        $this->load($id);
        $this->first($id);
    }

    public function __destruct() {
    }

    public function first() {
        $this->_index = 0;
        $this->_set($this->_index);
        
        return true;
    }
    
    public function next() {
        if( $this->_index < $this->count()-1 ) {
            $this->_index++;
            $this->_set($this->_index);
            
            return true;
        }
        else
            return false;
    }

    public function last() {
        $this->_index = $this->count();
        $this->_set($this->_index);
        
        return true;
    }
    
    public function count() {
        return count($this->_ingredients);
    }
    
    public function index() {
        return $this->_index;
    }
    
    private function _set($index) {
        if($this->_index < $this->count()) {
            $this->description  = $this->_ingredients[$index]["description"];
            $this->name = $this->_ingredients[$index]["name"];
            $this->amount   = $this->_ingredients[$index]["amount"];
            $this->optional = $this->_ingredients[$index]["optional"];
            $this->unity    = $this->_ingredients[$index]["unity"];
            $this->type = $this->_ingredients[$index]["type"];
        }
    }
    
    public function load($id) {

        $this->description  = NULL;
        $this->name = NULL;
        $this->amount   = NULL;
        $this->optional = NULL;
        $this->unity    = NULL;
        $this->type = NULL;

        if((int)$id != 0) {
            /*
            Code die $ingredients vult met in de zin van:
            while (...) {
                ingredients[$index]["description"] = ...;
                ingredients[$index]["name"]     = ...;
                ingredients[$index]["amount"]   = ...;
                ingredients[$index]["optional"] = ...;
                ingredients[$index]["unity"]    = ...;
                ingredients[$index]["type"] = ...;
            }
            */

            if (!empty($ingredients)) {
                $this->_ingredients = $ingredients;
                $this->_set(0);
            }
        }
        else
            return false;
    }
}

?>

Nu had ik echter een paar vraagtekens bij mijn eigen code, namelijk:

• Is dit (een beetje ) goed OOP?
• Kan ik beter een Ingredient class maken, en daaroverheen een IngredientCollection maken? Of is deze oplossing met privates zo ook goed?
• De constructor, is dat een beetje volgens de OOP regels?
• De public variabelen, is dat hoe het hoort (in PHP)? Of moet ik die te benaderen maken met getVariabeleNaamHier() en setVariabeleNaamHier() ?

[Michali]

Ik zou idd een Ingredient class maken en dan via een getCurrentIngredient() deze huidige ingredient ophalen. Het is iig niet netjes om public members te gebruiken en al helemaal niet om alle waarden van de huidige ingredient daar aan toe te kennen. Deze waardes moeten via een Ingredient instantie zelf opgehaalt kunnen worden. Nu moet je bij het toevoegen van een waarde aan de ingredient class ook de collectie class wijzigen en dat mag niet te bedoeling zijn. Maak dus gewoon een simpele collectie class, met functies als add, remove, next, first, last en getCurrent (of iets in die richting) en doe dat met hele Ingredient instanties. load lijkt me trouwens ook niet echt een taak voor een collectie class.

[Verwijderd]

Leuk draadje, ben sinds vanmiddag ook aan het kijken naar het OO-gedeelte van PHP, nu draait mijn server helaas 4.*.*, en ik heb al begrepen dat het OO-gedeelte daarvan niet zo bijster interessant is.

Toch maar smeken om een upgrade naar 5 bij mn host

[Verwijderd]

PHP:

<?php

class IngredientCollectionClass {
    
    private $_ingredients;
    private $_index;

    public function __construct() {
        $this->_index       = 0;
        $this->_ingredients = array();
    }

    public function __destruct() {
    }
    public function getId() {
        return $this->getCurrent()->getId();
    }
    public function getDescription() {
        return $this->getCurrent()->getDescription();
    }
    public function getName() {
        return $this->getCurrent()->getName();
    }
    public function getAmount() {
        return $this->getCurrent()->getAmount();
    }
    public function getOptional() {
        return $this->getCurrent()->getOptional();
    }
    public function getUnity() {
        return $this->getCurrent()->getUnity();
    }
    public function getType() {
        return $this->getCurrent()->getType();
    }
    
    public function add($id) {
        $insert_id = $this->count();
        $this->_ingredients[$insert_id] = new IngredientClass($id);
    }
    public function getCurrent() {
        return $this->_ingredients[$this->_index];
    }

    public function first() {
        $this->_index = 0;
        return true;
    }
    public function next() {
        if( $this->_index < $this->count()-1 ) {
            $this->_index++;
            return true;
        }
        else
            return false;
    }
    public function last() {
        $this->_index = $this->count();
        return true;
    }
    public function count() {
        return count($this->_ingredients);
    }
    public function getIndex() {
        return $this->_index;
    }
    
}

////////////////////////////////////////////////////////////////

class IngredientClass {
    private $_id;
    private $_description;
    private $_name;
    private $_amount;
    private $_optional;
    private $_unity;
    private $_type;

    public function __construct($id=0) {
        $this->_load($id);
    }

    public function __destruct() {
    }
    
    public function getId() {
        return $this->_id;
    }
    public function getDescription() {
        return $this->_description;
    }
    public function getName() {
        return $this->_name;
    }
    public function getAmount() {
        return $this->_amount;
    }
    public function getOptional() {
        return $this->_optional;
    }
    public function getUnity() {
        return $this->_unity;
    }
    public function getType() {
        return $this->_type;
    }
    
    private function _load($id) {
        
        $this->id           = NULL; 
        $this->_description = NULL;
        $this->_name        = NULL;
        $this->_amount      = NULL;
        $this->_optional    = NULL;
        $this->_unity       = NULL;
        $this->_type        = NULL;

        if((int)$id != 0) {

            /* Verkrijg $ingredient uit de database */
            
            if (!empty($ingredient)) {
                $this->_id          = $id;
                $this->_description = $ingredient["description"];
                $this->_name        = $ingredient["name"];
                $this->_amount      = $ingredient["amount"];
                $this->_optional    = $ingredient["optional"];
                $this->_unity       = $ingredient["unity"];
                $this->_type        = $ingredient["type"];
            }
            else {
                return false;
            }
        }
        else
            return false;
    }
}
?>

en dan bijvoorbeeld gebruiken als:

PHP:

/* De item class gebruik het volgende CODE-SNIPPETS om ingredients beschikbaar te stellen: */
$this->_ingredients = new IngredientCollectionClass();
while(...) {
  $this->_ingredients->add((int)$id);
}
public function getIngredients() {
  return $this->_ingredients;
}



do {
  echo $item->getIngredients()->getDescription();
  echo $item->getIngredients()->getAmount();

} while ( $item->getIngredients()->next() )

Ik heb werkelijk geen idee of dit beter is Heb het gevoel van niet

[Michali]

Nu zit je nog steeds met het probleem dat je de collectie class moet gaan aanpassen als je de Ingredient class aanpast. Ik zou alle get<...>() functies, behalve getCurrent(), in de collectie class gewoon weg laten. Als nadenkt over wat de collectie voorstelt, dan merk je ook dat je die vragen niet aan de collectie, maar aan een ingredient zelf hoort te stellen. Dat is ook een belangrijk punt in OO programmeren. Je moet goed nadenken over wat je class voorstelt en of de functies die je er in hebt geplaatst daar ook echt bijhoren. Oftewel, zou je aan een collectie items vragen wat de naam ervan is mbv. getName()? Denk het niet.

Je collectie class wordt nu eigenlijk zo algemeen dat je eigenlijk moet gaan denken aan een algemene collectie class, dus eentje die niet alle te gebruiken is voor ingredienten, maar ook voor andere type objecten. Je zou daarvoor een eigen class kunnen maken, maar het is denk ook een goed idee om eens naar ArrayObject te kijken en bijbehorende ArrayIterator. Ik heb het vermoeden dat die al best voldoen. Volgens mij kun je ze zelfs uitbereiden door er gewoon van te erven. Zo kun je specifieke functionaliteit toevoegen mocht dat nodig zijn.

Het verplaatsen van de load functie naar Ingredient zelf is al een goede stap. Dit is voor simpele oplossingen voldoende. Je zou echter ook een aparte class kunnen maken die als taak heeft Ingredient instanties in de database te zetten en er ook weer uit te halen als dat nodig is. Daar moet je zelf maar even naar kijken. De get<...>() functies in de Ingredient class zijn ook goed. Je verbergt nu dat je hoe je aan deze waardes komt en nu is dit ook gemakkelijk aan te passen mocht dat nodig zijn.

[ Voor 26% gewijzigd door Michali op 12-06-2005 19:21 ]

[Verwijderd]

ah, ok.... ik had ook inderdaad de twijfels over de getfuncties in de IngredientsCollection, maar ik had dat gedaan ivm met een van je eerdere voorbeelden:

PHP:

class Zoo {
  private $bears = new BearCollection();
  public function addBear($name) { $this->bears->add(new Bear($name)); }
  public function getBears() { return $this->bears; }
}

$zoo = new Zoo();
$zoo->addBear('johnny bear');
$bears = $zoo->getBears();
print $bears->getCurrent()->getName();

deze zou dan namelijk ook beter dit kunnen worden? Of denk ik nu verkeerd?

PHP:

class Zoo
{
  private $bears = new BearCollection();
  public function getBears() { return $this->bears; }
}

$zoo = new Zoo();
$zoo->getBears()->addBear('johnny bear');
$bears = $zoo->getBears();
print $bears->getCurrent()->getName();

Het is me iig nog niet helemaal duidelijk wanneer ik nu in een classe gewoon een andere, onderliggende classe zou aanspreken, en wanneer ik er nieuwe functies voor moet maken

[Dutchmega]

Interessante topic. Ik maak momenteel nogal gebruik van de getInstance() in PHP5, wat dus eerlijk gezegd niet hoge kwaliteit OOP is... Helaas gebruiken de meeste hosters nog PHP4 omdat PHP5 niet goed backwards-compatible is (volgens hun)..

[ Voor 5% gewijzigd door Dutchmega op 12-06-2005 19:51 ]

[Michali]

Nou je moet kijken naar wat je class voorstelt en of de functie daar wel bij past. Wat een Zoo voorstelt is duidelijk, dus vindt je het toevoegen van een beer aan een dierentuin iets wat er bij past? Het lijkt mij iig een vrij normale vraag/bericht om aan een dierentuin te stellen/sturen. Je moet de vraag stellen aan het eerste object waar het normaal is om die vraag aan te stellen. In dit geval zou ik dan voor de Zoo gaan, maar direct aan de BearCollection zou je ook kunnen doen. Dit heet overigens cohesion, een erg belangrijk princiepe in OO proggen. Cohesion is vertaald samenhang, wat aangeeft hoe samenhangend de set functies die een class beschikbaar stelt zijn en hoe goed ze passen bij de abstractie die de class voorstelt. Je moet uiteraard proberen om dit zo hoog mogelijk te houden. Oftwel passen alle functies van Zoo wel bij wat het voostelt? En is dat voor de Collection class ook zo?

[Michali]

Dutchmega schreef op zondag 12 juni 2005 @ 19:51:
Interessante topic. Ik maak momenteel nogal gebruik van de getInstance() in PHP5, wat dus eerlijk gezegd niet hoge kwaliteit OOP is... Helaas gebruiken de meeste hosters nog PHP4 omdat PHP5 niet goed backwards-compatible is (volgens hun)..

Bedoel je in het gebruik van een Singleton? Wel jammer idd dat hosters daar niet echt snel in zijn. Hopelijk gaan ze wel over als de final van 5.1 eenmaal uit is.

[Verwijderd]

Even muggeziften hoor, maar dat hoort bij dit topic:

amount, optional, (unity?) zijn geen eigenschappen van een ingredient maar van een gerecht.

[esf]

In plaats van

PHP:

class Zoo {
  private $bears = new BearCollection();
  [...]
}

kun je eventueel beter

PHP:

class Zoo {
  private $animals = new AnimalCollection();
  [...]
}

gebruiken en dan alle soorten dieren uit Animal laten erven. Als je voor alle soorten dieren een eigen collection toevoegt in de klasse, kun je moeilijk nieuwe dieren toevoegen.

[Verwijderd]

PHP:

class IngredientClass {
  //niet veranderd, zie eerdere post om ruimte te besparen
}

PHP:

class CollectionClass implements Iterator{
    
    private $_index = 0;
    private $_collection = array();

    public function __construct($array=array()) {
        if (is_array($array)) {
            $this->_collection = $array;
        }
    }

    public function add($item) {
        $insert_id = $this->count();
        $this->_collection[$insert_id] = $item;
    }

    public function key() {
        return key($this->_collection[$this->_index]);
    }

    public function rewind() {
        return $this->first();
    }
    
    public function current() {
        return $this->_collection[$this->_index];
    }

    public function valid() {
       return $this->current() !== false;
    }

    public function first() {
        $this->_index = 0;
        return true;
    }
    
    public function next() {
        if( $this->_index < $this->count()-1 ) {
            $this->_index++;
            return $this->_index;
        }
        else
            return false;
    }

    public function last() {
        return $this->_index = $this->count();
    }
    
    public function count() {
        return count($this->_collection);
    }
    
    public function index() {
        return $this->_index;
    }
    
}

PHP:

$ingredients = new CollectionClass();
$ingredients->add(new IngredientClass((int)$ingredient["id"]));

do { 
  $ingredients()->current()->getDescription();
  $ingredients()->current()->getAmount();
} while ($ingredients()->next())

Zo dan? Heb het idee dat het nu wel aardig wordt?
iig erg bedankt voor al jullie input, érg leerzaam!

[ Voor 10% gewijzigd door Verwijderd op 13-06-2005 12:35 ]

[Sybr_E-N]

Je zou nog iets van Type Hinting kunnen toevoegen. Dan weet je altijd wat voor type een parameter is, zoals in jouw collection constructor.

Misschien is het ook een idee om je eigen iterator te maken. Nu maak je steeds zelf alle next(), valid() en current() methoden. Je kunt het ook zo opzetten dat je voor toekomstige en andere collections dezelfde code kan gebruiken als je er weer eens doorheen wilt loopen.

[Verwijderd]

Sybr_E-N schreef op maandag 13 juni 2005 @ 12:41:
Je zou nog iets van Type Hinting kunnen toevoegen. Dan weet je altijd wat voor type een parameter is, zoals in jouw collection constructor.

Hmm, ik snap die voorbeelden die op de php manual site staan wel, maar ik kan niet echt inzien waar het voor gebruikt kan worden? Moet ik dan een collection typehinter maken om te voorkomen dat de verkeerde items toegevoegd kunnen worden? i.e. met de zoo, dat ik een typehinter maak dat er alleen beren kunnen worden toegevoegd, en geen leeuwen?

Misschien is het ook een idee om je eigen iterator te maken. Nu maak je steeds zelf alle next(), valid() en current() methoden. Je kunt het ook zo opzetten dat je voor toekomstige en andere collections dezelfde code kan gebruiken als je er weer eens doorheen wilt loopen.

Nou, ik heb snel ff "implements iterator" er bij ingebouwd, nog voordat je repliede. Maar ik weet niet of dat nog meegekregen hebt voor je reply. Is het dan ook zo hoe je het bedoelde?

[Sybr_E-N]

Verwijderd schreef op maandag 13 juni 2005 @ 12:58:

Hmm, ik snap die voorbeelden die op de php manual site staan wel, maar ik kan niet echt inzien waar het voor gebruikt kan worden? Moet ik dan een collection typehinter maken om te voorkomen dat de verkeerde items toegevoegd kunnen worden? i.e. met de zoo, dat ik een typehinter maak dat er alleen beren kunnen worden toegevoegd, en geen leeuwen?

Je wordt dan gewoon gedwongen, netals in andere OOP-talen waar het vaak niet anders kan, om objecten mee te geven van een bepaald type. Hierdoor weet je bijvoorbeeld in je constructor dat je tenalle tijde dat je object van dat opgegeven type is. In PHP kun je alleen type hinting, klassenaam ervoor zetten, voor objecten gebruiken. Je kunt niet vooraf dwingen dat je methode alleen integers accepteerd.

Nou, ik heb snel ff "implements iterator" er bij ingebouwd, nog voordat je repliede. Maar ik weet niet of dat nog meegekregen hebt voor je reply. Is het dan ook zo hoe je het bedoelde?

Ja, zo bedoelde ik het ongeveer ja.

[.oisyn]

-NMe- schreef op zondag 12 juni 2005 @ 14:30:
[...]

Lijkt me wel. Maar intern hebben die collections dus wel gewoon een array of andere lijstvorm die de beren bijhoudt, en vervolgens heb je ook een array pointer/index nodig om door die beren heen te kunnen lopen. Beide zijn private variabelen van de collectieklasse.

Waarom is het de taak van een collectie om 'de huidige item' te kennen? Een collectie is niets meer dan dat, een verzameling van elementen. Om er doorheen te lopen gebruikt men doorgaans een iterator, een apart object dat een specifiek element binnen een verzameling aanwijst. Dit is eveneens ook praktischer, met een iterator embedded in de collectie is er maar 1 gebruiker die door de lijst kan lopen. Wat als meerdere gebruikers dezelfde collectie willen gebruiken? Dan gaan ze elkaar in de weg zitten. Met een apart iterator object is het mogelijk zoveel iterators te maken als je wilt, één voor elk apart iteratie proces.

[ Voor 22% gewijzigd door .oisyn op 13-06-2005 13:48 ]