• 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:
• 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:
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.
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;
}En fait, Early abstraction and early optimization are evil.