(05-06-2015, 03:46 PM)Xenos a écrit :

Citation :Moi Beggar je dois m'y conformer je n'ai pas le choix, c'est une chose.

Ben oui, puisque tu as implémenté l'interface en question... ?!


Rah... Si tu vires le instanceof tu gères toujours Kid, puisque la signature de méthode n'a pas changé. C'est seulement l'algorithme interne de la méthode qui change et qui ne fait plus de distinction entre Kid et le reste des objets. Du coup, oui, tu dois lire la doc pour savoir que l'objet, parce qu'il décide de faire comme ça, ne va plus donner de fric à Kid.
T'as rien cassé de l'extérieur, t'as juste changé les décisions que la classe appelée prend.


Merci niahoo pour la séparation entre East (no return) et le reste du débat

(05-06-2015, 03:49 PM)Xenos a écrit :

Citation :Plus de condition, mon code est bien plus simple à tester et faire évoluer.

Je voudrai bien savoir comment ton code gérerait le cas "Je ne donne de l'or que si c'est un Humain et si ce n'est pas un Kid".
Mieux vaut 1 méthode de 100 lignes que 100 méthodes de 1 quand il s'agit de masquer les décisions internes de la classe.

Si je veux me faire passer pour un autre, avec ma méthode je peux (l'appelant créer juste un KidProxy par exemple et le passe à Conan).

Mais moi aussi je dis avec quel objet je sais travailler. Cela n'a pas de rapport avec comment je vais travailler avec cet objet.
Tu as:

Code :

public askGoldByKid(Kid);
public askGoldByBeggar(Beggar);
public askGoldByFemme(Femme);

Ce que l'appelant veut, c'est juste "askGold", non? Si la classe appelante est un Kid+Beggar+Femme, comment sait-elle ce qu'elle doit appeler?

(05-06-2015, 03:53 PM)niahoo a écrit : Je suppose que si tu veux donner, par exemple, double si c'est un gosse, et double si c'est une fille (décidément ...), soit 4 fois plus pour une petite fille, tu reviens à une seule méthode, interne. C'est là qu'on voit que PHP n'est pas très adapté pour ça (enfin disons très verbeux).

    public function askGoldByKid(Kid $kid)



    {

        $conan = clone $this;

        $conan->kidIsWomen = false;

        $conan->goldFactor = 2;

        $kid->areYouWomen($conan);

    }

    

    public function kidWantGoldIsWomen(Kid $kid)

    {

        $this->goldFactor * 2;

        $kid->giveGold($this->gold * $this->goldFactor);

    }

(05-06-2015, 04:06 PM)Xenos a écrit : Ton argument sur Kid n'est plus géré est fallacieux: t'as le même soucis de "Kid pas géré" si ta méthode est vide ou si la mienne n'a pas de instacenof Kid. Si tu vires le instanceof, tu décides de ne plus donner d'argent au Kid. Dans le cas présent (avec nos 3 instanceof), tu décides de donner de l'argent si c'est un Kid, une Femme ou un Beggar. Le reste, crotte.
Quand tu utilises le askGold, tu ne sais pas si le Hero va te filer de l'or. C'est lui qui décide. Si tes Kids n'en reçoivent plus, ce n'est pas un bug, c'est une décision de Hero. Il gère toujours Kid, mais il ne veut plus leur donner d'argent.

Donc, comment tu fais en terme de code pour que Hero donne:
• 1x son or à un Kid
• 0.1x son or à un Beggar (sauf Femme)
• 1.5x son or à une Femme
• 3x son or à une Femme+Kid
• 0.5x son or à un Beggar Femme
?


(accessoirement, tu vas rajouter une méthode areYou* dans chaque classe, pour chaque interface existante dans le code?! O.o)

Citation : savoir si Hero à INTENTIONNELLEMENT refusé de donner de l'or à Kid

(05-06-2015, 04:00 PM)srm a écrit :

        $kid->areYouWomen($conan);

    }

    

    public function kidWantGoldIsWomen(Kid $kid)

    {

        $this->goldFactor * 2;

        $kid->giveGold($this->gold * $this->goldFactor);

    }

Avec les interfaces mises à jour bien entendu
Là tu gères même le parallèlisme

$kid = new SmartKid();

$bruce = new BruceWillis();



$kid->areYouWoman($bruce);

(05-06-2015, 04:07 PM)niahoo a écrit : pfff donc maintentant une gamine peut se faire passer pour David Douillet si elle ne veut pas dire que c'est une petite fille et juste implémenter Beggar. À trop vouloir coller à un soi-disant comportement qu'auraient les objets dans la réalité ça devient ridicule. Pour moi passer l'objet Beggar et qu'en interne celui qui doit filer sa thune puisse inspecter l'objet aussi est tout aussi valide. Parce que en vrai c'est le programmeur qui choisit. Si quelqu'un peut dissimuler son identité cela doit aussi être implémenté.

D'ailleurs c'est un bon cas d'école. Beggar et Hero ont chacun une skill, déterminée par un score, l'un pour cacher qu'il aime les chips, l'autre pour deviner qu'il a en face de lui un authentique CrispsEater. Si le score du Hero dépasse celui du Beggar alors il ne lui donne rien ; pas question de financer son envie irrépressible de patate croustillante. Dans quelle classe ça se passe ?