Compass : East Oriented

[Xenos]

Rah, non, ce n'est pas "je ne veux pas de typehinting sur askGold", c'est "le typehinting ne te dis pas que toutes les valeurs du paramètre seront traités de la même façon par la méthode". Ce dont je ne veux pas, c'est ajouter des méthodes (publiques) juste parce que la classe, dans son algo interne, différencie tel et tel objet (sur la base de leur classe), parce que va maintenir un code de 100k lignes quand, à chaque fois qu'il faut ajouter une feature, tu dois modifier les interfaces existantes puis ajouter les méthodes partout où ces interfaces sont implémentées (alors que ces classes n'ont aucun lien avec la feature ajoutée).

Oui, tu dois lire la doc de la classe pour savoir la logique de cette classe pour cette méthode. Ce qui n'a rien à voir avec le fait de ne pas lire la doc pour savoir quels messages la classe comprend.

[srm]

en West tu fais ce que tu veux, donc généralement du code crade ou lorsque tu modifies une classe tu dois regarde les autres classes qui l'utilise pour ne rien casser.

.

Heuuu je vais dire un truc gamin mais prends pas ton cas pour une généralité ... Fondamentalement ça ne change rien, un objet va faire sa vie de son côté puisque il est encapsulé dans son espace propre. Non parce que dans ton exemple, giveGold si c'est pas un setter moi je pige que dalle.

En East on aura :

public function giveGoldByHero(Gold $gold, Hero $hero);

Ca n'est pas un setter parce que je ne dis pas à Beggar ce qu'il doit faire de l'or.
Il peut très bien avoir une méthode vide et ne rien en faire.
Ou si l'interface de Hero le stipule quelque chose du genre : $hero->injury($this);

Donc je dis juste "moi $hero je te donne $gold", le Beggar en fait ce qu'il veut.


En West ton objet va faire getGold() au lieu de askGold() c'est lui qui impose le format de sortie.
Moi Beggar je dois m'y conformer je n'ai pas le choix, c'est une chose.
Et une seconde chose, j'impose au Hero de me retourner de l'or, soit 0 soit plus.
Mais je ne lui laisse pas la liberter de faire ce qu'il veut. Donc mon code est moins souple.

[srm]

Non mais ça d'accord, moi je suis d'accord. Mais quel rapport avec East/West ? là c'est un choix d'écriture, ben ok, c'est compatible à la limite donc osef.

C'est pas vraiment un choix d'écriture.
Si tu mets des instanceof dans ton programme, on doit lire ton code pour savoir ce que fait ton code.
Ce qui veut dire que lorsque tu modifies le fonctionnement INTERNE de ton objet tu peux casser l'extérieur.
Imagine je vire "if ($object instanceof Kid)".
J'ai changé un fonctionnement INTERNE de mon objet et pourtant j'ai cassé l'extérieur, je ne sais plus du tout
gérer un objet Kid. Et de l'extérieur on en sait rien du tout, on ne peut pas le savoir sans lire le code.

Vas-tu à chaque mise à jour d'une librairie aller voir le code interne d'une classe ? Non.
Est-ce qu'une librairie va signaler dans le changelog le fonctionnement interne d'une classe ? Non.
Est-ce que la doc le mentionnera ? Non elle ne documente pas le fonctionnement interne ça n'a pas de sens.

[niahoo]

Non mais un setter aussi l'objet fait ce qu'il veut dedans. Aucun rapport là. Comme disait Xenos, si le besoin est là, on peut passer le "giver" dans le setter. ça ce n'est pas propre à East.

Code :

class Hero {
    public function askGold(Beggar $beggar) {
        // ...
        return new Gold(this->gold/10);
    }

ça c'est du West. Et là il n'y a pas de type check sur la valeur de retour, nous somme d'accord.

edit: et par rapport à ton dernier post : oui, je suis d'accord, tu peux explicitement déprécier la compatibilité avec un Kid. Mais avec des getters c'est possible aussi. C'est juste que généralement tu n'as pas besoin de typer un getter.

[Xenos]

Et entre des deux exemples, c'est dans lequel où le monde extérieur a plus d'informations sur l'algorithme interne de la classe? Dans giveGold(GoldReceiver) (je te rappelle que j'ai jamais dit que le typehinting était interdit, juste que le typehinting n'a pas à refléter l'algorithme interne de la méthode) ? Ou dans askGoldBy*?

Et le plus simple à maintenir, c'est quoi? 3 méthodes publiques dans une interface? Ou une seule? Et niveau évolutivité, si tu veux donner plus d'or à un Beggar+Kid+Femme tu fais comment dans ton code? Et pour donner moins à un Kid+!Femme?

Je ne vois pas en quoi faire transpirer ainsi l'algorithme interne d'une méthode dans sa signature publique est une bonne chose.

[srm]

Rah, non, ce n'est pas "je ne veux pas de typehinting sur askGold", c'est "le typehinting ne te dis pas que toutes les valeurs du paramètre seront traités de la même façon par la méthode". Ce dont je ne veux pas, c'est ajouter des méthodes (publiques) juste parce que la classe, dans son algo interne, différencie tel et tel objet (sur la base de leur classe), parce que va maintenir un code de 100k lignes quand, à chaque fois qu'il faut ajouter une feature, tu dois modifier les interfaces existantes puis ajouter les méthodes partout où ces interfaces sont implémentées (alors que ces classes n'ont aucun lien avec la feature ajoutée).

Oui, tu dois lire la doc de la classe pour savoir la logique de cette classe pour cette méthode. Ce qui n'a rien à voir avec le fait de ne pas lire la doc pour savoir quels messages la classe comprend.

Tu préfères avoir 100 méthodes de 1 ligne ou 1 méthode de 100 lignes ?
Tous les guides de programmation te recommanderons d'avoir 100 méthodes de 1 ligne.
On découpe le plus possible, tu imagines quand même que pour cet exemple précis je n'ai même plus de if ?!
Plus de condition, mon code est bien plus simple à tester et faire évoluer.

Concernant la doc j'ai répondu plus haut.

[srm]

Non mais un setter aussi l'objet fait ce qu'il veut dedans. Aucun rapport là. Comme disait Xenos, si le besoin est là, on peut passer le "giver" dans le setter. ça ce n'est pas propre à East.

class Hero {

   public function askGold(Beggar $beggar) {

       // ...

       return new Gold(this->gold/10);

   }

ça c'est du West. Et là il n'y a pas de type check sur la valeur de retour, nous somme d'accord.

Sauf déjà que là encore une fois tu as plusieurs soucis.
Ta méthode à comme comportement par défaut de retourner une valeur.
Donc tu en retournes toujours une ? Et si tu ne veux pas donner de l'or quand on t'en demande tu fais comment ?

[Xenos]

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

[srm]

Et entre des deux exemples, c'est dans lequel où le monde extérieur a plus d'informations sur l'algorithme interne de la classe? Dans giveGold(GoldReceiver) (je te rappelle que j'ai jamais dit que le typehinting était interdit, juste que le typehinting n'a pas à refléter l'algorithme interne de la méthode) ? Ou dans askGoldBy*?

Et le plus simple à maintenir, c'est quoi? 3 méthodes publiques dans une interface? Ou une seule? Et niveau évolutivité, si tu veux donner plus d'or à un Beggar+Kid+Femme tu fais comment dans ton code? Et pour donner moins à un Kid+!Femme?

Je ne vois pas en quoi faire transpirer ainsi l'algorithme interne d'une méthode dans sa signature publique est une bonne chose.

Si tu veux donner plus d'or à un Beggar Kid Femme, tu peux par exemple quand tu reçois un Beggar lui dire :
$beggar->areYouWomen($this)
Et là libre à lui de te le dire, il peut avoir honte et ne pas vouloir te le dire.
Avec ta méthode il ne peut pas.

On ne fait pas du tout transpirer comme tu dis l'algo dans les méthodes, on dit avec quel objet on sait travailler, c'est bien différent. Afin de pouvoir modifier son comportement interne sans risque de casser ce qui gravite autour de la classe.

[Xenos]

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?