Bonjour,

Je suis en train d'essayer de comprendre l'Itérator !
Bon j'ai compris qu'il y avait une interface à implémenter et que l'on pouvais parcourir un objet avec foreach.

J'ai déjà eu du mal à capté qu'on passait un objet dans le foreach plutôt qu'un tableau
En revanche mon problème c'est que j'ai du mal à visualisé l'intérêt de cette méthode et dans quel contexte on l'utilise.

De plus j'ai vu dans un tutoriel ce code :

http://www.apprendre-php.com/tutoriels/ ... php-5.html

<?php
class MaClasse {
protected $arg1 = 'plop' ;
protected $arg2 = 'plip';
//...
}
$c = new MaClasse();
foreach($c as $key=>$value) {
echo $key, ' : ', $value, '<br/>';
}
?>

Hors chez moi cela ne fonctionne pas !
Je me suis rendu compte que les attribut était proctected et quand je les aient passé en public ça fonctionnait.
Si quelqu'un à une explication la dessus et pouvait me donné des exemples d'utilisation divers svp ?

des exemples plus concret.


Merci ^^

tout simplement parce que l'exemple est faux , tu ne peux pas accéder a un propriété protected hors class
remplace protected par public

par contre dans le 2eme exemple ca marche puisque les valeurs sont des copies

Hello,
je te renvoi à l'exemple 1 & 2 du manuel php : http://be2.php.net/Iterator

Donc si on revient à ton exemple, le premier exemple du site dis justement que cela n'afficherait pas cela à moins d'implémenter l'interface iterator et donc d'implémenter les méthodes adéquate.

remarque : tu as bien php5?

Bonsoir à vous !

Alors je connais l'encapsulation et ses effets mais ne connaissant pas l'itérator je pensais qu'en parcourant
l'objet je pourrais y accéder par ses méthodes dans le foreach genre :

$value->getMaMéthode()

mais après touts ses petits test je me suis aperçus que ce la ne fonctionnais pas évidement.
Et on m'as souvent rabâché que les attributs devais êtres private pour une meilleur conception.

Donc si on revient à ton exemple, le premier exemple du site dis justement que cela n'afficherait pas cela à moins d'implémenter l'interface iterator et donc d'implémenter les méthodes adéquat

J'ai compris qu'il fallait l'implémenté mais dans son exemple au début il fait un test et dis que cela affichera tel résultat et les attributs sont en protected donc je m'y suis fié !
Remarque ca m'aura fait comprendre ce principe !

En revanche j'avais vu pas mal de tutos sur l'Iterator mais aucun ne m'à donné envie de l'utiliser je n'arrive pas à me projeter dans le sens ou souvent on nous dis tu prends un nombre
tu rembobine etc... ou alors c'est avec MYSQL et j'utilise PDO lol c'est pas évident je me suis pas dis ah ok cool je peux faire ça avec

J'avais dans l'idée de l'utiliser pour faire du mapping ! car je boucle 2 fois mais je sais pas comment l'implémenté avec PDO pour le moment je suis pas encore à l'aise avec ça.

PDO (comme la plupart des librairie de de sql de PHP) te donne la possibilité de te renvoyé un objet plutôt qu'un tableau et tu peux le parcourir avec un foreach!

Pour ce qui est de l'utilité disons qu'il arrive souvent qu'on désire parcourir quelque chose. On peux imaginer que l'on aprcours un objet construit pour en afficher une partie. Il suffit de voir dans d'autre langage le nombre de fois où l'on en utilise... Néanmoins il est vrai que en PHP je ne l'ai que rarement utilisé contrairement à du java (par exemple).

Pour les itérateurs j'ai envie de dire wikipedia est ton ami : http://fr.wikipedia.org/wiki/It%C3%A9ra ... ception%29

Allez un exemple, ce qui me vient à la tête, c'est l'exemple du guestbook.

