Static classes vs Singletons (pt 2)

[Joanna Carter \(TeamB\)]

Following on from the other discussion, I have to just check something out
with reference to disposal of resources held in static fields.

I have a Persistence Framework that is 'globally accessible'. In Delphi, I
would use a class of static methods to enforce the singleton, and I added
static fields to hold things like the database connections, etc.

This worked fine in Delphi because we have unit initialisation/finalisation
sections that can act as static constructors/destructors, and with
deterministic finalisation, we could simulate a static destructor in the
finalisation and clean up resources there on application closedown.

Now, bearing in mind that if I use the 'proper' Singleton pattern, I am
always accessing a static field through a static method, I can't see any
difference between using my own class of static methods to access the static
fields, and using the Singleton pattern.

My question is, do the instances pointed to by static fields ever get
garbage collected ?

I have always assumed that this happened as part of the tidy-up code that
got executed when the application quit.

Joanna

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Now, bearing in mind that if I use the 'proper' Singleton pattern, I am
always accessing a static field through a static method, I can't see any
difference between using my own class of static methods to access the
static
fields, and using the Singleton pattern.

Hi, It's not the same even as they looks much alike, if you use static
class you do not create an instance of the class , you cannot for example
pass around an instance of that class as a parameter to methods.

With a singleton you create an instance and after that there is no
difference between it and an instance of another class that is not
singleton. The only difference is that the singleton class has no public
construtor and you have 100% control of the construction process using the
static method/Property .
Also you could easily allow to destroy & recreate the instance at will:

// NOT THE BEST WAY TO IMPLEMENT a singleton
class singleton
{
static singleton theInstance = null;

public singleton GetIt
{
get
{
if ( theInstance == null )
theInstance = new singleton();
return theInstance;
}

//Remove the instance, when called again the property it will be
re-instanciated
public void Reset()
{
theInstance = null;
}

}

you cannot do that with a static class

My question is, do the instances pointed to by static fields ever get
garbage collected ?

All you have to do is assign it to null :

static DataSet ds = new DataSet();

void Clean()
{
ds = null;
}

Otherwise it will be kept until the AppDomain be active.



Cheers,

 

[Joanna Carter \(TeamB\)]

//Remove the instance, when called again the property it will be
re-instanciated
public void Reset()
{
theInstance = null;
}

}

you cannot do that with a static class

I would not want to do that with the static classes I have in mind, they
should be available at all times that the app is running.

All you have to do is assign it to null :

static DataSet ds = new DataSet();

void Clean()
{
ds = null;
}

In that case, I could just as well call a static method on my class to free
off the connections held by the static fields; the effect would be the same.
All I have to do is to call a 'finaliser' static method at the end of the
main() method of the app.

Otherwise it will be kept until the AppDomain be active.

If, by this, you mean when the application quits, then there should be no
problem.

My question was : If you have static fields that need Disposal of resources
and those fields are intended to last the entire run of the app, do I need
to explicitly finalise them or will the app closing do this for me ?

 

[Jon Skeet [C# MVP]]

If, by this, you mean when the application quits, then there should be no
problem.

Usually that's the same thing, but not always. Chances are if you don't
know you're creating a new AppDomain, you're not

My question was : If you have static fields that need Disposal of resources
and those fields are intended to last the entire run of the app, do I need
to explicitly finalise them or will the app closing do this for me ?

Well, the finalizers will get run if the app goes down cleanly, *but*
they only get a few seconds to execute - so if there are lots of them
and one of them takes a while, the others won't happen.

Personally I'd always prefer to put some explicit shutdown code in.

 

[Joanna Carter \(TeamB\)]

Well, the finalizers will get run if the app goes down cleanly, *but*
they only get a few seconds to execute - so if there are lots of them
and one of them takes a while, the others won't happen.

Personally I'd always prefer to put some explicit shutdown code in.

So, I would be best having something like the following :

static class ObjectStore
{
private ClassThatUsesResource fred;
...
public static void Shutdown()
{
fred.Dispose();
fred = null;
}
}

....called from Main()

{
...
ObjectStore.Shutdown(); // last line in main()
}

???

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker

 

[Jon Skeet [C# MVP]]

So, I would be best having something like the following :

static class ObjectStore
{
private ClassThatUsesResource fred;
...
public static void Shutdown()
{
fred.Dispose();
fred = null;
}
}

...called from Main()

{
...
ObjectStore.Shutdown(); // last line in main()
}

???

Yup - something like that. Of course, if you can avoid doing it the
first place, that would be even better. (Keeping a resource for the
duration of an app is normally not a brilliant idea, especially if that
resource won't get automatically cleaned up if the app crashes hard.)

 

[Matthew Smith]

"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT

class singleton
{
static singleton theInstance = null;

public singleton GetIt
{
get
{
if ( theInstance == null )
theInstance = new singleton();
return theInstance;
}
...
}

Should you not add to this class the constructor:

private singleton()
{
}

so as not to allow it to be instantiated outside the class?