The only thing required by a Runnable class is a run( ) method, but if you want to do anything else to the Thread object (such as getName( ) in toString( )) you must explicitly get a reference to it by calling Thread.currentThread( ). This particular Thread constructor takes a Runnable and a name for the thread.
When something has a Runnable interface, it simply means that it has a run( ) method, but there�s nothing special about that�it doesn�t produce any innate threading abilities, like those of a class inherited from Thread. So to produce a thread from a Runnable object, you must create a separate Thread object as shown in this example, handing the Runnable object to the special Thread constructor. You can then call start( ) for that thread, which performs the usual initialization and then calls run( ).
The convenient aspect about the Runnable interface is that everything belongs to the same class; that is, Runnable allows a mixin in combination with a base class and other interfaces. If you need to access something, you simply do it without going through a separate object. However, inner classes have this same easy access to all the parts of an outer class, so member access is not a compelling reason to use Runnable as a mixin rather than an inner subclass of Thread.
When you use Runnable, you�re generally saying that you want to create a process in a piece of code�implemented in the run( ) method�rather than an object representing that process. This is a matter of some debate, depending on whether you feel that it makes more sense to represent a thread as an object or as a completely different entity, a process. If you choose to think of it as a process, then you are freed from the object-oriented imperative that �everything is an object.� This also means that there�s no reason to make your whole class Runnable if you only want to start a process to drive some part of your program. Because of this, it often makes more sense to hide your threading code inside your class by using an inner class, as shown here:
InnerThread1 creates a named inner class that extends Thread, and makes an instance of this inner class inside the constructor. This makes sense if the inner class has special capabilities (new methods) that you need to access in other methods. However, most of the time the reason for creating a thread is only to use the Thread capabilities, so it�s not necessary to create a named inner class. InnerThread2 shows the alternative: An anonymous inner subclass of Thread is created inside the constructor and is upcast to a Thread reference t. If other methods of the class need to access t, they can do so through the Thread interface, and they don�t need to know the exact type of the object.
The third and fourth classes in the example repeat the first two classes, but they use the Runnable interface rather than the Thread class. This is just to show that Runnable doesn�t buy you anything more in this situation, but is in fact slightly more complicated to code (and to read the code). As a result, my inclination is to use Thread unless I�m somehow compelled to use Runnable.
The ThreadMethod class shows the creation of a thread inside a method. You call the method when you�re ready to run the thread, and the method returns after the thread begins. If the thread is only performing an auxiliary operation rather than being fundamental to the class, this is probably a more useful/appropriate approach than starting a thread inside the constructor of the class.
...You need to know about both for the exam, although in the real world you�re much
more likely to implement Runnable than extend Thread. Extending the Thread class
is the easiest, but it�s usually not a good OO practice. Why? Because subclassing should
be reserved for classes that extend an existing class, because they�re a more specialized
version of the more general superclass. So the only time it really makes sense (from an
OO perspective) to extend Thread is when you have a more specialized version of a
Thread class. In other words, because you have more specialized thread-specific behavior.
Chances are, though, that the thread work you want is really just a job to be done by
a thread. In that case, you should design a class that implements the Runnable interface,
which also leaves your class free to extend from some other class...
Originally posted by merlin bar:
I actually had the same question, but one area which has not been mentioned is access to private members.
According to O'Reilly's 'Exploring Java', implementing runnable (as opposed to extending Thread) "has the added advantage of allowing run() to access any private variables and methods it might need in the class."
This leads me to believe that extending Thread does not give this option. If this is the case, then there is a significant difference.
I suppose getter/setter methods could be used to overcome this.
No need to feel sorry, you are very welcome to start some comparative-culture-talk thread and your this post has already amazed me: you speak cool Chinese indeed, the accurate 4 tones even cooler than some native Chinese people.No exaggeration here. It's definitely not easy for a foreigner. And even...Zhuang1 Zi3...wow, my admirations!!
Sorry for the random thoughts, just needed a break from this dumb project I'm working on.
This parrot is no more. It has ceased to be. Now it's a tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your databasehttps://coderanch.com/t/704633/RavenDB-Open-Source-NoSQL-Database