Links

Lists

Latest Updates

Ruby On Rails List
Python list
Advanced Java
The JavaScript List
Apache Users
Full Disclosure
Linux Security

Search the archives!


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Advanced-java] enclosing class creating a thread advice


  • From: nikolaos@xxxxxxxxx (Nikolaos Giannopoulos)
  • Subject: [Advanced-java] enclosing class creating a thread advice
  • Date: Thu, 14 Mar 2002 16:13:46 -0000

Dave,

Sounds like a very good question.

(1) This example is a very simple case that just outlines the mechanism with
only the doWork() method.  The major difference over just using runnable in
my experience is that ThreadWork can be enhanced to provide more than just
doWork().  For example if you wanted to separate the initialization and tear
down of resources you could add the following methods to the interface:

public void initResources();
public void releaseResources();

This is especially useful if you expect the work to iterate over pieces of
data and you need to establish/tear down a db connection at most once (for
any given work).

(2) If you relied on runnable and needed anything beyond run() then you
would end up creating the interface that I described anyways (albeit at a
later point in time).

(3) I find that the design intent is more clearly delineated by using this
interface even if all you want to do is doWork() i.e. it is clear to those
using this class that they are implementing ThreadWork and what the
implications of doing so are.  Implementing Runnable simply implies that
instances of this class will be passed to a thread.

Personally, and this is solely my opinion, I think these are some of the
benefits to this approach over simply using Runnable - I would imagine there
are probably others as well.

HTH.

--Nikolaos



> From: advanced-java-admin@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:advanced-java-admin@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Dave
> Wathen
>
>
> In what way is this solution different to using Runnable?
>
> Dave Wathen
> Canzonet Limited
> http://www.canzonet.com
> mailto:dave.wathen@xxxxxxxxxxxx
>
> -----Original Message-----
> From: advanced-java-admin@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:advanced-java-admin@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Nikolaos
> Giannopoulos
> Sent: 14 March 2002 13:54
> To: Tim O'Neil; advanced-java@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: [Advanced-java] enclosing class creating a thread advice
>
>
> > From: advanced-java-admin@xxxxxxxxxxxxxxxxxxxxxx
> > [mailto:advanced-java-admin@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Tim
> > O'Neil
> >
> > I have a class that spins off a thread to do some work on a
> > data file. This class hangs subordinate classes out to do
> > i/o and random access file work that must be referenced by
> > the thread. I am currently passing a reference to the entire
> > enclosing class to the thread so it has all the stuff it needs
> > to do its thing. This works, but it seems kinda ugly to me.
> > I wonder if this is the way to go or does this seem like a
> > scenario for reflection or some other method?
>
>
> If you are passing in a specific class then this probably seems
> ugly because
> the solution doesn't seem flexible enough.  How about doing the following:
>
> public interface ThreadWork {
>   public void doWork();
> }
>
> public class SomeThreadWorkA implements ThreadWork {
>   public SomeThreadWorkA() {}
>   public void doWork() {
>     // Actual Work specific to this class A
>   }
> }
>
> Now your ThreadWorker can hold references to ThreadWork objects and simply
> invoke doWork() on without really caring what the actual work does - since
> it is specific to the work itself (and encapsulated therein) and
> not part of
> the interface.
>
> HTH.
>
> --Nikolaos
>
>
> _______________________________________________
> Advanced-java mailing list
> Advanced-java@xxxxxxxxxxxxxxxxxxxxxx
> http://lists.xcf.berkeley.edu/mailman/listinfo/advanced-java
>
> _______________________________________________
> Advanced-java mailing list
> Advanced-java@xxxxxxxxxxxxxxxxxxxxxx
> http://lists.xcf.berkeley.edu/mailman/listinfo/advanced-java
>