Creating Singleton Class

[JDYoder]

I have a class I think I'd like to setup as a singleton since I never want another object to be created for it. (That is, assuming I'm understand what a "singleton" is, which I think means a one and only instance of the class that can be created as a second object?) I've read about, but I'm not understanding how to go about it. For simplicity, say this is my class...

 

 

Public Class clsPrinter

   Public Enum Status
       Printing
       Waiting
       Unknown
   End Enum

   Public Function Printing(oDocument As Object)
       ' Code to print object
   End Function

End Class

 

 

How do I change this to a singleton class of just "Printer"? Or does it actually create an object called "Printer"? Like I said, the singleton thing is confusing to me. Any help would be very appreciated.

[Diesel]

Public Class Printer

Private Shared _instance As Printer

 

Public Shared ReadOnly Property Instance() As Printer

Get

 

If _instance Is Nothing Then

_instance = New Printer

End If

 

Return _instance

End Get

End Property

 

Public Enum Status As Integer

Printing = 0

Waiting

Unknown

End Enum

 

Public Function Printing(ByVal oDocument As Object) As Boolean

' Code to print object

Return False

End Function

 

End Class

 

 

 

clsPrinter? eww. M$ recommends leaving off prefixes these days, since you can easily find out the type during debug by mousing over.

[IngisKahn]

public class Printer
{
   static Printer instance = new Printer();

   Printer() { ... }

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

 

The keys are a private constructor and a static property.

 

In .NET 2.0 you could also use a static class.

 

BTW: MS also recommends not using underscores. :p

Edited July 26, 2005 by IngisKahn

[JDYoder]

I created Diesel's example. So now from some calling program, I typed "Printer." and the intellisense didn't show the Printing method, but did show the word "Instance". Only after selecting Instance and then hitting "." did the Intellisense show "Printing". So I have to use the word "Instance" every time, rather than just able to type "Printer"? That seems cumbersome. But is it the only way?

 

Also, I noticed , I can still declare any old object as a "Printer" type. I thought singleton classes guaranteed it to be a "one and only" kind of class/object hybrid? Or am I incorrect?

[IngisKahn]

Declaring a private constructor would ensure that you can not create any additional Printer objects. You can still declare a variable of the type Printer but the only way to use it is to set it to the object returned by the static Printer.Instance property. You can use this method to have easy access to Printer's members. Your other option would be to use a static class.

[Diesel]

What do you use to identity member variables?

[IngisKahn]

According to Microsoft P&P:

class Example
{
   int someMember;

   public int SomeMember { get { ... } set { ... } }

   public Example(int someMember)
   {
       // only in the constructor do you need to use 'this.'
       this.someMember = someMember;
   }
}

 

Of course this won't work in VB and even though MS doesn't target P&P for VB the consensus is to prefix with 'm' or 'my' sans underscore.

[Joe Mamma]

or

class Example
{
 static int _someMember;

 static public int SomeMember 
 { 
   get 
   { 
     return _someMember;
   } 
   set 
   {
     _someMember = value;
   } 
 }
}

 

Usage:

 

Example.SomeMember = 0;

[IngisKahn]

Ya, but the whole point is that you're advised not to use underscores in names (esp. as a prefix) due to readability/flow issues. Then again, if you're the only person working on the code then you can do whatever you want privately so long as you follow P&P for the public interface.

[BlackStone]

If you look at the (private) fields of frameworks classes, such as the ArrayList, they have an underscore. I personally like IngisKahn's version better (less typing), but apparently ms is still into the '_'.

[Joe Mamma]

you're advised not to use underscores in names (esp. as a prefix)

huh??? who advises that? internals are suggested to be either prefixed as _variable, or mVariable or m_Variable.

 

the "_" implies its attachment to current class.

[IngisKahn]

Hmm, that's a bit disturbing. More so since the guideline originated from an internal MS memo. Perhaps it was implemented before the edict was handed down. :(

[Joe Mamma]

Hmm' date=' that's a bit disturbing. More so since the guideline originated from an internal MS memo. Perhaps it was implemented before the edict was handed down. :([/quote']what memo???

 

[/url]

Elements of C++ Style, Misfeldt, et al (2004 Cambridge U. Press) Pp 18-27

Programming .Net Components 1 ed (2003 O'Reilly) p xiv

 

Just because MS suggest something be done a certain way does not mean to do it that way. . .

 

Remember VB SUX's hungarian notation? a total obfuscation of process.

Just consider intellisense.

 

I have 20 buttons on a form. . . one of which sends mail. . .

I type 'btn' and all 10 appear and I have to hit 's' to get the right control

as opposed to 'se' and most likely I have the button right there.

The obj prefix is worse.

 

And it is recommended you pass in a value the same name (minus the prefix) to methods -

 

_value = value (granted value isn't a good choice in realworld use)

[IngisKahn]

It was posted by a few people on blogs.msdn.com, but a quick web search didn't find it...

 

The recommendation is that no variable name decoration should be used (Hungarian or underscore). Any slight benefit gained from decorations is superceded by IDE functionality. (Especially in VS2005; it�s like night and day compared to VS2003)

[PlausiblyDamp]

I've seen several different recomendations from various MS sources (samples, blogs etc.) as a rule I would stick to the MS naming conventions for any externally visible members (Public or Protected) and not worry quite so much about exactly how internal naming conventions fit in as long as they are applied consistently and improve readability.

I personally do tend to use the _ prefix for member variables.

[Diesel]

:) If Plausibly uses it, it's good enough for me.

 

Besides...

 

private int someMember;

 

public int SomeMember { get; set; }

 

isn't CLS Compliant.

[IngisKahn]

Why not? CLS Compliance deals only with the public interface.

[Diesel]

Oh sorry...

 

protected int someMember;

 

public int SomeMember { get; set; }

[IngisKahn]

Confucius say: "Never use public or protected fields."