Compass : East Oriented

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