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