Compass : East Oriented

[srm]

J'en reviens quand même aux objections précédentes:

• Si on veut faire de la bio, on la fait jusqu'au bout, et on lance la bouteille à la mer et non à un objet; d'ailleurs, c'est First Come First Served (la première cellule captant la molécule du message détruit cette molécule).

On ne veut pas faire de la bio. On copie dans une certaine mesure cet univers pour permettre d'avoir une bonne abstraction.

• Que les langages OO actuels comme Java ne soient pas de purs OO, oui, c'est vrai. Mais on se plie au langage qu'on choisit: s'il existe un langage OO pur, sans return, pourquoi pas, cela se tente, mais forcer les langages OO "classiques" à se plier à ce pour quoi ils ne sont pas conçus, c'est inefficace. Surtout quand l'explication est "return me force à retourner un typage donné", alors qu'en PHP ce n'est pas vrai: l'appelé est totalement libre de faire ce qu'il veut.

Je ne vois pas pourquoi le langage serait OO pur si tu avais pas de return.
C'est cool de pouvoir faire du chainage grâce à return $this.
En dehors de ça, un langage à souvent plus tendance à te permettre tout et n'importe quoi que t'imposer une manière très stricte de coder, je n'ai pas spécialement d'avis à ce sujet, c'est un autre débat.

Ce que j'arrive pas à assimiler, c'est surtout la notion que Client::getAgeAskedByBarman serait réutilisable, puisque c'est hyper-spécifique au couple Barman-Client. C'est objecté en fin de conférence: le foisonnement de méthodes devient énorme (et verbeux): statistiquement, il y a plus de risques d'avoir des foirages avec plus de code.

Je n'ai pas parlé de réutilisabilité moi, mais d'abstraction. Tout comme mageekguy l'a fait. On parle que d'abstraction.
De boite noire, de ne pas savoir comment marcher l'objet etc. Et encore une fois, de manière générale tu n'as pas 50 objets drastiquements différents qui fonctionnent avec un autre.

Heu, la partie du Barman qui s'instancie, je trouve que c'est un mélange avec le StateLess model.

Et tu veux en venir ou du coup ?

J'ai un doute sur les tests: si la classe testée est totalement libre, alors comment on teste $tv->userWantsToWatchTv? En fait, la notion même de test n'a pas lieu d'être si chaque agent est libre de tout (cool, c'est cela de moins à faire, mais comme en stage, on débouche sur des codes qui font n'importe quoi :\).

Le code est totalement libre, mais dans le cadre d'un test tu sais ce qu'il doit faire.
Tu l'initialise, lui donne les bonnes données etc.
Et tu sais que dans un fonctionnement normal $tv->userWantsToWatchTv($user) va appeler $user->tvIsOnChannel($channel) par exemple. Et donc ton test va consister à vérifier que $tv envoie bien le bon message à $user.

Dans l'exemple du Barman qui veut connaitre la religion du Client, en East, il faut ajouter 2 méthodes (Client::religionAskedByBarman et Barman::religionToldByClient) et éditer la méthode Barman::giveAlcool; en classique, il faut ajouter 1 méthode (s'il n'existe pas ou s'il est spécifique au Barman) Client::getReligion/Client::getReligionByBarman. C'est pas plus Opened/Closed que East?

Tu peux pour un soucis de clareté utiliser le "code de référence" qui est sur https://github.com/estvoyage/phpTour2015 et refaire ton explication à son sujet. Et montrer avec un petit bout de code ce que tu ferais à ta façon (donc non East).

Après, que l'orateur se rassure: tout code West peut être Easté (c'est facilement démontrable). Est-ce que cela en vaut le coup, franchement, au vu des résultats de mon dernier réseau de neurones, j'en doute.

Tu te bornes à comparer ça à un réseau de neurone alors que ça n'a RIEN à voir.

J'irai faire un tour sur le channel (ou on fixe rendez-vous histoire d'y être ensemble?)
J'vais aussi publier le code du stage, cela pourrait être un exemple intéressant à reprendre

J'y suis tout le temps, en général je répond sous une heure max.

[srm]

