Citation:
Envoyé par
thelvin
C'est ce que j'ai dit, là à la compilation ça ne va pas être possible.
Ok.
Citation:
Mais les génériques ne limitent pas leur utilité à la compilation, c'est juste l'utilisation la plus simple.
Ils servent à s'assurer qu'on est strictement typé, et à échouer le plus tôt possible quand le typage n'est pas assuré.
Échouer à la compilation quand le typage n'est pas respecté, c'est l'idéal. Mais pas toujours possible. Ce n'est pas une raison pour se résigner à ce que les erreurs de typage arrivent à des endroits complètement imprédictibles parce qu'on pensait traiter une List de Employer pendant tout un process mais c'est seulement cinq couches plus tard qu'on fait vraiment de la réification et BAM en fait d'Employer on a un Salaryman et ClassCastException.
Dans ce cas-là, ce qu'on veut, c'est échouer au moment où on croyait récupérer une List d'Employer mais il se trouve que c'est autre chose qu'on a à nous donner. Le non-respect du typage arrive là, donc c'est là qu'on veut une erreur. Pas plus tard, à un endroit où on croyait qu'on avait déjà notre Liste d'Employer.
J'admets.
Citation:
Vu ce que tu décris, ce que je proposais faisait de la détection d'erreur plus tôt qu'il n'est possible. Très bien, alors ne détectons pas aussi tôt, mais aussi tôt que possible.
Quand tu appelles ton getSector(sectorName), tu sais que tu en veux un qui va donner des Employer quand tu fais selectAll().
Tout à fait d'accord.
Citation:
Donc tu devrais faire un getEmployerSector(sectorName) à la place, qui renvoie un Sector<Employer> qui va te faire ça.
Là, ça me paraît beaucoup plus difficile.
On a un objet de type Simulation qui contient la liste de tous les secteurs (en fait, une HashMap<String,Sector>).
Sector n'est qu'une interface, certains secteurs concrets pouvant être d'un type multi-agents, comme "firms" et "workers", d'autres pouvant être d'un type agrégé, le secteur représentant alors un seul acteur (un marché, l'Etat, la banque centrale, le reste du monde...).
Lorsque le secteur des travailleurs est initialisé, chaque travailleur nouvellement créé reçoit, dans le doc XML qu'il a reçu en argument, le nom du secteur des employeurs (ici, "firms").
A ce moment (si l'utilisateur a décrit les secteurs dans le bon ordre dans le fichier XML décrivant son modèle) le secteur des employeurs doit déjà être initialisé.
Donc, en suivant ce que tu dis, c'est le moment de détecter si le secteur désigné est capable ou non de renvoyer une List<Employer>.
Tout ce que peut faire le travailleur, c'est s'adresser à la simulation pour lui demander de lui renvoyer le secteur qui porte le nom "firms".
Tout ce que peut faire la simulation, c'est renvoyer le secteur qu'elle trouve dans HashMap à ce nom et qui, pour elle, est de type Sector sans autre précision.
Donc il ne peut y avoir, au niveau de la simulation, de méthode getEmployerSector(sectorName).
C'est à chaque travailleur de vérifier si le secteur qu'on lui désigne comme employeur en est effectivement un, c'est-à-dire qu'il renvoie une List<Employer> quand on lui demande la liste de ses agents.
Si je veux te suivre, il faut alors que getEmployerSector(sectorName) soit une méthode de Worker.
Citation:
Reste à faire en sorte que getEmployerSector(sectorName) vérifie que le Sector renvoyé est bien un Sector<Employer>. Le Sector, lorsqu'il a fini de lire sa conf', il sait quelle classe il fournit. Il peut donc garder cette information en interne dans une variable Class<E> agentClass.
Jusqu'à présent je stockais cette information ainsi (dans l'objet BasicSector, implémentation multi-agent de l'interface Sector) :
Code:
1
2
3
4
| /**
* The class of the agents that populate the sector.
*/
final private Class<? extends Agent> agentClass; |
Citation:
Du coup quand tu appelles getEmployerSector(sectorName) dans le but d'avoir ce Sector, la classe Simulation peut le trouver grâce à son sectorName, mais elle ne sait pas s'il fournit bien des Employer. Mais puisque lui le sait, elle peut tout simplement lui demander si c'est le cas. Et sinon, lancer une Exception qui indique que tu as demandé le Sector sectorName pour te fournir des Employer, mais il se trouve que le Sector de ce nom-là ne fournit pas cela.
Donc, dès que le travailleur connait le nom du secteur employeur :
- il demande à la simulation ce secteur,
- il demande au secteur quel est le type d'agent qui le peuple (je rajoute à l'interface Sector une méthode getAgentType()),
- si le type retourné est incompatible avec Employer on lance une exception.
Ainsi, comme tu dis, l'erreur est déclenchée le plus tôt possible, à l'initialisation du Worker, et non plus tard lorsque le travailleur commence le job search.
Mais, quand bien même le secteur "firms" passe correctement ce chek, je vais rester avec le même warning au niveau du job search, quand le travailleur va demander au secteur "firms" de lui renvoyer la liste de ses agents et qu'il va vouloir la convertir en une liste d'employeurs.
