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 <[EMAIL PROTECTED]> wrote:
"Joe Carter" <[EMAIL PROTECTED]> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