Pour moi, East n'est pas une façon d'utiliser un langage, mais une façon de faire un langage. Du coup, appliquer du East sur un langage qui n'est pas du East (= qui n'y est pas adapté, comme PHP), c'est contre-productif, et ce serait aussi mal venu de faire du East dans un langage inadapté comme PHP que de faire du West dans un langage inadapté comme Erlang.

C'est pas vraiment ça, East c'est juste la programmation orienté objet à l'origine.
Et en gros tout les langages qui ont un model objet un minimum complet s'y prête parfaitement (avec des Interfaces par exemple)
Et en quoi PHP est inadapté pour faire du East ?

La croisade du East n'est pas  faite pour changer les mentalités des codeurs PHP/Java/C etc, mais pour mettre en avant les spécificités des autres langages comme Erlang.

Pas du tout, c'est peut-être ton point de vue, mais d'aucune personne présente sur ##east.

Le meilleur exemple que je pourrai avancer, ce sont les sites web et l'architecture client-serveur: c'est du pure East (et c'est designé ainsi): le serveur génère une page HTML, l'émet à destination du client, et le client en fait ce qu'il veut. C'est intrinsèquement, dans le fonctionnement du "langage" web, du pure-East. D'où mes remarques quand certains mettent du javascript ou des notions de navigation dans le message HTML: ce n'est pas de cette façon que fonctionne le web, il faut s'y plier, et faire du East. De même, PHP/Java ou d'autres n'ont pas une façon de fonctionner "East-oriented", et il faut faire avec, et s'y plier (bien qu'on puisse lire get/set/return d'une façon qui permet de faire du East quand même).

Avec HTTP/2 ça a grave du plomb dans l'aile ton explication

[Xenos]

• L'OO-bio n'aurait pas de return $this car le message est envoyé à l'ensemble des objets (et ceux qui savent y répondre y répondent), c'est un principe que j'avais appliqué sur ce réseau neuronal. Si tu veux cibler le message à destination d'un objet, le langage OO-pur, sans return, pourrait spécifier "L'envoie d'un message se fait à destination d'un objet précis, ou par défaut, à destination du dernier objet". Ou bien, comme il n'y a pas de retour attendu, chaîner deux méthodes implique que la 2nd ignore la précédente.

Exemple:

Code :

$object.thisIsMyMessage(...);
.thisIsAnotherMessage(...); // serait envoyé à $object
// Ou
$object.thisIsMyMessage(...).thisIsAnotherMessage(...);

• Je ne suis pas d'accord: le besoin initial auquel répond l'OO, et c'est même dit dans la conférence, c'est la réutilisabilité. Le problème des vieux codes était d'avoir des éléments spécifiques à une situation, qui n'était pas réutilisables dans d'autres. L'abstraction, c'est un moyen de faire de la réutilisation, mais askWhatByWhom() est moins abstrait que askWhat ou getWhat (c'est juste une question de convention de nommage: pour moi, ces deux méthodes ont le même but: récupérer une donnée, pas accéder à un attribut). Etant moins abstraite, elle est moins réutilisable.

• Mélanger East et Stateless masquerait ce qu'est East. C'est un des soucis en dev informatique d'ailleurs: la responsabilité (qui/quoi est en charge de quoi). Mélanger East & le Stateless mélange des concepts différents et brouille les responsabilités. Mais c'est annexe, car je n'ai plus en tête ce qui était dit sur le Stateless


• Je ne suis pas d'accord pour les tests: East a l'énorme atout de permettre l'émergence de nouveaux comportements. Or, un système émergent ne peut pas être testé, car on ne peut pas en attendre quelque chose (sinon, son comportement ne serait pas émergent mais prédictible). Pour des réseaux neuronaux, de l'intelligence artificielle ou tout autre problème dans ce domaine, East est très adapté. Mais dans ces domaines, il n'y a pas de "test" possible, puisqu'on ne sait pas ce qu'on en attend (c'est le fondement de East: je te fais confiance pour faire ta part). La notion même de test n'aurait donc pas lieu d'être.

