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).
• Les cellules sont des organismes travaillant en parallèle, et non en série: on ne peut pas faire de l'OO pur sur un seul thread
• 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.
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.
Heu, la partie du Barman qui s'instancie, je trouve que c'est un mélange avec le StateLess model.
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 :\).
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?
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.
Bonne conférence quand même
(quoique le "si on avait l'héritage multiple on s'emmerderait pas", je suis pas d'accord, puisque extends/implements n'ont pas le même but)
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
• 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).
• Les cellules sont des organismes travaillant en parallèle, et non en série: on ne peut pas faire de l'OO pur sur un seul thread
• 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.
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.
Heu, la partie du Barman qui s'instancie, je trouve que c'est un mélange avec le StateLess model.
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 :\).
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?
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.
Bonne conférence quand même
(quoique le "si on avait l'héritage multiple on s'emmerderait pas", je suis pas d'accord, puisque extends/implements n'ont pas le même but)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