Compass : East Oriented

[srm]

Si le setter est un ordre donné à la classe, on n'est pas dans le je te fais confiance. Sinon, le setBroken doit aussi être testé dans le contexte présente (aka, le test précédent teste à la fois setBroken et userWantsToWatchYou).

C'est pas exactement un ordre en fait. C'est une initialisation. Et je lui fais confiance pour s'initialiser correctement.
Si c'était un comportement je lui aurais dis "je veux te casser" et la télé aurait pu me dire "je suis incassable" et ne rien faire, ou se casser.

Pourquoi le fait que la classe appelée fasse le tri Barman/Policier ne serait pas Open/Close?
Okay, le BarmanPolicier en East peut se présenter comme l'un ou comme l'autre. Et s'il veut se présenter comme les deux? Perso, je dirai que cela rajouterait une interface (BarmanAndPoliceman), mais là encore on effondre la combinatoire.

Parce que tu dois modifier du code existant pour rajouter des instanceof
Si quelqu'un est à la fois un Barman et un Policier et que l'on a besoin de ça... Je t'avoue que je vois pas trop de cas concret et que je ne sais pas trop comment on résoudrait ça proprement.
Mais peut-être avec une autre interface qui est la composition des deux.

Si getReligion est déjà dans Consumer (ça aurait plus sa place dans Human d'ailleurs), il n'y a rien à changer à l'interface en West. C'est un cas probable, puisque le getReligion est commun à plusieurs (toutes) interfaces appelantes. En revanche, en East, il faudra forcément la changer puisqu'il n'y a aucune chance que Barman ait déjà son askReligionByBarman. C'est le soucis de réutilisation introduis par les askWhatByWho.

Le soucis et l'avantage de la souplesse et des modifications open/close, puisqu'au moins je peux lui répondre ce que je veux au Barman alors qu'avec un getter je ne peux pas.

Si Beaucoup plus de classes tierces impactées et encore heureux., alors ton code est tentaculeux, et le moindre changement va impliquer des modifications partout, ce qui va rendre la maintenance affreuse. L'interface n'a pas vocation à changer (Open/Close principle), et East oblige à modifier 2 interfaces pour inclure la religion, alors que West n'en modifie au pire qu'une (getReligion, et encore on peut s'en passer en créant de nouvelles interfaces, une nouvelle classe et le pattern Decorator/la composition) voire, 0 (c'est le code interne qui change).

Partout faut le dire vite, il y a pas 50 classes qui dépendent d'une interface.
Et quoi qu'il en soit, ça a toujours été le principe des interfaces.
Montre voir ce que ça donnerait avec ton decorator et composition, ça sera plus facile ensuite pour pointer les soucis que ça provoque cette solution.

[Xenos]

Le soucis et l'avantage de la souplesse et des modifications open/close, puisqu'au moins je peux lui répondre ce que je veux au Barman alors qu'avec un getter je ne peux pas.

Je n'ai pas compris la phrase :\ Je re-soulève le point que PHP n'a pas de typage de retour (les type hintings sont tous facultatifs).

Peut-être pas 50 classes, okay, mais plusieurs, ce qui veut dire que les changements devront être fait à d'autres endroits du code que là où le changement est demandé. Faudrait, pour éviter cela, que East permette d'avoir une approche d'ajout d'interfaces plutôt que d'édition d'interfaces.


Supposons que getReligion n'existe pas pour le consommateur, et que le barman veuille la prendre en compte pour savoir s'il sert ou non. Je vais élaguer le code d'exemple.

---

Situation actuelle (West):

Code PHP :

<?php 

interface IAlcoholConsummer {

    public askAge();

}



interface IBarman {

    public giveAlcoholTo(IAlcoholConsummer $consummer);

}



class Client implements IAlcoholConsummer {

    public askAge() {

        // histoire de montrer que c'est pas forcément un "getter"

        return (new Date(Date.now() - $this->birthday)).asYear();

    }

}



class Barman implements IBarman {

    public giveAlcoholTo(IAlcoholConsummer $consummer) {

        // Note qu'on présume que askAge renvoie un age en année,

        // Il serait plus pertinent de ne pas présumer puisque ce n'est pas dans le contrat d'interface

        return ($consummer->askAge() > $this->minAge) ? new Alcohol() : null;

        // ou Alcohol.NULL dans le cadre du null-object pattern / typehinting du retour

    }

} 

[srm]

Le soucis et l'avantage de la souplesse et des modifications open/close, puisqu'au moins je peux lui répondre ce que je veux au Barman alors qu'avec un getter je ne peux pas.

Je n'ai pas compris la phrase :\ Je re-soulève le point que PHP n'a pas de typage de retour (les type hintings sont tous facultatifs).

C'est bien ce que je dis, c'est un soucis certes dans une certaine mesure, mais cette méthode à d'avantage de souplesse et vu que j'ai askAgeByBarman($barman) je peux très bien faire : $barman->userAgeIs($this->age + 30);
Donc mentir à un Barman mais si j'ai askAgeByStats là je vais répondre $this->age.
Avec getAge() je ne peux pas faire ce genre de choses. Je ne suis pas souple.

Peut-être pas 50 classes, okay, mais plusieurs, ce qui veut dire que les changements devront être fait à d'autres endroits du code que là où le changement est demandé. Faudrait, pour éviter cela, que East permette d'avoir une approche d'ajout d'interfaces plutôt que d'édition d'interfaces.

Dans ton exemple tu montres toi même deux problème avec ta méthode.
// Note qu'on présume que askAge renvoie un age en année,
// Il serait plus pertinent de ne pas présumer puisque ce n'est pas dans le contrat d'interface

Ca c'est un soucis majeur.
Tu as des interfaces mais tu ne peux pas te reposer dessus pour avoir un code fiable alors que c'est leur but et principe.

Et que tu nommes askAge ou getAge tu est obligé de faire le même type d'action quelque soit l'objet qui le demande.
Tu n'as pas de soupless et d'extensibilité possible selon ne type d'objet qui te demande l'information.

Tu dois modifier toutes les classes qui implémente l'interface oui.
C'est là que le semver devient important.
Et qui fait que justement ça coincera pas. Mais respecter le semver n'a pas de rapport avec East en soit.
C'est juste utiliser des bonnes pratiques, le problème que tu soulèves se pose aussi quand tu ne fais pas du East.

Et c'est parfaitement logique, de toujours respecter les interfaces et n'utiliser que ce qu'elles définissent permet d'éviter pas mal d'erreurs masquées.

La méthode de composition que tu proposes, tu peux la faire aussi en East, mais tu as moins de souplesse si tu fais comme ça.
Si tu veux avoir comportement askAge différent si la personne qui te le demande est religieuse ou non, tu es bloquée.
Ou alors tu vas devoir ajouter des instanceof. Donc ne pas respecter l'open/close principe et en plus tu vas devoir connaître l'objet extérieur avec lequel tu travails, donc une dépendance plus forte.

[niahoo]

$tv->smashedByBaseballBat() ?

Bon par contre je suis en train de regarder l'exemple de phpTour2015 et c'est l'exact opposé de ce que j'aime faire en programmation.

Absolument tout repose sur des contre-contre-appels de fonctions avec une modification de $this implicite pour dire "le client en cours a l'age de boire". J'aime bien l'idée de East mais l'implémentation donnée en exemple est vraiment bof.

[Xenos]

Avec getAge() je ne peux pas faire ce genre de choses. Je ne suis pas souple

Je te le redis: oui, tu le peux (à condition de passer l'appelant en paramètre du getAge; sinon, ça repose sur la stacktrace, et c'est plutôt lent), et c'est la responsabilité de la classe appelée (et non de l'appelante) qui est engagée (via instanceof ou n'importe quel autre mécanique interne).

Exemple:

Code PHP :

<?php 

class Client implements IClient {

    private $combienDeFoisLINSEEMaDemande = 0;

    public function getAge($caller) {

        // discriminer via instanceof

        // ou via n'importe quel autre critère

        // comme le nombre de sollicitations de l'INSEE

    }

}



class Barman {

    //...

    $client->getAge($this);

} 

[srm]

$tv->smashedByBaseballBat() ?

Bon par contre je suis en train de regarder l'exemple de phpTour2015 et c'est l'exact opposé de ce que j'aime faire en programmation.

Absolument tout repose sur des contre-contre-appels de fonctions avec une modification de $this implicite pour dire "le client en cours a l'age de boire". J'aime bien l'idée de East mais l'implémentation donnée en exemple est vraiment bof.

Qu'est ce qui t'embête en soit ?

[srm]

Avec getAge() je ne peux pas faire ce genre de choses. Je ne suis pas souple

Je te le redis: oui, tu le peux (à condition de passer l'appelant en paramètre du getAge; sinon, ça repose sur la stacktrace, et c'est plutôt lent), et c'est la responsabilité de la classe appelée (et non de l'appelante) qui est engagée (via instanceof ou n'importe quel autre mécanique interne).

Exemple:

Code PHP :

<?php 

class Client implements IClient {

   private $combienDeFoisLINSEEMaDemande = 0;

   public function getAge($caller) {

       // discriminer via instanceof

       // ou via n'importe quel autre critère

       // comme le nombre de sollicitations de l'INSEE

   }

}



class Barman {

   //...

   $client->getAge($this);

} 

[Xenos]

instanceof ne t'impose en rien de connaitre le monde extérieur: c'est un opérateur, et au même titre que tout autre opérateur, tu peux le lire instanceof($object, $instanceName) au lieu de $object instanceof $instanceName si tu préfères. Je ne vois pas en quoi cela te gène.
Ajouter une classe ne casse en rien le code existant, puisque le typehinting t'assures que le paramètre implémente telle interface. Que le paramètre soit une nouvelle classe implémentant d'autres interfaces, tu t'en fiches complètement. Donnes-moi un cas concret avec du code où cette histoire d'instanceof gènerait. Donne-moi le cas-code où l'ajout de la classe va détruire mon code et mes instanceof.

Montre-moi 1) en quoi instanceof c'est "connaitre l'univers qui m'entoure", et 2) un code où ajouter des classes et interfaces comme précédemment casserait tout sans que je ne le vois.

