Pourquoi Thread n’est pas une classe abstraite et que start () n’est pas final?

Pourquoi la classe Thread t-elle été implémentée en tant que classe régulière et non en tant que classe abstraite avec la méthode run() abstraite?

Cela va-t-il introduire des problèmes? Ou est-ce que ça sert à ça?

De plus, la méthode Thread.start() est supposée être une méthode très spécifique dont la fonctionnalité ne peut être implémentée par aucune autre classe (si je ne me trompe pas). Et par conséquent, je suppose que le mot clé final serait plus approprié que toute autre méthode.

Mais je suis capable de passer outre cette méthode et de l’utiliser comme je veux,

 public class Test extends Thread { public static void main (Ssortingng... args) { Thread test = new Test(); test.start(); } @Override public void run() { System.out.println("New thread started..."); } @Override public void start() { System.out.println("Did anyone tell you I will spawn a new thread??"); } } 

Il a évidemment seulement imprimé,

Quelqu’un vous a-t-il dit que je lancerais un nouveau sujet?

Y a-t-il une autre utilisation que de dérouter l’ingénieur qui vous remplace?

Sinon, pourquoi la méthode n’a-t-elle pas été déclarée finale dans la classe Thread?

Pourquoi la classe Thread a-t-elle été implémentée en tant que classe régulière et non en tant que classe abstraite avec la méthode run () abstraite?

Cette question se résume au fait que vous devriez toujours préférer la composition à l’inheritance.

Si la classe Thread était déclarée comme abstract , le langage devrait fournir une autre classe étendue à partir de laquelle les programmeurs pourraient utiliser pour créer un Thread . Votre question serait alors de savoir pourquoi cette classe qui extends de Thread n’est pas abstract . Si le langage ne fournissait pas une autre classe qui extends de Thread , les programmeurs devraient créer leur propre classe qui extend s à partir de Thread et substituer la méthode run() .

Sinon, pourquoi la méthode n’a-t-elle pas été déclarée finale dans la classe Thread?

La seule explication possible que je puisse donner est que les développeurs du langage ont vu des cas d’utilisation pour start à start lorsque la classe a été introduite dans le JDK. La première version de Java que j’ai utilisée était la version 1.5 et je n’ai personnellement pas rencontré de cas d’utilisation pour lequel il était nécessaire de remplacer le start . Comme l’a déclaré JB Nizet dans sa réponse

Si Java a été repensé à partir de zéro, il y a de fortes chances que la conception soit différente

Vous pouvez bien sûr choisir de vous tirer dans le pied, mais cela ne signifie pas que vous devez le faire.

Pourquoi la classe Thread a-t-elle été implémentée en tant que classe régulière et non en tant que classe abstraite avec la méthode run () abstraite?

Parce que la méthode recommandée pour créer un thread ne consiste pas à sous-classer Thread. La méthode recommandée est de définir un Runnable et de le passer en argument au constructeur Thread:

 Runnable r = new Runnable() { @Override public void run() { ... } }; Thread t = new Thread(r); t.start(); 

Et par conséquent, je suppose que le mot clé final serait plus approprié que toute autre méthode.

Oui et non. Vous ne pouvez pas remplacer l’implémentation de start () par votre propre implémentation, mais vous pouvez faire d’ autres choses dans start () si vous le souhaitez:

 @Override public void start() { System.out.println("Did anyone tell you I will spawn a new thread??"); super.start(); } 

Cela dit, si Java a été redessiné à partir de zéro, il y a de fortes chances que la conception soit différente. Rappelez-vous que cette classe date de Java 1.0 et qu’elle est toujours compatible avec les versions antérieures.

Pourquoi Thread.start() n’est pas final ?

Êtes-vous sûr de ne jamais vouloir le remplacer?

 Class MyThreadFactory implements ThreadFactory { @Override public Thread newThread(Runnable r) { return new Thread(r) { @Override public void start() { LOGGER.info("Starting thread " + this); super.start(); } }; } } 

Je pense que quelques calirifcations doivent être affichées pour les réponses:

“Êtes-vous sûr de ne jamais vouloir passer outre?”

Non ! Je ne voudrais pas. C’est comme dire: “Etes-vous sûr de vouloir déclarer cette variable privée?” Parce que si je pouvais déclarer n’importe quelle variable que j’utilise en public sans craindre que d’autres développeurs ne gâchent ma logique de conception, le codage serait un jeu d’enfant. L’un des objectives les plus importants des concepts OOPS de Scope, d’abstraction, de polymorphism, de gestion des erreurs, etc. est de communiquer aux autres développeurs la conception et les intentions de votre code. utiliser super.start (). @Codebender a écrit une méthode de démarrage pour un thread sans utiliser super.start () et le compilateur ne s’est jamais plaint. Donc, il est libre de casser tout le mécanisme de Threading et le compilateur est supposé le laisser passer? La méthode de démarrage des threads garantit que la méthode d’exécution est appelée et exécutée au bon moment! C’est essentiel au concept même de filetage. Je serais plus qu’heureux d’être corrigé, si j’ai raté quelque chose ici. 2.

Parce que la méthode recommandée pour créer un thread ne consiste pas à sous-classer Thread.

OK, si designbender est autorisé par la conception, à sous-traiter Thread et gâcher la méthode de démarrage, par cette logique, c’est la conception elle-même qui se déroule dans le pied. Par une autre déclaration faite (que je suis complètement d’accord), Runnable est la méthode recommandée. Alors pourquoi permet-on à la classe Thread d’instancier le thread sans aucune ressortingction? Ceci est suivi par:

Vous ne pouvez pas remplacer l’implémentation de start () par votre propre implémentation,

Cela prend en charge l’affirmation de codebender selon laquelle la méthode de démarrage devrait être définitive lorsque vous dites cela .. ^

Le seul point, qui est valable, est déjà mentionné en tant que note latérale, mais est la réponse réelle à cette question.

“Rétrocompatibilité”.

En fait, les améliorations se produisaient même jusqu’à JDK 5.0, lorsqu’elles incorporaient de nombreux ajouts et clarifications au modèle de concurrence Java. Nous voulons que la compatibilité ascendante soit supscope tout le temps et que la classe Thread soit toujours exactement comme avant, même si l’interface Runnable est la méthode recommandée de nos jours.

Encore une fois, je serais plus qu’heureux d’être corrigé, si j’ai raté quelque chose.