Tu a plusieurs possibilité, mais si tu est dans une architecture avec des modèles, théoriquement tu ne pourrais pas faire de requête sql (ou bien cela proviendrait d'un fichier texte ou ....) donc tu va créer un modèle itérable qui te permettra de parcourir la liste des message de ton guestbook pour, par exemple, les afficher.

ps : oublie pas que PDO = objet donc tu peux imaginer étendre ....

Par défaut une itération sur un objet php5 s'effectuera sur les attributs public de l'objet. En implémentant l'interface Iterator vous pourrez décidez comment cet objet sera parcouru.

Voici un exemple sur un panier ( vraiment mais alors vraiment basic )

class Article
{
	private $_nom;
	
	public function __construct($nom)
	{
		$this->_nom = (string) $nom;
	}
	
	public function getNom()
	{
		return $this->_nom;
	}
}

class Panier implements Iterator
{
	private $_articles;
	
	public function __construct()
        {
		$this->_articles = array();
	}
	
	public function ajoutPanier(Article $article)
	{
		$this->_articles[] = $article;
	}
	
	/**
	 * Implémentation des méthodes de l'interface iterator
	 */
	public function valid() 
        {
		 return array_key_exists(key($this->_articles),$this->_articles);
	}

	public function rewind() 
        {
		reset($this->_articles);
                return $this;
	}

	public function next() {
		 next($this->_articles);
		 return $this;
	}

	public function key() 
        {
		return key($this->_articles);
	}

	public function current() 
        {
		return current($this->_articles);
	}
}

$p = new Panier();

$a1 = new Article('article 1');
$a2 = new Article('article 2');

$p->ajoutPanier($a1);
$p->ajoutPanier($a2);

// parcours du panier
foreach($p as $a)
{
	echo $a->getNom().'<br />';
}

Hey ,

Si tu veux t'amuser avec les itérateurs, je te conseille de lire cette page Hoa_Iterator. Certes, c'est la page du manuel de référence du paquetage Hoa_Iterator (de Hoa Framework) mais tu vas sûrement y apprendre plusieurs choses intéressantes. On y explique ce qu'est en détail un itérateur et plusieurs exemples d'utilisations avec PHP sont proposés (avec toutes les boucles de PHP notamment).

Hello,

Merci Hywan pour ton explication. En plus, je ne connaissais pas ce type d'écriture : Qui après réflexion, c'est tout à fait logique.

Bonne soirée

Attention, il s'agit de l'implémentation de l'interface Fluent (ou Chainage en français) qui consiste à faire en sorte que chaque méthode d'une classe retourne l'instance de la classe, pour permettre, justement, de chainer les instructions.

Sans cette implémentation, c'est à dire si ta méthode ne retourne pas $this à la fin, tu auras une erreur.

Cette méthode a des avantages et des inconvénients. Il ne faut pas l'utiliser systématiquement. Son seul et unique but est d'apporter une facilité d'écriture, mais elle apporte aussi une gestion plus compliquée et moins fines des erreurs. Attention à bien peser le pour et le contre .

Hello,

Attention, il s'agit de l'implémentation de l'interface Fluent (ou Chainage en français) qui consiste à faire en sorte que chaque méthode d'une classe retourne l'instance de la classe, pour permettre, justement, de chainer les instructions.

Sans cette implémentation, c'est à dire si ta méthode ne retourne pas $this à la fin, tu auras une erreur.

Merci Zeus pour ton lien. Ça m'a permis de mieux comprendre l'avantage et l'inconvénient de cette écriture.

mais elle apporte aussi une gestion plus compliquée et moins fines des erreurs

Oui je me doute puisque les méthodes sont appelés les unes après les autres sur la même instance sans qu'il y ait un contrôle dessus.

En revanche, si le type de retour n'a aucune importance ou si aucune erreur ne peut-être émise, alors autant en profiter .

En revanche, si le type de retour n'a aucune importance ou si aucune erreur ne peut-être émise, alors autant en profiter .

Pour ma part, je profite de l'apport des exceptions pour ce genre d'utilisation.

Un truc du genre :

try
{
  $object = new Class();

  $object->setA($valA)
    ->setB($valB)
    ->setC($valC);
}
catch( ClassException $e )
{
    // Traitement de l'erreur
}

De cette manière, je bénéficie tout de même de l'interface Fluent, qui est extrêmement pratique pour les setter, mais tout en utilisant des contrôle d'erreur, et d'une gestion d'erreurs

C'est également une alternative oui.

L'erreur la plus courante est quand on retourne un autre objet que $this. Si c'est objet vaut null, alors c'est le crash assuré. Attention donc à vraiment bien géré le tout avec de belles exceptions .

En revanche, si le type de retour n'a aucune importance ou si aucune erreur ne peut-être émise, alors autant en profiter .

Pour ma part, je profite de l'apport des exceptions pour ce genre d'utilisation.
De cette manière, je bénéficie tout de même de l'interface Fluent, qui est extrêmement pratique pour les setter, mais tout en utilisant des contrôle d'erreur, et d'une gestion d'erreurs

+10 Je me l'imagine bien dans ce sens là. ^^

Si c'est objet vaut null, alors c'est le crash assuré. Attention donc à vraiment bien géré le tout avec de belles exceptions .

S'il n'y a pas d'exception, est ce que c'est le vrai crash (error fatal) ou il peut y avoir un comportement bizarre ?