• Faudra m'expliquer comment East, qui "recopie la biologie cellulaire" n'aurait rien à voir avec du réseau neuronal...

• East n'est pas "orienté" objet: c'est de l'objet pur. La plupart des langages sont "orientés objets". J'en veux pour preuve que le langage permet de retourner ce que l'on veut, alors que East pose comme principe de ne retourner que $this: c'est un paradigme de langage.
Quelle partie de HTTP/2 plomberait mon argument?

---

Mélanger East & West dans un même code serait la pire solution, mais voici ce que je ferai en West pour que le Barman se base sur la Religion:

Code :

public function giveAlcoholToConsumer(alcohol\consumer $consumer) {
    return
        ($consumer->getAge() > $this->minAge && !in_array($consumer->getReligion(), $this->forbiddenReligions) ?
            $this->newAlcohol(): null;
}

A supposer, bien sûr, que alcohol\consumer expose une méthode getAge et getReligion, ce qui n'est pas garanti (si c'est Bender Rodriguez, le consommateur, Age & Religion n'ont peut-être pas de sens). Dans ce genre de cas, on pourrait toujours passer (vue qu'on est en PHP), par un ($consumer instanceof IHuman && <humanConditions> || $consumer instanceof IRobot && <RobotConditions>...). Cela peut d'ailleurs s'extraire dans une classe séparée (une IAlcoholGiveConditions) et/ou passer par une Chain of Resposibility si le nombre d'instanceof est important.


En fait, Early abstraction and early optimization are evil.

[niahoo]

Heu on peut arrêter avec les neurones ? On envoie un message à un objet en particulier car c'est le fonctionnement du langage qui veut ça. Pouvoir renvoyer un clone est très utile.

Pas besoin de changer la syntaxe ou autre.

Je ne suis pas d'accord pour les tests: East a l'énorme atout de permettre l'émergence de nouveaux comportements. Or, un système émergent ne peut pas être testé, car on ne peut pas en attendre quelque chose (sinon, son comportement ne serait pas émergent mais prédictible). Pour des réseaux neuronaux, de l'intelligence artificielle ou tout autre problème dans ce domaine, East est très adapté. Mais dans ces domaines, il n'y a pas de "test" possible, puisqu'on ne sait pas ce qu'on en attend (c'est le fondement de East: je te fais confiance pour faire ta part). La notion même de test n'aurait donc pas lieu d'être.

Et là c'est n'importe quoi. Excuse moi. Tu mélanges les niveaux du code et de ce que le code fait. Tu peux ne pas prévoir ce que ton code fait en fonction des différentes situations qui arrivent. Mais pour une même situation, mieux vaut que ton code se comporte de la même manière systématiquement.

Je dois de temps en temps bosser sur une appli pour laquelle ce n'est pas le cas, et c'est horrible.

[srm]

• Je ne suis pas d'accord: le besoin initial auquel répond l'OO, et c'est même dit dans la conférence, c'est la réutilisabilité. Le problème des vieux codes était d'avoir des éléments spécifiques à une situation, qui n'était pas réutilisables dans d'autres. L'abstraction, c'est un moyen de faire de la réutilisation, mais askWhatByWhom() est moins abstrait que askWhat ou getWhat (c'est juste une question de convention de nommage: pour moi, ces deux méthodes ont le même but: récupérer une donnée, pas accéder à un attribut). Etant moins abstraite, elle est moins réutilisable.

En effet je me trompe un peu. C'est moins réutilisable dans le sens ou n'importe qui ne peut pas demander mais du coup ça te permet d'être plus open/close et plus abstrait dans le sens ou tu peux répondre spécifiquement une donnée selon l'utilisateur.
Par exemple à un Barman tu pourras lui mentir sur ton âge, mais à un Policier tu vas éviter.

• Je ne suis pas d'accord pour les tests: East a l'énorme atout de permettre l'émergence de nouveaux comportements. Or, un système émergent ne peut pas être testé, car on ne peut pas en attendre quelque chose (sinon, son comportement ne serait pas émergent mais prédictible). Pour des réseaux neuronaux, de l'intelligence artificielle ou tout autre problème dans ce domaine, East est très adapté. Mais dans ces domaines, il n'y a pas de "test" possible, puisqu'on ne sait pas ce qu'on en attend (c'est le fondement de East: je te fais confiance pour faire ta part). La notion même de test n'aurait donc pas lieu d'être.

