Non-static Peers (was: Torque 4.0 plan)

Oops, I used the swear word "singleton" ... Fortunately, I probably 
misused it. I did not mean to enforce singleton behaviour, i.e. to forbid 
the existence of more than one instance. The static wrapper would be for 
ease of usage, the Backend class for those which do not want to use static 
method at all, and for the people in between, a setter to exchange the 
backend of the static class. I have appended some sample code.

Would this be ok ? Any better suggestions ?

    Thomas

The code would look as follows:

public class SomePeer
{
  private static SomePeerBackend backend;

  static
  {
    backend = new SomePeerBackend();
  }

  public static void setBackend(SomePeerBackend backend)
  {
    if (backend == null)
    {
      throw new NullPointerException();
    }
    this.backend = backend;
  }

  public static List doSelect(Criteria criteria)
  {
    return backend.doSelect(criteria);
  }

  ....
}

public class SomePeerBackend
{
  /** Public constructor */
  public SomePeerBackend()
  {
  }

  public List doSelect(Criteria criteria)
  {
    // do select, return results
    ...
  }

  ...
}

On Fri, 1 Dec 2006, Joe Carter wrote:

> On 30/11/06, Henning P. Schmiedehausen <hps@xxxxxxxxxxxx> wrote:
> > "Joe Carter" <joe.carter@xxxxxxxxxx> writes:
> >
> > >Personally I'd just have the singleton (snip...)
> >
> > If you think about a singleton, please separate the singleton class
> > and the implementation class (don't have the static getInstance()
> > method and a possible private C'tor in the implementation). If you
> > separate these, it is possible for projects using e.g. Spring to
> > manage the classes through the framework.
> >
> > Even better, google for 'evil singleton' and read the first few links...
> >
> >         Best regards
> >                 Henning
> >
> > I completely agree. Allowing plug-in frameworks to work would be the
> ideal.
> Giving me _any_ way to extend was my main concern.
> I was just a bit wary of asking for too much :-)
>
> Cheers
>
> Joe