[JS] Boucle for..in Array et ajout de methodes via prototype = conflit?!

[Xenos]

Le pattern strategy n'est pas totalement incompatible avec cette notion "atomique". En un sens, on peut "fusionner" deux atomes (Personnage et EspritCombatif dans l'exemple du SdZ), mais on ne peut pas récupérer l'élément "soin". Un peu comme si on pouvait fusionner des atomes, mais pas les scinder, ce qui ne contredit pas la notion d'objet indivisible (deux objets indivisibles n'ont pas de raison de ne pas pouvoir être fusionnés, mais après fusion, on perd la séparation entre ces objets). De l'extérieur de la classe "Personnage", je ne peux pas accéder à l'objet "EspritCombatif". Au mieux, je peux avoir une méthode qui va me renvoyer un objet "EspritCombatif", mais je ne peux pas dire que cet objet "EspritCombatif" était un composant de "Personnage".

Ce qui me gène dans la Bibliothèque pour laquelle on itère sur les Livres, c'est que l'on considère que les Livre renvoyés par la bibliothèque sont ceux que la Bibliothèque contient. A mon sens, dès l'instant où j'ai envoyé le Livre dans la Bibliothèque, j'en "perd" la trace, car je ne suis pas censé savoir comment la Bibliothèque va manipuler ce livre.

(Après, le débat sera sans fin ^^ Je comprend le point de vue que vous avancez, mais je n'aime pas utiliser ce point de vue là, et je préfère avoir des objets "atomiques", même lourds, plutôt que de considérer que les objets et les conteneurs comme la Bibliothèque sont la même chose et fonctionnent pareil)

[srm]

Tu préfères mal coder en résumé.
A ta guise

[niahoo]

Les quoi le problème avec les dossiers contenant trois voire un seul fichier ... L'important ce n'est pas que l'objet soit petit mais qu'il soit congru. C'est comme pour les fonctions, qui ne doivent faire qu'une seule chose, et bien. Un objet ne doit gérer qu'une seule chose, et bien. Un paragraphe par idée, une idée par paragraphe comme dirait l'autre.

---

À ce propos, il faut vraiment revoir ta notion de "atomique".

Quand tu envoies un livre dans la bibliothèque, tu en perds la trace. Mais tu peux quand même récupérer le livre a posteriori (sinon la bibliothèque ne sert à rien). Ceci n'est absolument pas incompatible avec ce que je raconte depuis X posts. Encore une fois, pouvoir itérer sur le contenu d'une collection ne remet pas en cause l'encapsulation du moteur de stockage de cette collection et de la fonction dont elle fonctionne.

[Xenos]

tu peux quand même récupérer le livre a posteriori (sinon la bibliothèque ne sert à rien).

Justement, je pense que non (dans le cas d'un objet, pas d'une collection, sachant que je distingue les deux comme je distinguerait un atome d'une molécule).
Si tu prends du sel, et que tu le dissous dans l'eau, tu en perds la trace. Ensuite, tu fais évaporer l'eau (aka, la bibliothèque fait son petit bazar), et tu récupère à nouveau du sel.
Ok, tu auras la même masse (ou quantité) de sel (en supposant que seule l'eau s'est évaporée), mais rien ne te garantis que le sel récupéré est composé des mêmes atomes (pire, des mêmes électrons) que le sel initial.
Mon principe se situe à ce niveau là, en permettant de distinguer un objet "véritable" (ou "pur") comme l'eau saline, d'une simple collection (un sac avec une bouteille d'eau et une salière).

Donc, on ne "récupère pas le livre", mais on récupère un livre.
Peut-être que, oui, c'est "mal codé", au sens où ce n'est pas les conventions usuelles, mais cela devient très agréable à utiliser quand on est en présence de miriades d'objets. Si, par exemple, j'ai une carte de jeu qui, de base, est composée de cases, alors avec un modèle classique, je pourrait ajouter une case, puis la récupérer ensuite. Avec un modèle "atomique", j'ajoute une case, et je récupère une case, mais aucune garantie d'avoir les mêmes. Je peux alors changer, dans le contenu de ma carte, les cases par une fonction continue (heightmap) par exemple. En effet, à ce moment là, la case peut toujours être envoyée à la carte (la fonction continue sera modulée) et elle peut toujours être récupérée (calcul de la hauteur de la heightmap en un point). Mais je n'ai pas la garantie que ce sera la même case.

Quand tu dis "un objet gère une seule chose", il faudrait préciser ce que tu entends par "chose", car si une fonction ne doit faire qu'une seule chose, et qu'un objet ne doit faire qu'une seule chose, je ne vois pas comment un objet pourrait avoir la possibilité de définir plusieurs fonctions (ou méthodes)... Il ferait alors plusieurs "choses" O.o

[srm]

On va faire simple Xenos vu que tu comprends rien.
Donne un code, de 50 à 200 lignes qui est codé à ta façon et montre l'utilité et la puissance de ton code.

Et je coderais la même version en objet propre tu comprendras mieux.

[Xenos]

Ok.

Voilà donc ce que je propose:

Code PHP :

<?php



    /*objet*/

    class Livre

    {

        private /*string*/ $titre;

        private /*string*/ $texte;

        public function __construct(/*string*/ $p_titre, /*string*/ $p_texte)

        {

            $this->titre = $p_titre;

            $this->texte = $p_texte;

        }

        public /*string*/ function getTitre()

        {

            return ($this->titre);

        }

    }

    

    /*conteneur*/

    class ConteneurLivre

    {

        protected $livres;

        public function __construct(/*array[Livre]*/ $p_livres=array())

        {

            $this->livres = Array();

            foreach ($p_livres as $clivre)

                $this->stack($clivre);

        }

        public function stack(/*Livre*/ $p_livre)

        {

            $this->livres[] = $p_livre;

        }

        public /*Livre*/ function unstack()

        {

            return (array_pop($this->livres));

        }

        public /*Livre*/ function getLivre(/*string*/ $p_titre)

        {

            foreach ($this->livres as $key=>$clivre)

            {

                if ($clivre->getTitre() == $p_titre)

                {

                    unset($this->livres[$key]);

                    return ($clivre);

                }

            }

        }

    }

    

    /*objet*/

    class Bibliotheque

    {

        private /*ConteneurLivre*/ $livres;

        

        public function __construct()

        {

            $this->livres = new ConteneurLivre();

        }

        public function addLivre(/*Livre*/ $p_livre)

        {

            $this->livres->stack(clone $p_livre);

        }

        public /*Livre*/ function getLivre(/*string*/ $p_titre)

        {

            return ($this->livres->getLivre($p_titre));

        }

    }



    

    // Main

    $myBook = new Livre('Lorem Ipsum', 'Lorem ipsum dolor sit amet, consectetur adipisicing elit,...');

    

    $bibliotheque = new Bibliotheque();

    $conteneur = new ConteneurLivre();

    

    $bibliotheque->addLivre($myBook);

    $conteneur->stack($myBook);

    

    $myOtherBook = $bibliotheque->getLivre('Lorem Ipsum');

    $myOtherOtherBook = $conteneur->getLivre('Lorem Ipsum');

    

    assert($myBook === $myOtherBook);                //false

    assert($myBook === $myOtherOtherBook);            //true

    assert($myOtherBook === $myOtherOtherBook);        //false

?>

[niahoo]

Non une fonction ne fait qu'une seule chose, par exemple enregistrer un livre, récupérer un livre, traduire un livre, etc. Un objet ne **gère** qu'un seule chose, par exemple une collection de livres. C'est plutôt simple comme concept.

Bon et donc pour reprendre ta métaphore sur le sel, excuse moi mais c'est n'importe quoi. Quand je stocke un livre dans une bibliothèque, je veux pouvoir récupérer exactement ce livre, et pas une version dissoute dans l'eau avec l'encre à moitié effacée, des pages d'un autre livre et le dernier chapitre en anglais. non merci.

[Xenos]

D'accord pour le distingo Faire / Gérer.

Si tu préfères ainsi fais donc Je préfère de mon coté stocker les objets dans des Conteneurs qui ne font rien d'autre que stocker (ils ne gèrent que le fait de stocker) et envoyer des objets à manipuler à d'autres objets, sans espérer les récupérer exactement après le traitement.

[niahoo]

Bon allez, je montre mon code.

$bibliothèque = [];

---

Je préfère de mon coté stocker les objets dans des Conteneurs qui ne font rien d'autre que stocker (ils ne gèrent que le fait de stocker)

Je me tue à démontrer que c'est le but d'une bibliothèque

et envoyer des objets à manipuler à d'autres objets, sans espérer les récupérer exactement après le traitement.

Pourquoi s'infliger cette contrainte. Reste atomique : stockage, pas partage.

[srm]

En gros tout ce que tu as dit c'est du bullshit car dans ton exemple tu fais qu'utiliser le pattern adaptateur.
De plus tu le fais mal, sans injection de dépendance, du coup ton code est intestable (au sens test unitaire).