Ca permet l'émergence de nouveau comportement oui, mais dans un contexte donnée l'objet va te répondre une chose précise. On est pas dans un comportement aléatoire.
Typiquement, askAlcoohol va par exemple soit donner de l'alcool, soit ne rien faire si il en a pas, soit par exemple proposer un soda si c'est une fille. Mais dans le cadre de ton test tu auras définis le contexte et tu sauras exactement ce qu'il va envoyer comme message.

• Faudra m'expliquer comment East, qui "recopie la biologie cellulaire" n'aurait rien à voir avec du réseau neuronal...

Bah c'est simple, dans le réseau neuronal tu envoies un message et n'importe qui peut le chopper (ou en tout cas tout ceux qui peuvent comprendre ce message) enfin si j'ai bien compris, je ne connais pas les réseaux de neurones. En East tu envoies un message à quelqu'un que tu sais qu'il comprend ce message. Ce quelqu'un est très précis.

Mélanger East & West dans un même code serait la pire solution, mais voici ce que je ferai en West pour que le Barman se base sur la Religion:

Code :

public function giveAlcoholToConsumer(alcohol\consumer $consumer) {
   return
       ($consumer->getAge() > $this->minAge && !in_array($consumer->getReligion(), $this->forbiddenReligions) ?
           $this->newAlcohol(): null;
}

En fait, Early abstraction and early optimization are evil. On peut sortir ces conditions dans une nouvelle classe (un alcoholGiver) si besoin.

Bon bah je vois pas ce que tu as de mieux en West.
En East tu as une méthode de plus, mais en plus tu n'imposes pas au consumer de te donner sa religion.
Donc tu es moins dépendant du consumer.

[Xenos]

J'ai quand même du mal à assimiler un Je sais ce que je veux, et je te fais confiance pour le faire couplé à Je teste que tu as bien fait ce que je veux. J'essaierai de formuler des exemples précis de situations.

[srm]

$tv = new Tv();

$tv-setBroken(true);

$tv->userWantsToWatchYou($user)

$tv = new Tv();

$tv->userWantsToWatchYou($user)

A ton avis les codes vont faire la même chose ?
A ton avis on peut tester les deux cas ?
A ton avis est-il intéressant de tester ce code ?

Encore une fois, dans un contexte donné et précis elle doit forcément le faire, tout comme dans un autre contexte donné et précis elle enverra un autre message ou pas du tout de message.

[Xenos]

Si c'est du East, setBroken est acceptable ?!
Dans un contexte précis, la TV doit forcément faire un truc, okay. Je sais ce que je veux, et je te fais confiance pour le faire: c'est applicable aux codes de test? Si oui, alors on a un problème... Si non, okay, ça va, mais cela fait deux paradigmes en fonction du contexte (test vs fonctionnement).


Cette distinction Barman/Policier, pourquoi doit-elle être faite explicitement par un ask*ByBarman et ask*ByPolicier plutôt qu'implicitement par ask* + instanceof? J'aurai plutôt considéré que c'est à la classe appelée de faire, en interne, la distinction entre Policier et Barman, c'est à dire n'avoir qu'une seule méthode ask* et au besoin, un instanceof interne.
D'ailleurs, si le Barman est Policier, comment cela se passe en East? En West, l'appelé prendra sa décision en sachant que c'est un instanceof Policier && instanceof Barman, mais en East? Il faut un ask*ByBothBarmanAndPolicier?


J'ai quand même du mal à assimiler un Je sais ce que je veux, et je te fais confiance pour le faire couplé à Je teste que tu as bien fait ce que je veux. J'essaierai de formuler des exemples précis de situations.

En West, je n'ai touché ni à l'interface de Barman, ni à l'interface de Consumer. Je n'ai fait que modifier le code interne de la méthode giveAlgoholToConsumer. Aucune classe tierce ne sera touchée. Elles ne pourront l'être que si l'interface consumer est éditée pour ajouter getReligion (mais on peut faire sans modifier cette interface, en pur Open/Close)

En East, si j'ai compris, il aurait fallut modifier l'interface consumer pour ajouter askReligionByBarman et modifier l'interface du barman pour ajouter religionGivenByConsumer: beaucoup de classes tierces risquent d'être impactées.

[srm]

Si c'est du East, setBroken est acceptable ?!

Bah oui pourquoi ça ne le serait pas ?!

Dans un contexte précis, la TV doit forcément faire un truc, okay. Je sais ce que je veux, et je te fais confiance pour le faire: c'est applicable aux codes de test? Si oui, alors on a un problème... Si non, okay, ça va, mais cela fait deux paradigmes en fonction du contexte (test vs fonctionnement).

Les tests ça a toujours été le paradigme : je sais ce que tu dois faire et je vérifie que tu le fais
Que tu sois en POO, en fonctionnel etc.

Cette distinction Barman/Policier, pourquoi doit-elle être faite explicitement par un ask*ByBarman et ask*ByPolicier plutôt qu'implicitement par ask* + instanceof? J'aurai plutôt considéré que c'est à la classe appelée de faire, en interne, la distinction entre Policier et Barman, c'est à dire n'avoir qu'une seule méthode ask* et au besoin, un instanceof interne.
D'ailleurs, si le Barman est Policier, comment cela se passe en East? En West, l'appelé prendra sa décision en sachant que c'est un instanceof Policier && instanceof Barman, mais en East? Il faut un ask*ByBothBarmanAndPolicier?

Parce que déjà ça ne sera pas open/close
Et ça t'impose de connaître tous les types d'instances que tu vas avoir, tu es moins abstrait.
Et ça impose à ta boite noire de trop connaître le monde extérieur, savoir tous les types de classes que tu peux avoir.
Pire, prendre des décisions en fonction des type d'instance que tu vas.
Donc prendre des décisions selon un contrat, et les interfaces c'est exactement fait pour ça.
ask*ByBarman, je sais immédiatement dans quel contrat je suis, je n'ai pas à me poser 50 questions et mettre des if dans tous les sens.

SI le Barman est Policier, c'est à lui de choisir comment il se présente.
Puisque c'est lui qui va faire $user->ageAskByBarman($this) ou $user->ageAskByPolicier($this)
Et ton exemple montre bien le soucis du instanceof.
Comment tu gères ça avec un instanceof ? Bah c'est toi la boite noire ($user) qui va prendre la décision.
Alors que c'est le Barman/Policier qui doit choisir comment se présenter, en tant que Barman ou Policier.

J'ai quand même du mal à assimiler un Je sais ce que je veux, et je te fais confiance pour le faire couplé à Je teste que tu as bien fait ce que je veux. J'essaierai de formuler des exemples précis de situations.

En West, je n'ai touché ni à l'interface de Barman, ni à l'interface de Consumer. Je n'ai fait que modifier le code interne de la méthode giveAlgoholToConsumer. Aucune classe tierce ne sera touchée. Elles ne pourront l'être que si l'interface consumer est éditée pour ajouter getReligion (mais on peut faire sans modifier cette interface, en pur Open/Close)

En East, si j'ai compris, il aurait fallut modifier l'interface consumer pour ajouter askReligionByBarman et modifier l'interface du barman pour ajouter religionGivenByConsumer: beaucoup de classes tierces risquent d'être impactées.

J'espère bien que tu vas toucher l'interface Consumer en West !
Si tu ne le fais pas ça veut dire que tu vas appeler Consumer->getReligion alors que c'est défini nul part dans l'interface et tu ne sera donc même pas sur que la méthode existe ! Donc en gros ton interface ne sert plus à rien si tu t'autorise à appeler des choses qui ne sont pas définis dans l'interface.

Beaucoup plus de classes tierces impactées et encore heureux.
Je change le contrat, elles doivent s'y plier, c'est le principe même des interface, faire différement c'est comme si tu utilisais pas les interface.

[Xenos]

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

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.

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.

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