Bien implémeter les threads

Bonjour,
je me lance dans les threads et j'ai donc bouquiné un peu et j'ai lu 2 trucs completement opposés.

- Un cours sur Internet disait que la plus simple manière de créer un Thread est de dériver la classe Thread pour faire une classe fille de Thread et y mettre tout ce que doit faire le thread.

- dans un bouquin, je lis que c'est souvent la plus mauvaise méthode et qu'il convient plutot de faire gérer les Threads par la classe en ayant besoin...

du coup je ne sais pas trop a quel saint me vouer ... Personnellement je pencherai plus pour la premiere solution, qui me semble plus orientée objet. Mais je peut me tromper.

Bon la question peut paraitre plus philosophique aue pratique, mais tant quìa faire autant apprendre a faire les trucs proprement :P

merci pour vos réponses

kerinel

Bonjour, je vais te donner mon avis sur la question et cela n'engage que moi.

Il est vrai que dériver de la classe Thread est une façon simple de faire un Thread (quand à savoir si c'est la plus simple, c'est assez philosophique : dériver, implémenter, agréger, qu'est ce qui est le plus simple ???)
Je pense que cela peut se justifier au niveau conception objet si la classe dérivée est un objet technique qui représente bien une sorte de processus légér. Tu pourrais par exemple trouver pratique d'avoir une implémentation enrichie d'un Thread.

Ceci étant dit, je pense que dans le cas d'une application "métier", les objets créés sont plus en rapport avec le domaine métier. Dès lors, je ne pense pas que dériver de Thread soit bon conceptuellement. Mieux vaut au sein de la classe qui veut executer des traitements non bloquant, créer à ce moment là un Thread (classe anonyme généralement) qui executera le code.
Si tu as des objets métiers qui représentent des traitements, tu peux aussi faire en sorte qu'ils implémentent l'interface Runnable. Cela peut alors te permettre de généraliser comme te l'aurai permis une dérivation de Thread.

Pour conclure, je dirai que l'héritage est quelque chose de formidable. Il est probablement le paradigme de la POO qui est le plus vite compris. A tel point que le gros défaut des débutants est alors de vouloir l'utiliser pour tout et n'importe quoi. Je pense qu'il faut l'utiliser lorsque qu'on souhaite à la fois une relation "est un" et une factorisation de code. Dans les autres relations "est un", les interfaces sont plus appropriées.

Je suis du même avis que Benwit.
Car implémenter Runnable rend la classe plus flexible:
- elle peut toujours hériter d'une autre classe
- elle peut lancer elle même son code dans un thread séparé: new Thread(this).start();
- on peut déléguer le choix de l'exécution du code Runnable à une autre classe qui pourra faire laClasse.run() pour être synchrone ou bien new Thread(laClasse).start(); pour être asynchrone

Donc faire un "clignoteur" juste pour faire clignoter mes Digits, c'est pas une bonne idée. Il faut plutot que je fasse une methode clignoter, que j'implemente Runnable avec
public void run() [ clignoter();]
(desole je trouve pas les accolades sur ce clavier :? )
et que quand j'ai besoin de faire clignoter je fasse
new Thread(this).start();

Mais si du coup je veux pouvoir faire un second Thread dessus qui lui me permet de faire defiler du texte.
si je n'ai pas la fonction clignoter, je peux faire pareil avec une methode defiler et
public void run()[defiler();]

Masi comment faire pour faire cohabiter les deux, schant que je peux vouloir faire clignoter sans faire defiler, faire defiler sans faire clignoter, ou faire les deux ensemble...

Du coup je suis bien obligé de définir un objet supplémentaire ? Ou alors je dois utiliser une classe anonyme ? Mais du coup quel est l'avantage par rapport a le derivation d'objet ? Car mon objet est plus facilement controlable que la classe anonyme non ?

merci
kerinel

Tu fais une classe qui sait faire Clignoter
Tu fais une classe qui sait faire Défiler
Tu fais une classe TextAnimator qui contient l'un ou l'autre ou les deux pour animer ton texte.
Cette classe pourra démarrer et arrêter chacunes de ces classes (qui pourraient dérivées d'une même interface TextAnimation qui a startAnimation() et stopAnimation() par exemple
Comme ça tu peux prévoir d'autres effets comme un changement de couleur ou de police par exemple

Ps: si tu fais du Swing pense à bien synchroniser tes updates de texte via SwingUtilities

Donc pour l'instant mon code ressemble à ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66

public class DigitBox{   private Clignoteur cligne; private boolean çaNeClignotePas;     public DigitBox() {   je fais la Digit Box qui regroupe les Digits etc...   çaNeClignotePas=true;   }//fin DigitBox     public void clignoter(){   if(çaNeClignotePas){ çaNeClignotePas=false; cligne = new Clignoteur(); cligne.start();   } else{ cligne.arret(); çaNeClignotePas=true; }   }//fin clignoter     }//fin de class DigitBox         class Clignoteur extends Thread{   private boolean tantQuOnVeutClignoter   public clignoteur(){   creation du clignoteur...   tantQuOnVeutClignoter=true;   }//fin Clignoteur   public void run(){   while(tantQuOnVeutClignoter){ instruction pour clignoter }   }//fin de run()     public void arret(){   tantQuOnVeutClignoter=false;   }//fin arret   }//fin de class Clignoteur

---

j'ai la meme chose pour faire defiler, avec un Defileur , une methode faireDefiler...

Il me suffit de remplacer:

class Clignoteur extend Thread
par
class Clignoteur implement Runnable


private Clignoteur cligne;
par
private Thread cligne;

et
cligne = new Clignoteur();
cligne.start();
par
cligne = new Thread(new Clignoteur());
cligne.start;

pour etre bon ?
Du coup je ne vois pas trop la différence....

merci pour votre aide.
kerinel

En effet la différence n'est pas énorme mais ce principe est comme je l'ai dit plus haut est, je pense, plus souple.

De plus le fait de faire comme cela peut permettre de gérer plus finement l'exécution du code dans un thread séparé.
Tu peux choisir un thread parmis un pool par exemple pour exécuter ton Runnable
Chose que tu ne pourrais pas faire si tu héritais de Thread car ce sera forcément ce Thread qui exécutera le code (bon tu pourrais toujours toujours passer ta classe qui hérite de Thread à une autre classe Thread car Thread implement Runnable; mais là c'est pas tip top)

Le mieux si c'est pour du graphique, c'est d'utiliser javax.swing.Timer.

OK, donc c'est purement conceptuel en fait. Mais effectivement cela parait plus souple.
Peut etre serait-il-plus judicieux de faire gérer le Thread par le Clignoteur?
avec un truc comme ceci

Dans la classe Clignoteur :

Code:

---

1 2 3 4 5

public void clignoter() { Thread monThread = new Thread(this); monThread.start(); }

---

Et dans mon DigitBox:

Code:

---

1 2 3 4 5 6 7

Clignoteur toto = new Clignoteur() toto.clignoter();   plus loin   tot.stop()

---

Le Timer ? Kesaco ? je vais regarder ça ...

Je commence à mieux cerner tout ça en tout cas. Merci beaucoup pour votre aide.

Citation:

---

Envoyé par kerinel

OK, donc c'est purement conceptuel en fait. Mais effectivement cela parait plus souple.
Peut etre serait-il-plus judicieux de faire gérer le Thread par le Clignoteur?
avec un truc comme ceci

Dans la classe Clignoteur :

Code:

---

1 2 3 4 5

public void clignoter() { Thread monThread = new Thread(this); monThread.start(); }

---

Et dans mon DigitBox:

Code:

---

1 2 3 4 5 6 7

Clignoteur toto = new Clignoteur() toto.clignoter();   plus loin   tot.stop()

---

Le Timer ? Kesaco ? je vais regarder ça ...

Je commence à mieux cerner tout ça en tout cas. Merci beaucoup pour votre aide.

---

Si toto est un élément graphique, ça n'est pas correct car il faut faire .clignoter() dans l'edt (avec SwingUtilities.invokeLater(...)).