Compass : East Oriented

[srm]

1) Verbosité

Le code devient effectivement très verbeux, ce qui compense le gain de souplesse de East (okay, c'est souple, mais bien plus complexe à maintenir).

Je ne trouve pas que ça soit plus complexe à maintenir, bien au contraire, puisque que quand tu fais évoluer ton code ou change quelque chose, tu as pas besoin de réfléchir à l'ensemble de ton application afin de savoir si tu vas casser un truc ou pas.


2) Obfuscation (c'est clairement le plus problématique à mon sens)
Beaucoup de retours ne sont non plus explicites (on n'a pas de "return"), mais implicite. Le code a l'air parallélisable, mais en réalité, il ne l'est pas car si "return" n'apparait pas, la logique du code se repose quand même dessus. Exemple: if ($this->canDrinkAlcohol === true) attends implicitement que le résultat de $this->country->canUserDrinkAlcohol($this); ait eu lieu. Idem dans canUserDrinkAlcohol.

Je ne vois pas en quoi le fait qu'il n'y a pas de return explicite (un getter en gros) ne rend pas le code parallélisable. Le système East est en gros un système de message, que l'on peut assimiler au système d'Acteur qui est justement très apprécié quand on veut faire de la parallélisation.


3) Plus de méthodes publiques
Le code passe de deux méthodes publiques (void User::drinkAlcohol() et bool Country::getMajority()) à 7 méthodes publiques. Je pense que le risque de cassure de contrat ("Si country change son type de retour pour la méthode getMajority, mon code est cassé.") est alors bien plus important.


Oui mais contrôlé, il n'y a pas de mal à faire évoluer ton contrat et à y ajouter des choses, ce qui est plus mal c'est modifier des choses déjà existantes.


4) Lourdeur des classes
D'instinct, vu qu'il faut ajouter des méthodes quand on ajoute des conditions (void User:exAskedByCountry(Country)), le code ne sera pas d'une excellente extensibilité (il faudra les créer et altérer l'endroit où on les appelle; avant on altérait seulement la condition if); mais cela peut probablement se régler par des patterns type "liste de trucs à appeler dans canUserDrinkAlcohol").


Bah on revient au cas 1 pour moi, ça permet justement de se concentrer sur l'objet de façon unique sans te préoccuper du monde extérieur qui l'utilise, c'est plus facile à modifier et par conséquent à étendre.


5) Combinatoire
Au vu des noms de méthodes de User (sexAskedByCountry(Country), oldAskedByCountry(User)), on se prive de la combinatoire (le truc qui fait qu'avec 5 objets, on a 20 combinaisons différentes possibles) de l'orienté objet, ce qui va certainement entrainer beaucoup de réécriture de code: combien de méthodes faut-il ajouter si la possibilité de boire de l'alcool est également influencée par les fédérations (genre Country=France, Federation=Europe), par les maladies éventuelles du User, ou par la qualité des boissons de cette année?

Il faudrait en ajouter autant que nécessaire en effet, mais si tu fais pas du East tu vas ajouter autant de getter que nécessaire, c'est la même chose non ?

[srm]

Je considère plutôt les getters comme des moyens d'interroger l'objet sur une donnée. L'objet répond par une donnée (ou par un autre objet), qui peut tout à fait venir des propriétés internes de la classe, d'une base de données, d'une propriété statique, ou d'une valeur aléatoire.

Oui mais tu couples bien plus tes objets, puisque si tu fais $user->getSomething() tu imposes à l'objet user de te retourner quelque chose. Si tu fais $user->askSomethingByCountry($country) tu laisses la liberté à l'objet user de faire ce qu'il veut.
De ne rien répondre, ou de répondre tout à fait autre chose à country.
Un objet étant censé être une boite noire, tu ne sais pas ce qu'il s'y passe dedans, tu ne peut pas lui demander une valeur puisque son fonctionnement interne t'es inconnu et il peut très bien s'en moquer de ce que tu lui demande.

Concernant ton exemple de code, si askMajority a un soucis et que le fichier n'existe pas, je suppose que tu vas lever une exception non ? Ca veut dire que UserDrinkAllower doit savoir que Country lève une exception, ça veut dire que UserDrinkAllower sait comment marche Country, alors qu'il ne le doit pas le savoir c'est une boite noire. Si tu changes le format de l'exception de Country pour une raison ou une autre, tu vas devoir t'assurer de ne pas casser le code existant qui catch cette exception. Du coup quand tu modifies le fonctionnement interne de Country tu dois t'assurer qu'il continue de marcher avec le monde extérieur et c'est là que l'on voit qu'il y a un couplage fort et que ça rend le code difficile à maintenir et faire évoluer.

[srm]

6) Les dépendances circulaires

