Compass : East Oriented

[niahoo]

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).

[srm]

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

Je peux très bien avoir implémenter l'interface Beggar mais que mon objet en particulier refuse de l'or.


Concernant Kid, donc oui tu avais un système ou tes Kid recevaient de l'argent à chaque fois qu'ils rencontrent un Hero.
Soudain ton programme bug, un bug vicieux car tes Kids ne recoivent plus d'argent quand ils rencontrent un Hero.

Pourquoi ? Car le Hero ne gère plus, ça n'est pas ce qu'il décide de ne pas donner de l'argent à un Kid, c'est qu'il ne GERE PLUS un Kid.

Ca peut donc soit être une feature voulu, soit un comportement imprévu. Tu peux être dans les deux cas.
En East tu ne peux pas avoir ce cas. Vu que tu DOIS implémenter la méthode askGoldByKid, si tu la mets vide tu sais PERTINEMENT que tu décides de ne rien faire quand un Kid te demande de l'argent.

[srm]

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?

Tu peux très bien faire un KidProxy en East aussi rien ne t'y empêches.
La classe appelante décide comment se présenter au Héro, j'en ai déjà parlé dans les pages précédentes.
C'est typiquement le cas d'un Policier en civile qui se présente à une personne, c'est le Policier qui décide de se présenter comme un Civile ou un Poçlicier, c'est pas la personne qui va le décider.

[srm]

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);

    }

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

[Xenos]

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)

[niahoo]

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 ?

[srm]

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)

Comment tu fais pour savoir si Hero à INTENTIONNELLEMENT refusé de donner de l'or à Kid ou si il ne le gère plus suite à une mise à jour, un oubli, un changement de périmètre fonctionnel, etc ? Si c'est pas défini dans un contrat, c'est impossible à savoir. Tu as beau arguer comme tu veux.

Pour chaque besoin fonctionnel je vais l'ajouter oui.

[Xenos]

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

C'est pas défini dans le contrat que askGoldByKid() file du pognon à Kid. Comment tu sais si la méthode vide est intentionnelle ou non? T'as le même problème.

En revanche, c'est marqué dans le contrat PHP7 que public function goldCoin giveGold($something); renverra forcément du pognon à l'appelant, ou null.

[niahoo]

Ton exemple est pas bon

        $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

Mais là, si je fais :

$kid = new SmartKid();

$bruce = new BruceWillis();



$kid->areYouWoman($bruce);

pasque bruce il veut savoir si c'est une fille, mais pas lui filer du blé. Mais là, la fifille elle va appeler kidWantGoldIsWomen c'est bien comme ça que ça fonctionne ? Et donc Bruce il va lui filer du blé. Non ton exemple n'est pas bon, t'es censé juste stocker le fait que la fille est une fille (alors que si bruce ouvre les yeux il voit bien que c'est un judoka de 120kg mais passons).

En East c'est donc dans la méthode askGold que l'on doit appeler giveGold. (mais bon tu le sais, tu as juste fait un exemple rapide, je sais bien).

edit et tu ne gères pas le parallélisme, tes clones ne tapent pas dans la même réserve de thunes, tu as multiplié ton or. Mais ceci est accessoire.

[srm]

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 ?

Comme tu veux, ça dépend qui demande à qui.
Sauf qu'en collant en East tu te rends compte qu'au final tu n'as jamais besoin de te demander si tu vas casser un objet externe en changeant le tien. Tu modifies ton objets, met à jour des interfaces si tu en as le besoin, tu sais immédiatement qui mettre à jour car tu vois ceux qui utilisent cette interface et si tu le fais pas de toute façon dès le lancement tu vas avoir un bug.

En dehors de ça au final ça ne pose aucun soucis.
Le seul soucis que ça pose est moral et au niveau des habitudes, car on est pas habitué à coder de cette façon, on a appris à mal utiliser l'objet et ça dès l'école.