(24-04-2015, 11:09 AM)Xenos a écrit : 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 ?

(24-04-2015, 11:09 AM)Xenos a écrit : 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.

(25-04-2015, 02:11 PM)Xenos a écrit : 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.

/**

* @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

	}

Citation :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.

Citation :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".