Extends Thread & Runnable

[Srinivasa Raghavan]

In the Previous post made by Steven Bell, there was a line " Third you should not extend Thread rather you should implement Runnable and use a Thread to run your Runnables".?

Why ? what advantages you get by implementing a runnable interface rather than extending a thread ?
[ January 10, 2005: Message edited by: srini vasan ]

[Vijayendra V Rao]

  
public class Circle extends Thread{
  
  //Class Constructor
  public Circle()
  {
    //some initialisations
  }
 
  public void run()
  {
    //Thread code here..
  }
}

After sometime you suddenly realise that your class Circle needs to be a subclass of an abstract class called 'Shape" (since a Circle is a Shape). Would you be able to do this for the code above?! Or would it have been simpler if Circle would have implemented the Runnable interface?!

[Srinivasa Raghavan]

Ok Rao . I agree your statement.
Is there any other advantages other than this ?

[Vijayendra V Rao]

Originally posted by srini vasan:
Is there any other advantages other than this ?

I'm sorry but I can't think of any other advantages. Until now, I have found myself chosing the Runnable interface for only this purpose that I have mentioned (since this is such a common situation).

[Tomer Gal]

I Dont use any of the approches,
I Build an inner class.

void openSocketListenThread() {
Thread myThread = new Thread ( new Runnable() {
public void run() {
openSocketListen();
}
} );
myThread.start();

}
void openSocketListen() {
//do what you'd like
}



I Find this approach much more suited for object oriented programming.

[David Harkness]

Originally posted by Tomer G.:
I Dont use any of the approches,
I Build an inner class.

Technically, this is the "implement Runnable" method since that's precisely what your inner class does. "new Runnable() {...}" creates an anonymous inner class that extends Object and implements Runnable.

To me, it's not about advantages but rather correctness and clarity of design. Threads run tasks (Runnables) while Runnables are things that can be run (by Threads, Timers, etc). The only reason to extend Thread is to extend or alter Thread's behavior. Well, since Thread already runs Runnables, you don't need to extend Thread's behavior to make it run some code; that behavior is already there.

Vijayendra is indeed correct that you're painting yourself into a corner by extending Thread, but I'd say the first consideration is to do what makes logical sense given your requirements.

Oh, one other advantage to extending Runnable is that you can reuse the same Runnable with multiple Threads, either at the sime time or sequentially. Runnable implementations can also be used with existing classes like PooledExecutor, whereas Thread subclasses would require you to create your own version.

Sometimes you do something simply because it makes sense, not because you achieve some tangible benefit or advantage.

[Jeroen Wenting]

Many objects extend something else (besides Object) already so using Thread (never mind that it's not correct OO design in many situations) is often not even possible.

Mind that if you extend Thread you're still implementing Runnable after all, so why not do it directly and save the middle man?
The only reason I could come up with for extending Thread is if you have a ton of fields to set in your object to support run() in which case extending Thread saves you a few method calls and/or creating a wrapper object for that data to pass in the Runnable constructor.

[Stan James]

It's just a general OO guideline to prefer abstractions over concrete things. Implementing an interface is more abstract than extending a concrete class. Extending Thread is not wrong, but it is less flexible which may cause some regrets in the long run.

There is also a common question about restarting threads and the sad answer: you can't. But if you have an object instance that needs to go through its run() method, hold some state, go through run() again, hold some state, etc. you can do that with a Runnable. This will run a Runnable twice:

Runnable r = new MyRunnable();
new Thread(r).start();
// somehow wait for that to finish ...
new Thread(r).start();

[Anderson Adolfs]

Well. The main situation of using interfaces is that Java Language does not support more than one inheritance, like c++. So, if you wanna develop an applet that must use Threads ? How coult you do this ? public class nameOfClass extends JApplet extends Thread ? No, impossible. You will use the power of implements an interface.

public class nameOfClass extends JApplet implements Runnable, ... {
...
...
}

I think that is It.

[Tim McGuire]

In the case of needing to extend thread in an applet, don't make the main class extend Thread, make an inner class extend Thread:
[CODE]
public class nameOfClass extends JApplet {
public void aMethod(){
.....
}

class ThreadedObject extends Thread {
// you can make as many of these as the applet needs
}

} // end of Applet class
[CODE]
This is more flexible and easier to understand than implementing runnable. An example would be, what if you implement Runnable and decide later you need another thread? I think it would be a lot of code reworking. Using an object that extends Thread, there is flexibility built in.
[ January 11, 2005: Message edited by: Tim McGuire ]

[Anderson Adolfs]

Explaining about effectiveness of Java Programming, I think this is more flexible in this example. But is a solution for non support of multiple inheritance in Java, and maybe this can be used someday...

Aswering the question of srini, the advantages are these. David Darkness gave a good answer.

"...it's not about advantages but rather correctness and clarity of design...";

so,

"...advantage of implementing Runnable is that you can reuse It with multiple Threads..."

Anderson.

[Ilja Preuss]

Originally posted by David Harkness:
To me, it's not about advantages but rather correctness and clarity of design. Threads run tasks (Runnables) while Runnables are things that can be run (by Threads, Timers, etc).

Well, clarity of design certainly is a big advantage, isn't it?

Also, a Runnable doesn't necessarily need to be run by a Thread - it can be run by anything that accepts a Runnable as parameter. That is, implementing Runnable also makes your design more flexible.

Also, a Thread is a more heavyweight object than a Runnable. If you split the two, you can create the Runnable way before actually running it, store tons of them in a queue or something etc. pp. without the overhead of a whole Thread instance having to be created before you actually need to run something.

Now let's ask the question the other way around: Can anyone think of an advantage that extending Thread gives you over implementing a Runnable?

[Srinivasa Raghavan]

Thanks for all replies.
Now i understood the concept