Différences

Ci-dessous, les différences entre deux révisions de la page.

--- cours:informatique:dev:programmation_objet_pharo:330_iterateurs [2022/08/22 13:16] – yoann
+++ cours:informatique:dev:programmation_objet_pharo:330_iterateurs [2022/08/22 13:48] (Version actuelle) – yoann
@@ Ligne 223: / Ligne 223: @@
 Quand on a une collection souvent quand on fait des calculs on a tendance à imbriquer des collections dans des collection, et on se retrouve avec des niveaux d'imbrication qui peuvent être importants.
-<code smalltalk [enable_lines_numbers="true">
+<code smalltalk [enable_lines_numbers="true"]>
 #( #(1 2) #(3) #(4) #(5 6)) collect: [ :each | each ]
 "> #(#(1 2) #(3) #(4) #(5 6)) "
@@ Ligne 243: / Ligne 243: @@
 Donc la méthode ''do:'', elle prend en paramètre un block. Et voici l'implémentation de cette collection.
-<code smalltalk>
+<code smalltalk [enable_line_numbers ="true"]>
+do: aBlock
+    "Refer to the comment in Collection|do:."
+to: self size do:
+        [:index | aBlock value: (self at: index)]
 </code>
-a la taille de la collection do et j'ai un block. Je vais évaluer le block qui est passé en paramètre en lui passant l'élément à l'indice I. Donc c'est tout simple. Les itérateurs sont extrêmement puissants en Pharo, comme on a pu le voir. Toutes les collections supportent ces itérateurs de façon polymorphique. Du point de vue programmeur, on utilise des itérateurs et puis c'est chacune des classes de collections qui vont les implémenter de façon adéquate par rapport à la collection qu'ils représentent. On peut en définir des nouveaux, extrêmement intéressants. Je peux définir mes propres itérateurs si j'en ai envie sur les classes de collections. Il y a une subtilité. Pour ceux qui connaissent le Design pattern iterator, en fait la différence c'est que le développeur ne contrôle pas quand il passe à l'élément suivant. C'est la collection, qui en interne, décide de passer à l'élément suivant. On n'envoie pas explicitement le message "next" à l'itérateur. C'est une subtilité pour ceux qui connaissent le Design pattern iterator. En résumé, les itérateurs sont vraiment puissants et un allié fort du programmeur qui vont faciliter l'écriture des programmes. On l'a vu, ça permet d'écrire du code concis, simple et élégant et ça permet de garantir l' encapsulation des données au sein d'une collection.
+Pour chaque élément de la collection (ligne 3) je vais évaluer le block qui est passé en paramètre en lui passant l'élément à l'indice ''index'' (ligne 4).
+===== Résumé =====
+Les itérateurs sont extrêmement puissants en Pharo, comme on a pu le voir.
+  * Toutes les collections supportent ces itérateurs de façon polymorphique. Du point de vue programmeur, on utilise des itérateurs et puis c'est chacune des classes de collections qui vont les implémenter de façon adéquate par rapport à la collection qu'ils représentent.
+  * On peut en définir des nouveaux. C'est extrêmement intéressants: je peux définir mes propres itérateurs si j'en ai envie sur les classes de collections.
+  * Il y a une subtilité. Pour ceux qui connaissent le Design pattern iterator, en fait la différence c'est que le développeur ne contrôle pas quand il passe à l'élément suivant. C'est la collection, qui en interne, décide de passer à l'élément suivant. On n'envoie pas explicitement le message "next" à l'itérateur. C'est une subtilité pour ceux qui connaissent le Design pattern iterator.
+En résumé, les itérateurs sont vraiment puissants et un allié fort du programmeur qui vont faciliter l'écriture des programmes. On l'a vu, ça permet d'écrire du code concis, simple et élégant et ça permet de garantir l' encapsulation des données au sein d'une collection.

wikinotes

Outils pour utilisateurs

Outils du site

Différences

Outils de la page