Singleton types and static class

[Mohd Ebrahim]

1. Singleton types never have more than one instance at any one time. If an
instance exists, all client requests are serviced by that instance. If an
instance does not exist, the server creates an instance and all subsequent
client requests will be serviced by that instance. Because Singleton types
have an associated default lifetime, clients will not always receive a
reference to the same instance of the remotable class, even though there is
never more than one instance available at any one time.

2. In the above scenerio what If i just use a static class (non -instance
class) will this not server me purpose mentioned in the above statment

what is the difference between 1 & 2 ?

Thanks

 

[Hans Kesting]

Mohd Ebrahim brought next idea :

1. Singleton types never have more than one instance at any one time. If an
instance exists, all client requests are serviced by that instance. If an
instance does not exist, the server creates an instance and all subsequent
client requests will be serviced by that instance. Because Singleton types
have an associated default lifetime, clients will not always receive a
reference to the same instance of the remotable class, even though there is
never more than one instance available at any one time.

2. In the above scenerio what If i just use a static class (non -instance
class) will this not server me purpose mentioned in the above statment

what is the difference between 1 & 2 ?

Thanks

You *can* pass around a reference to a singleton. You *can't* do that
for a static class.

Hans Kesting

 

[Family Tree Mike]

1. Singleton types never have more than one instance at any one time. If an
instance exists, all client requests are serviced by that instance. If an
instance does not exist, the server creates an instance and all subsequent
client requests will be serviced by that instance. Because Singleton types
have an associated default lifetime, clients will not always receive a
reference to the same instance of the remotable class, even though there is
never more than one instance available at any one time.

2. In the above scenerio what If i just use a static class (non -instance
class) will this not server me purpose mentioned in the above statment

what is the difference between 1 & 2 ?

Thanks

It sounds like you are not keeping your instance alive long enough. Why are
you releasing (disposing) the instance? The standard way of implimenting a
singleton should keep a handle to the instance in the class, and therefore it
should be kept alive.

Mike

 

[proxyuser]

1. Singleton types never have more than one instance at any one time. If
an
instance exists, all client requests are serviced by that instance. If an
instance does not exist, the server creates an instance and all subsequent
client requests will be serviced by that instance. Because Singleton types
have an associated default lifetime, clients will not always receive a
reference to the same instance of the remotable class, even though there
is
never more than one instance available at any one time.

2. In the above scenerio what If i just use a static class (non -instance
class) will this not server me purpose mentioned in the above statment

One difference is that a singleton is not created unless (and until) needed
(or at least you can program it that way.) A static is always created at
load time. If it has some memory or performance hit, then this is
undesirable. You might want to control when it happens.

Although I'm not really sure what you mean by "associated default lifetime".
Off the top of my head, this doesn't necessarily sound true for the general
case, since the "lifetime" could simply be "until the app closes".

 

[Peter Duniho]

1. Singleton types never have more than one instance at any one time. If
an
instance exists, all client requests are serviced by that instance. If an
instance does not exist, the server creates an instance and all
subsequent
client requests will be serviced by that instance. Because Singleton
types
have an associated default lifetime, clients will not always receive a
reference to the same instance of the remotable class, even though there
is
never more than one instance available at any one time.

As others have said, you should be more specific about your "Singleton
type". The singleton pattern doesn't in and of itself dictate a finite
lifetime, but of course if you are using some framework that defines its
own kind of singleton it might impose something like that.

2. In the above scenerio what If i just use a static class (non -instance
class) will this not server me purpose mentioned in the above statment

what is the difference between 1 & 2 ?

As an object, a singleton instance can implement interfaces and inherit
base classes. Other than that, very little difference. A singleton
(optionally) offers a slightly more abstracted "lazy initialization"
implementation, but even with a static class you can initialize any
underlying data structures needed to support the implementation lazily, so
there's not much practical difference in that respect.

In terms of your specific description, if you _do_ have a singleton that
is implemented to have a finite lifetime, then of course it is much
simpler to implement that with a singleton than with a static class (you
could keep the static class in its own AppDomain so it can be unloaded, or
provide a method in the class to discard any stored data as a way of
implementing a sort of pseudo-lifetime). As mentioned before, singletons
are not inherently subject to this condition, but in your specific case I
suppose yours may be.

Pete

 

[Tom Spink]

One difference is that a singleton is not created unless (and until) needed
(or at least you can program it that way.) A static is always created at
load time. If it has some memory or performance hit, then this is
undesirable. You might want to control when it happens.

Hi proxyuser,

By created do you mean constructed? Because I'm afraid this is not the
case. A static class is constructed on first use of a member.

At least, this is the behaviour in 3.5.

-- Tom

 

[proxyuser]

Hi proxyuser,

By created do you mean constructed? Because I'm afraid this is not the
case. A static class is constructed on first use of a member.

Well, I was thinking of a static object in general. If the OP meant static
class (which is literally what he wrote) then you're right. I assumed he
meant instantiation of a static object to serve as a singleton.

 

[Peter Duniho]

[...] A static is always created at
load time. If it has some memory or performance hit, then this is
undesirable. You might want to control when it happens.

Hi proxyuser,

By created do you mean constructed? Because I'm afraid this is not the
case. A static class is constructed on first use of a member.

Well, I was thinking of a static object in general. If the OP meant
static
class (which is literally what he wrote) then you're right. I assumed he
meant instantiation of a static object to serve as a singleton.

That still doesn't imply that the object is instantiated when the code is
loaded. As long as the static members of the class are never referenced,
the initialization won't occur.

Pete