Singleton & Interfaces

[rob]

I have two different classes singleton1 and singleton2 that both are
singletons. Both classes implement the same functions. Therefore, I
would like to have an interface containing these functions. The problem
is that an interface does not allow static functions and an abstract
class does not work in my case because multiple inheritence is not
allowed. So how do I go after doing this?

Thanks

[Jeffrey Hornby]

One way to define a singleton that doesn't necessarily look like a singleton
is to have a normal class that has to be instantiated to be used but have all
the private member variables static. This isn't the classic singleton
pattern but it works in the same way.

--
Jeffrey Hornby
Hornby Consulting, Inc.

"rob" wrote:

I have two different classes singleton1 and singleton2 that both are
singletons. Both classes implement the same functions. Therefore, I
would like to have an interface containing these functions. The problem
is that an interface does not allow static functions and an abstract
class does not work in my case because multiple inheritence is not
allowed. So how do I go after doing this?

Thanks

[Nicholas Paldino [.NET/C# MVP]]

Rob,

If you were truly implementing the singleton pattern, you would be
exposing an instance for each singleton. This would make exposing an
interface easy. You would just choose which singleton you are returning,
and return the interface implementation.

Of course, you do this instead of having static members.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"rob" <rm*******@yahoo.com> wrote in message
news:11*********************@b68g2000cwa.googlegro ups.com...

I have two different classes singleton1 and singleton2 that both are
singletons. Both classes implement the same functions. Therefore, I
would like to have an interface containing these functions. The problem
is that an interface does not allow static functions and an abstract
class does not work in my case because multiple inheritence is not
allowed. So how do I go after doing this?

Thanks

[rob]

Yes, each of my singletons exposes a separate instance of itself.
Unfortunately, I don't really follow what your suggestion is. Could you
elaborate on this?

Thanks

Nicholas Paldino [.NET/C# MVP] wrote:

Rob,

If you were truly implementing the singleton pattern, you would be
exposing an instance for each singleton. This would make exposing an
interface easy. You would just choose which singleton you are returning,
and return the interface implementation.

Of course, you do this instead of having static members.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"rob" <rm*******@yahoo.com> wrote in message
news:11*********************@b68g2000cwa.googlegro ups.com...

I have two different classes singleton1 and singleton2 that both are
singletons. Both classes implement the same functions. Therefore, I
would like to have an interface containing these functions. The problem
is that an interface does not allow static functions and an abstract
class does not work in my case because multiple inheritence is not
allowed. So how do I go after doing this?

Thanks

[Nicholas Paldino [.NET/C# MVP]]

rob,

Well, what you would do really at this point is expose a class factory
of sorts. Basically, since both singletons expose the same interface, you
have to have a way of choosing which implementation you want, something
like:

public interface IMyInterface
{}

public static class A : IMyInterface
{
static readonly instance = new A();

public static Instance
{
get
{
return instance;
}
}
}

public static class B : IMyInterface
{
static readonly instance = new B();

public static Instance
{
get
{
return instance;
}
}
}

public static class MySingletonFactory
{
public static this[string index]
{
get
{
if (index == "A")
{
return A.Instance;
}
if (index == "B")
{
return B.Instance;
}
throw new Exception();
}
}
}

It's a little sparse, but it should give you a good idea of what I am
talking about.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"rob" <rm*******@yahoo.com> wrote in message
news:11*********************@i40g2000cwc.googlegro ups.com...

Yes, each of my singletons exposes a separate instance of itself.
Unfortunately, I don't really follow what your suggestion is. Could you
elaborate on this?

Thanks

Nicholas Paldino [.NET/C# MVP] wrote:

Rob,

If you were truly implementing the singleton pattern, you would be
exposing an instance for each singleton. This would make exposing an
interface easy. You would just choose which singleton you are returning,
and return the interface implementation.

Of course, you do this instead of having static members.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"rob" <rm*******@yahoo.com> wrote in message
news:11*********************@b68g2000cwa.googlegro ups.com...

>I have two different classes singleton1 and singleton2 that both are
> singletons. Both classes implement the same functions. Therefore, I
> would like to have an interface containing these functions. The problem
> is that an interface does not allow static functions and an abstract
> class does not work in my case because multiple inheritence is not
> allowed. So how do I go after doing this?
>
> Thanks
>

[sloan]

To followup on Nicholas' post:

http://sholliday.spaces.msn.com/PersonalSpace.aspx 12/1/2005
Understanding the Simple Factory Pattern

There are several way to do a Factory. His is the "key method".

I have 2 other methods at my blog:


"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:%2****************@TK2MSFTNGP03.phx.gbl...

rob,

Well, what you would do really at this point is expose a class factory
of sorts. Basically, since both singletons expose the same interface, you
have to have a way of choosing which implementation you want, something
like:

public interface IMyInterface
{}

public static class A : IMyInterface
{
static readonly instance = new A();

public static Instance
{
get
{
return instance;
}
}
}

public static class B : IMyInterface
{
static readonly instance = new B();

public static Instance
{
get
{
return instance;
}
}
}

public static class MySingletonFactory
{
public static this[string index]
{
get
{
if (index == "A")
{
return A.Instance;
}
if (index == "B")
{
return B.Instance;
}
throw new Exception();
}
}
}

It's a little sparse, but it should give you a good idea of what I am
talking about.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"rob" <rm*******@yahoo.com> wrote in message
news:11*********************@i40g2000cwc.googlegro ups.com...

Yes, each of my singletons exposes a separate instance of itself.
Unfortunately, I don't really follow what your suggestion is. Could you
elaborate on this?

Thanks

Nicholas Paldino [.NET/C# MVP] wrote:

Rob,

If you were truly implementing the singleton pattern, you would be
exposing an instance for each singleton. This would make exposing an
interface easy. You would just choose which singleton you are returning, and return the interface implementation.

Of course, you do this instead of having static members.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"rob" <rm*******@yahoo.com> wrote in message
news:11*********************@b68g2000cwa.googlegro ups.com...
>I have two different classes singleton1 and singleton2 that both are
> singletons. Both classes implement the same functions. Therefore, I
> would like to have an interface containing these functions. The problem > is that an interface does not allow static functions and an abstract
> class does not work in my case because multiple inheritence is not
> allowed. So how do I go after doing this?
>
> Thanks
>

[Jon Skeet [C# MVP]]

Jeffrey Hornby <Je***********@discussions.microsoft.com> wrote:

One way to define a singleton that doesn't necessarily look like a singleton
is to have a normal class that has to be instantiated to be used but have all
the private member variables static. This isn't the classic singleton
pattern but it works in the same way.

It's also a way that leads to very confusing code, in my experience. At
the very least, it needs to be very, very clearly documented. Otherwise
a developer who creates separate instances and (for example) sets a
property to different values against the different instances would be
very confused to see the last property set appear to "win" for all
instances.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jeffrey Hornby]

But that's a risk for all classic singletons. The only way avoid that
problem is to implement a singleton strictly as a static class or store the
sole reference to the singleton in a global variable.

--
Jeffrey Hornby
Hornby Consulting, Inc.

"Jon Skeet [C# MVP]" wrote:

Jeffrey Hornby <Je***********@discussions.microsoft.com> wrote:

One way to define a singleton that doesn't necessarily look like a singleton
is to have a normal class that has to be instantiated to be used but have all
the private member variables static. This isn't the classic singleton
pattern but it works in the same way.

It's also a way that leads to very confusing code, in my experience. At
the very least, it needs to be very, very clearly documented. Otherwise
a developer who creates separate instances and (for example) sets a
property to different values against the different instances would be
very confused to see the last property set appear to "win" for all
instances.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Jeffrey Hornby <Je***********@discussions.microsoft.com> wrote:

But that's a risk for all classic singletons. The only way avoid that
problem is to implement a singleton strictly as a static class or store the
sole reference to the singleton in a global variable.

But with a classic singleton the developer can't create two different
instances. It's when you've got separate instances which effectively
share all their state that confusion comes in, IMO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jeffrey Hornby]

In my experience, singleton often causes some confusion no matter how it is
implemented for exactly the reason you set forth. Although they might be the
same instance two different references to the same singleton created by a
factory method will appear to many programmers as two entirely different
objects especially if they aren't aware that they are dealing with a
singleton.

That is why it is always important to clearly document - preferably in the
name of the class and/or the factory method - that you are using a singleton
no matter what method you use.

--
Jeffrey Hornby
Hornby Consulting, Inc.

"Jon Skeet [C# MVP]" wrote:

Jeffrey Hornby <Je***********@discussions.microsoft.com> wrote:

But that's a risk for all classic singletons. The only way avoid that
problem is to implement a singleton strictly as a static class or store the
sole reference to the singleton in a global variable.

But with a classic singleton the developer can't create two different
instances. It's when you've got separate instances which effectively
share all their state that confusion comes in, IMO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Mark Wilden]

"Jeffrey Hornby" <Je***********@discussions.microsoft.com> wrote in message
news:2A**********************************@microsof t.com...

In my experience, singleton often causes some confusion no matter how it
is
implemented for exactly the reason you set forth. Although they might be
the
same instance two different references to the same singleton created by a
factory method will appear to many programmers as two entirely different
objects especially if they aren't aware that they are dealing with a
singleton.

I'm trying to think of a case where it would matter to clients whether
they're using a singleton or not. It seems to me that if the design is
correct, and that a singleton is the way to go, that clients shouldn't need
to care. But this is just a gut feeling of mine.

Does someone have a concrete example of why clients should need to know
they're using a singleton?

///ark

[Jeffrey Hornby]

If the client (or more accurately, the programmer writing the client) isn't
aware that they are working with a singleton and have two or more references
to it, the client code could, for example, set a property on the object which
is changed by some other piece of code. If the client code doesn't know that
anybody else requesting and instance of that class is getting the same object
(or an object that points to the same data), they might be depending on that
object not changing.

It's the same problem we used to have with global variables when somebody
assumed that they were the only one using the global variable. Another
section of code could make a change that your code doesn't expect.

--
Jeffrey Hornby
Hornby Consulting, Inc.

"Mark Wilden" wrote:

"Jeffrey Hornby" <Je***********@discussions.microsoft.com> wrote in message
news:2A**********************************@microsof t.com...

In my experience, singleton often causes some confusion no matter how it
is
implemented for exactly the reason you set forth. Although they might be
the
same instance two different references to the same singleton created by a
factory method will appear to many programmers as two entirely different
objects especially if they aren't aware that they are dealing with a
singleton.

I'm trying to think of a case where it would matter to clients whether
they're using a singleton or not. It seems to me that if the design is
correct, and that a singleton is the way to go, that clients shouldn't need
to care. But this is just a gut feeling of mine.

Does someone have a concrete example of why clients should need to know
they're using a singleton?

///ark

[Mark Wilden]

"Jeffrey Hornby" <Je***********@discussions.microsoft.com> wrote in message
news:CD**********************************@microsof t.com...

If the client (or more accurately, the programmer writing the client)
isn't
aware that they are working with a singleton and have two or more
references
to it, the client code could, for example, set a property on the object
which
is changed by some other piece of code. If the client code doesn't know
that
anybody else requesting and instance of that class is getting the same
object
(or an object that points to the same data), they might be depending on
that
object not changing.

Yes, I understand the theoretical possibilities. What I was looking for was
a real-world example. In practice, I think one generally doesn't set
properties on a singleton that another client might want to change. But I
could be wrong.

[Jeff Louie]

Mark... The classic example of a singleton that is not necessarily a
singleton... is
a print spooler. You get a reference to a print spooler and send it an
immutable
object. The immutable object gets printed. It does not matter that the
user is
aware of the singleton nature of the print spooler or not. In fact, the
design
specifically allows the eventual use of more than one print spooler. The
user
does not know if there is more than one print spooler or know what print
spooler they are printing to.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Mark Wilden]

"Jeff Louie" <je********@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

Mark... The classic example of a singleton that is not necessarily a
singleton... is
a print spooler. You get a reference to a print spooler and send it an
immutable object. The immutable object gets printed. It does not matter
that the
user is aware of the singleton nature of the print spooler or not. In
fact, the
design specifically allows the eventual use of more than one print
spooler. The
user does not know if there is more than one print spooler or know what
print
spooler they are printing to.

Right. This example, at least, supports my (somewhat hazy) hypothesis that
the client of a singleton need not know he's using a singleton.

///ark