Alors voila le problème : j'ai une classe Buffer ; en fait c'est pas vraiment un buffer mais bon. Quand on y ajoute un objet, celui-ci subit un traitement effectué par un autre objet implémentant une interface Worker.
J'ai un type de Worker qui effectue son traitement de manière asynchrone : il hérite de Thread, et quand on lui passe un objet, il est ajouté à une file d'attente.
Donc la chose se fait comme ça :

 
Mon problème est donc : comment arrêter proprement mon Thread ?
Le moyen qui m'a sauté au visage était d'appeler stop() dans le finalize() de mon Buffer. Mais ca me fait utiliser à la fois finalize() et instanceof, deux trucs sales que j'aime pas.
Il doit y avoir plus propre mais je ne vois pas, sachant que ca va pas être trop facile de garder une référence sur le worker ailleurs que dans buffer. Une idée ?

Pourquoi as tu un Buffer de Worker ?
Ton worker devrait excuter son traitement tout en ayant une fonction ajouterTraitement qui placerait donc ton nouveau traitement à la queue des traitements devant êtres executés par ton Worker.

 
Rapport en entre truc et Worker ?
Ne mélanges tu pas les serviettes et les torchons.

Je pense que ta la méthode run de ton Worker doit avoir une boucle infinie alors ajoute une methode arret() qui positionnera un flag à vrai par exemple et ainsi à chaque tour de boucle tu verifiera la valeur de ce flag pour savoir si tu lances le prochain traitement ou si tu sors de ta méthode run.
 
Dans le cas du multithreading la méthode finalize() n'est pas "sale". Imaginons que tes traitement sont des manipulations dans des bases de données donc les connexions serons assuré par un pool, la méthode finalize te permet d'etre sur de liberer tes ressources proprement .

mon avis sur la question :  
 
ton AsynchWorker est créé en dehors du buffer. C'est un objet inédpendant du buffer. Il n'y a donc pas de raison que ce soit le buffer qui arrête le Thread. D'ailleur tu as bien vu le problème : il n'y a aucune raison qeu le Buffer puisse arrêter le thread puisque qu'il n'est pas sensé savoir si un worker est threadé ou non. C'est ce qui t'oblige à faire le instance of, ce qui effectivement dans ce cas est crade.
 
donc je vois 2 solutions :  
 1) tu arrêtes le thread en dehors du Buufer, mais je ne connais pas assez ton prog pour savoir si c'est possible/facile
 2) tu ajoutes une gestion de cycle de vie à tes workers en ajoutant une methode startWork() et une methode stopWork() à l'interface Worker. Le problème c'est que ca t'oblige à modifier les classes implémentant Worker  déjà écrite ...
 

  utiliser finalize habituellement c'est une mauvaise idée. Tu n'as aucune garantie que la méthode sera appelée...
 
finalize peut être utilisée "par sécurité" mais il doit toujours exister un moyen de "fermer" un objet qui le nécessite de façon manuelle !

avec eclipse ou n'importe quel outil de refactoring, tu modifies l'interface ca t'ajoute les methodes dans toutes les classes qui l'implémentent.

oauis mais t'as pas toujours accès ou le droit de modifier ces classes ...  
 

On est bien d'accord.
Effectivement je pensais que la meilleure méthode est d'arrêter le thread en dehors du buffer. Le problème est que ca m'oblige à garder une référence sur le worker, et il me faudrait un objet exprès pour ça, car il peut y avoir plusieurs buffer donc plusieurs worker.
Ou alors que je demande au buffer son worker pour l'arrêter avant quand je n'ai plus besoin du buffer... Ca revient un peu au même que les methodes start et stop dans le worker...
Le problème c'est q le faitque le worker soit threadé ou non dépend des préférences de l'utilisateur, et j'aurais aimé ne pas avoir besoin de cette info trop souvent. Donc effectivement je crois que je vais modifier l'interface.

si tu peux te le permettre, la modification de l'interface est la meilleur méthode à mon avis ...
 
dans le cas où le worker n'est pas threadé, les méthode start et et stop ne feront rien ... c'est pas grave ...

Design pattern Expert : c'est celui qui a l'info qui bosse.
pattern forte cohésion : on ne diffuse pas l'information plus que nécessaire.
 
(les 2 sont de "UML et les Design pattern", C. Larman si je me plante pas)