[srm]

class Bouh

{

   public function hello($data)

   {



   }

}

Tu mets quoi comme instanceof dans ce code ?

class Bouh

{

   public function hello(Data $data)

   {



   }

}

Hop, aucun soucis tu as toutes les infos qu'il faut pour travailler.

[Xenos]

Tu mets les instanceof dont la méthode a besoin pour faire son boulot.
Dans le 2nd cas, tu sais que tu bosses avec un truc implémentant obligatoirement l'interface Data. Mais ce "truc" peut implémenter d'autres interfaces. Tu as le droit d'interroger ce $data pour lui demander si c'est un Age ($data instanceof Age) et d'agir en conséquence.
Dans le 1er cas, pareil, sauf que tu bosses avec un $data encore plus large (c'est "un truc quelconque").

Tu confonds la signature de la méthode, qui dit "Je n'accepte ce message que si tel paramètre implémente telle interface", sa documentation qui dit voici ce que je fais, et son algorithme interne qui est voilà comment je le fais. Cet algorithme est caché au monde extérieur (et c'est bien). Qu'il se base sur le fait que tel paramètre est de tel type, que tel paramètre est de tel autre type et renvoie tel autre résultat, de l'extérieur, on s'en fiche.

Ma boîte est en fait tellement noir que l'extérieur ne sait même pas qu'elle fait une discrimination en fonction des interfaces de ses paramètres. Et dans le 1er cas, elle connait encore moins de choses sur l'extérieur (puisqu'elle doit interroger cet extérieur à coup d'instanceof).