Object without a value

I was asking this question about controlling a thread that was reading from a blocking queue.开发者_StackOverflow中文版 Although it wasn't the solution I chose to go with, several people suggested that a special "poison pill" or "sentinel" value be added to the queue to shut it down like so:

public class MyThread extends Thread{
    private static final Foo STOP = new Foo();
    private BlockingQueue<Foo> blockingQueue = new LinkedBlockingQueue<Foo>();

    public void run(){
        try{
            Foo f = blockingQueue.take();
            while(f != STOP){
                doSomethingWith(f);
                f = blockingQueue.take();
            }
        }
        catch(InterruptedException e){

        }
    }

    public void addToQueue(Foo f) throws InterruptedException{
        blockingQueue.put(f);
    }

    public void stop() throws InterruptedException{
        blockingQueue.put(STOP);
    }
}

While I like this approach, I decided not to use it because I wasn't sure what value to use for the STOP field. In some situations it's obvious - for instance, if you know you're inserting positive integers, negative numbers could be used as control values - but Foo is a fairly complex class. It's immutable and hence has a constructor that takes several arguments. To add a no-argument constructor would mean leaving several fields uninitialised or null, which would cause methods to break if they were used elsewhere - Foo is not just used with MyThread. Similarly, putting dummy values into the main constructor would just pass this problem on as several of the fields and constructor parameters are themselves significant objects.

Am I simply programming over-defensively? Should I worry about adding no-argument constructors to a class, even if there are no setters to make the object usable (just assume other programmers will be sensible enough to not use that constructor)? Is the design of Foo broken if it can't have a no-argument constructor or at least a non-value - would it be better to put if(someField == null){throw new RuntimeException();} checks in all methods?

I don't really see what the advantage of this design is versus a simple boolean variable to indicate the loop should stop.

But if you really want to go with this design, I would suggest making a private no-arg constructor, and making a static STOP Foo. Like this.

public class Foo {

  public static final Foo STOP = new Foo();
  ... fields

  private Foo(){}
  public Foo(...){
    ...
  }

  ...

}

public class MyThread extends Thread{
  private static final Foo STOP = new Foo();
  private BlockingQueue<Foo> blockingQueue = new LinkedBlockingQueue<Foo>();

  public void run(){
      try{
          Foo f = blockingQueue.take();
          while(f != STOP){
              doSomethingWith(f);
              f = blockingQueue.take();
          }
      }
      catch(InterruptedException e){

      }
  }

  public void addToQueue(Foo f) throws InterruptedException{
      blockingQueue.put(f);
  }

  public void stop() throws InterruptedException{
      blockingQueue.put(Foo.STOP);
  }
}

This has the advantage that you're still not exposing an invalid constructor.

The disadvantage is that the Foo class knows that in some cases it's used as a 'poison pill', which might not be what it's for. Another disadvantage is that The STOP object might be inconsistent. You could make an anonymous subclass from it do disable the methods with UnsupportedOperationException or something.

I think you're right about not using empty constructors. If Foo is such an complex class, it doesn't seem logical to use a complete object for that.

If adding a null is possible. That seems a nice way to go.

Another way could also be to implement an interface. IBlockableQueueObject? This could be implemented by the foo object and by the STOP sign. Only thing is that you have to cast the interface back to the Foo if it is not a STOP.

another option would be to wrap Foo in a generic wrapper such as this:

public class Wrapped<T> {
    private final T value;

    public Wrapped(T value) {
        this.value = value;
    }

    public T get() { return value; }
}

which you can then use to pass a null value as a poison pill to a BlockingQueue<Wrapped<Foo>>.

You should worry about having no-argument constructors that don't result in usable instances.

The design of Foo sounds fine - I would generally assume that I'm not allowed to pass in null into a constructor unless the documentation specifically allows me to. Especially with an immutable class.