Compass : East Oriented

[srm]

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.

Elle est forcément intentionnellement vide car tu as du créer la méthode.
Alors que dans askGold tu n'as rien à faire pour ne pas avoir de if pour Kid.
et ton soucis en PHP7 avec giveGold c'est que si tu veux faire autre chose que retourner du Gold car tu es dans un cas particulier, tu ne peux pas. Donc tu restreints ton code il est moins souple.

[srm]

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.

Oui une erreur en effet, mais comme tu le dis je fais un code à chaque fois vite fait
J'ai géré le parallélisme au niveau des demandes, quand un Kid demande de l'or à un Hero il rentre en dialogue exclusif avec lui un autre Kid ne peux pas répondre à la place de l'autre c'est tout.

[srm]

Il faut bien garder à l'esprit que coder en East ne pose pas de problème technique.
Nécessite juste bien plus de méthodes avec du petit code que peu avec beaucoup de codes (et ça n'a rien d'un mal ça, au contraire) et de penser sa façon de programmer différemment.

Tu codes 100% avec des interfaces, si tu fais évoluer une interface, tu sais immédiatement ce qui casse et que tu dois mettre à jour.
Et pour chaque appel de méthode tu as plus de souplesse de faire ce que tu veux selon les possibilités de l'interface qui t'appelle.

Donc au final, je ne comprends pas trop pourquoi il y a un tel blocus.

[Xenos]

Ouep, tu dois retourner du Gold parce que t'as choisi d'implémenter l'interface avec un return Gold. La classe respecte le contrat qu'elle a choisi de passer, c'est pas une bonne chose ?

Non, le Kid rentre en dialogue exclusif avec un nouveau Hero (le clone), pas avec le Hero qu'il a appelé (si on parlait en pointeurs, on le verrait direct).

Je suis d'accord, il n'y a pas de problème technique de fond. Juste que East ajoute beaucoup de méthodes publiques (tout autant de maintenance et de risque de cassure), utilisées généralement par un seul point du code. T'as le droit de décomposer la grosse méthode en méthodes private pour l'alléger.

Y'a pas de rapport entre East et les interfaces: tu peux faire du bon West en faisant 100% d'interfaces. East, c'est pas l'interface seggregation.


J'attends toujours que tu me montres ton code pour faire "Hero donne 1x son or à Kid, 0.1x à Beggar, 2x à Femme, et 3x à Beggar+Kid+Femme".

[niahoo]

et ton soucis en PHP7 avec giveGold c'est que si tu veux faire autre chose que retourner du Gold car tu es dans un cas particulier, tu ne peux pas. Donc tu restreints ton code il est moins souple.

Mais qui veut faire ça !?! Non, allez, sérieusement, on fait pas ça. C'est le maaal.

Pour ma part il n'y a pas de blocus, je trouve ça même très bien pour gérer une transaction assez compliquée entre deux objets. Mais pour l'appliquer à tout un projet pour des trucs aussi futiles que refiler une pièce jaune à David dans son TGV, non-merci, quelques tests bien sentis et une bonne méthode classique me conviennent généralement mieux.

edit: Tu ne peux pas prôner la souplesse là (surtout pour promouvoir une pratique bien dégueu) et prôner avant la rigidité d'avoir des méthodes publiques au lieu d'utiliser des instanceof qui sont plus souples. Faut être quand même cohérent et éviter les vieux sophismes.

[niahoo]

$conan = clone $this;

Tu clone le héros. C'est lui qui file de la thune. Tu as cloné sa thune. Tu ne gères pas le parallélisme.

[srm]

Ouep, tu dois retourner du Gold parce que t'as choisi d'implémenter l'interface avec un return Gold. La classe respecte le contrat qu'elle a choisi de passer, c'est pas une bonne chose ?

Si, le seul soucis, c'est que ta méthode ne peut plus rien faire d'autre.

Non, le Kid rentre en dialogue exclusif avec un nouveau Hero (le clone), pas avec le Hero qu'il a appelé (si on parlait en pointeurs, on le verrait direct).

Il est donc bien en dialogue exclusif avec le Héro copie ou non, dans le sens ou lui seul connait cet instance de Héro et lui seul peut agir avec lui, c'est donc bien un dialogue exclusif non ?

Je suis d'accord, il n'y a pas de problème technique de fond. Juste que East ajoute beaucoup de méthodes publiques (tout autant de maintenance et de risque de cassure), utilisées généralement par un seul point du code. T'as le droit de décomposer la grosse méthode en méthodes private pour l'alléger.

Y'a pas de rapport entre East et les interfaces: tu peux faire du bon West en faisant 100% d'interfaces. East, c'est pas l'interface seggregation.

Oui bien d'accord. Mais si tu mets un getter, au final tu ne laisses pas vraiment au Héro de décider ce qu'il doit faire.
Comment tu fais pour que le Héro mette un coup de poing à Kid si il est mal luné ?

if ($hero->badMood() === true) {



    $kid->kickedBy($hero);

} else {

    $kid->giveGold($hero->getGold());

}

Un truc du genre non ? Au final l'algo de ton Hero est en dehors de ton Hero :/

J'attends toujours que tu me montres ton code pour faire "Hero donne 1x son or à Kid, 0.1x à Beggar, 2x à Femme, et 3x à Beggar+Kid+Femme".

J'ai donné un exemple Beggar + Femme, tu as qu'à extrapoler pour le reste

[srm]

$conan = clone $this;

Tu clone le héros. C'est lui qui file de la thune. Tu as cloné sa thune. Tu ne gères pas le parallélisme.

Ok, comme je disais, plus haut je gère le parallèlisme au niveau de la discussion pas de la déduction de Gold

[Xenos]

Je ne comprends pas ton argument: oui, elle ne peut rien faire d'autre: elle implémente l'interface qui dit "retourne ça". Pour moi, c'est comme si tu disais que la classe implémente l'interface Truc, donc elle est obligée d'implémenter Machin(Bidule $bidule): c'est pas souple.

Non, si mon Hero colle un pain au Kid, c'est du ressort de giveGold():

Code :

class Hero... {
    public function giveGold($object) {
        if ($this->malLune && $object instanceof Kid)
            $object->pafDansLePif();
        // Je sais que $object implémente Kid via instanceof, l'auto-complétion va donc me proposer cette méthode
        else {
              //...
        }
    }
}

J'attends l'exemple Beggar + !Femme parce que je ne vois pas comment tu l'extrapole.

[niahoo]

$conan = clone $this;

Tu clone le héros. C'est lui qui file de la thune. Tu as cloné sa thune. Tu ne gères pas le parallélisme.

Ok, comme je disais, plus haut je gère le parallèlisme au niveau de la discussion pas de la déduction de Gold

Bon ça sert à rien quoi OK, c'est plus clair comme ça.