East me semble créer énormément de dépendances circulaires. Par exemple, "User" a besoin de "Country" en OO classique, et c'est tout, d'où un schéma de dépendances User → Country. En East, User a besoin de Country qui a besoin de User (pour lui renvoyer des infos): on a une dépendance circulaire.
Autant en PHP, on s'en cogne, mais dans d'autres langages (au hasard donc, le C/C++), il y a de quoi s'arracher les cheveux.

Faut pas le voir comme ça
User sait envoyer des messages à Country
Country sait envoyer des messages à User

C'est pas la même chose, dans le cas ou tu as des getter tu as une dépendance forte oui car tu as forcément un retour d'information. Quand tu envoies un message tu as pas forcément un retour d'information.

[srm]

La conf du PHP Tour : http://estvoyage.github.io/phpTour2015/

[Xenos]

Non, si le fichier n'est pas accessible, je ne renvoie pas une exception: celle-ci n'est pas dans la signature publique de la méthode.
Ce qui rend les codes OO impossible à maintenir, ce sont les changements de signature des méthodes (lorsqu'ils sont anarchiques).
Java est bien fichu de ce coté-là (PHP est beaucoup trop souple et permissif pour de l'OO propre): si on veut lever une exception, on doit changer la signature de la méthode. Si on change cette signature, on casse des trucs.

Du coup, ma signature n'ayant pas de throws (PHP rattrape le coup avec des commentaires type @throws), je ne peux pas retourner d'exception: uniquement un (int). En cas d'erreur dans le fichier, je retourne un âge qu'il me faut fixer (ben oui, là, j'ai fait de la merde: j'aurai du utiliser un typage de retour différent des typages de base, comme une struct Age par exemple, qui m'aurait permis de gérer des âges du genre NaN; d'ailleurs, je peux toujours utilises l'int NaN en cas d'erreur: je ne casse pas la signature de la méthode).
Si je veut insérer la gestion par exception, il me faut une nouvelle méthode, qui dépréciera l'ancienne:

/**

* @deprecated askMajorityWithException

*/

	public function askMajority() {

		try {

			return $this->askMajorityWithException();

		}

		catch (FileException ex) {

			// Log it if you want

			return Country:: ON_ERROR_DEFAULT_MAJORITY;

		}

	}

/**

* @throw FileException

*/

	public function askMajorityWithException() {

		return (int)file_get_contents("country.majority.txt");

		// let's say file_get_contents throws FileException if file's not found

	}

User sait envoyer des messages à Country
Country sait envoyer des messages à User

C'est pas la même chose, dans le cas ou tu as des getter tu as une dépendance forte oui car tu as forcément un retour d'information. Quand tu envoies un message tu as pas forcément un retour d'information.

Essaie en C++, et tu verras que la dépendance circulaire va vite te les casser (okay, tu peux passer par des forward declarations dans le .hpp mais à force d'inclure des .hpp dans tous les .cpp, la moindre modification de signature d'une classe recompilera le projet entier; ce genre de soucis, j'en sors puisque cette semaine, j'étais à la coupe de France de robotique >.< ).

Et oui, je suis d'accord: c'est pour cela que les langages OO ont des signatures de méthodes publiques.
Finalement, j'ai plutôt l'impression que East, c'est seulement un doux nom pour tenter de porter les langages évènementiels vers les langages OO (qui n'y sont pas adaptés). Parce que là, du coup, kestananafout des signatures de méthodes finalement? Ranapété.


J'en revient au point capital de la combinatoire. Au vue de tes noms de méthodes (UserAskedByCountry par exemple), le pattern générique des noms va ressembler à #AskedBy*. Du coup, supposons que l'on ait 5 requêtes possibles (5 valeurs de #) que peuvent demander 5 classes différents (5 valeurs de *), on va se retrouver avec 25 méthode (et on aura surement cela pour chaque classe...).
Sans East, on a 5 requêtes possibles (5 getters), qui peuvent alors être demandés par une infinité de classes.
J'ai donc du mal à voir comment la réutilisation de code peut se faire proprement quand les méthodes se nomment "MachinAskedBy[ClassName]" au lieu de "getMachin" (sachant que ce get renvoie un truc qui n'est pas forcément un attribut; et si tel est le cas, il ne devrait être renvoyé que par copie, tout comme l'ADN qui ne sort jamais du noyau d'une cellule).


J'attends de voir un projet industriel réalisé en East, et maintenable sur le long terme, car au fond, sans le formaliser, j'en avais fait en stage de dernière année (sous la forme d'un réseau neuronal où chaque noeud est un objet, qui reçoit une copie de tous les messages des autres,le traite ou non et renvoie ou non un message à tous les autres)... Eh bien avec ce genre d'approche, le "je sais ce que je veux et je te fais confiance pour le faire" est vite devenu un "je sais ce que je veux mais mon truc fais n'importe quoi".

[srm]

Ça n'empêche que pour l'exception du coup c'est ton objet A qui doit s'adapter à l'objet B mais bon pourquoi pas.
Il n'y a pas de dépendance circulaire car A utilise B mais ne stock aucune référence vers celui-ci.

East c'est surtout la POO comme elle a été pensé à l'origine tu devrais lire le lien de la conf que j'ai donné. On invente rien, on rappel ce que c'est la POO à l'origine et pourquoi c'est super intéressant.

Il faut déjà qu'il y ai 5 objects différents qui ont besoin de 5 valeurs de A, c'est qui souvent sera du à une mauvaise conception.
Pour UserAskedByCountry est un getter c'est la même chose que getUser, alors que non pas du tout.
L'avantage du message c'est que tu peux répondre autre chose que ce qui est demandé, tu as la souplesse de faire ce que tu veux.

Le mieux c'est de tester avant de critiquer :p

[Xenos]

sans le formaliser, j'en avais fait en stage de dernière année (sous la forme d'un réseau neuronal où chaque noeud est un objet, qui reçoit une copie de tous les messages des autres,le traite ou non et renvoie ou non un message à tous les autres)... Eh bien avec ce genre d'approche, le "je sais ce que je veux et je te fais confiance pour le faire" est vite devenu un "je sais ce que je veux mais mon truc fais n'importe quoi".

:roll:

C'était du pure-East (sans forcément avoir mis un nom dessus).

Je maintiens (mais t'as peut-être pas fais de C++ pour le voir?) que si tu utilises A dans B, tu te trouves obligé d'au moins déclarer que A est une classe (forward declaration) avant de déclarer B (et inversement).
C'est pas la mort, mais cela rajoutes du code.

Ce qui pose soucis, c'est que chaque objet ayant une demande à faire à une classe doit (au vu du UserAskedByMachin) implique de créer une nouvelle méthode... Ou alors, de passer par une interface (Machin), que chaque demandeur doit implémenter. C'est jouable, mais cela m'a l'air de juste transferer la signature de chaque méthode dans une interface dédiée.

C'est peut-être un rappel de la POO à l'origine, mais je trouve surtout que c'est "sur-fait" car le problème est plus dans l'interprétation d'un appel de méthode ("le getter renvoie la valeur de mon attribut") que dans son utilisation ("le getter me renvoie l'âge de l'utilisateur, 'm'en fous d'où il sort: c'est ce que je veux, son âge").


Pour faire de l'OO pur sans se briser les doigts, il suffit finalement de lire les
Class::appelant { $chose = $object->methodName($parameters) }
comme
l'envoie d'un message à $object composé de l'émetteur, la méthode, les paramètres, le conteneur de résultat: {$appelant, methodName, $parameters...} puis l'arrêt de l'exécution de l'appelant, après avoir sauvé son état courant
et
Class::methodName { return $result; }
comme
Je traite le message {$appelant, methodName, $parameters...} et une fois terminé, j'envoie un message spécial au $appelant, type {$object, null, $result}. Quand $appelant reçoit ce message, il se remet dans l'état qu'il avait sauvé et récupère $result..

Perso, cela me parait bien moins prise de tête...
C'est d'ailleurs ce que l'ordinateur fait (il me semble). Bref, je n'adhère pas (que ce soit du Alan Kay ou non), car cela émule ce que la machine fait déjà intrinsèquement. Mieux vaut se contenter de bien respecter les signatures des méthodes et de ne pas les casser lors des évolutions.

[srm]

Tant pis tu ne veux pas essayer

[srm]

C'est toujours pareil de toute façon, si tu fais un getter, tu consisdères que l'objet sur lequel tu get n'a pas son mot à dire et qu'il ne peut que te retourner la valeur que tu lui demande. Et tu considères que tu sais mieux que lui qu'il peut te donner la valeur que tu demandes car tu lui impose de te la donner.

Et c'est là le drame, car tout ce postula est forcément faux.

Si tu ne vois pas pourquoi je t'invite à lire https://thesecretsquad.wordpress.com/201...onfuzzled/
Qui l'explique très bien

[srm]

Et je t'invite aussi à lire ça : https://www.reussitepersonnelle.com/zone-confort/
C'est instructif