To Heath (we talked about this subject before)
-
public sealed class Singleton { static readonly Singleton instance=new Singleton(); // Explicit static constructor to tell C# compiler // not to mark type as beforefieldinit static Singleton() { } Singleton() { } public static Singleton GetInstance() { return instance; } }That was from this[^] article. Maybe you can answer this question: Is there an explicit need there for the private constructor to avoid initialization? If we remove it completely, will .NET supply a default public parameterless constructor? Sammy "A good friend, is like a good book: the inside is better than the cover..." -
public sealed class Singleton { static readonly Singleton instance=new Singleton(); // Explicit static constructor to tell C# compiler // not to mark type as beforefieldinit static Singleton() { } Singleton() { } public static Singleton GetInstance() { return instance; } }That was from this[^] article. Maybe you can answer this question: Is there an explicit need there for the private constructor to avoid initialization? If we remove it completely, will .NET supply a default public parameterless constructor? Sammy "A good friend, is like a good book: the inside is better than the cover..."The point of making a constructor private/protected is so that someone using the object via the API can't create an instance on their own. This is very handy if you want to make an object with singleton behavior. The only way you get the instance (the only instance) is using
GetInstance. Doing it this way, there is no other way create the object. If you leave a construtor publicly exposed then it cirumvents the code you put in place to enforce the singleton behavior. -
public sealed class Singleton { static readonly Singleton instance=new Singleton(); // Explicit static constructor to tell C# compiler // not to mark type as beforefieldinit static Singleton() { } Singleton() { } public static Singleton GetInstance() { return instance; } }That was from this[^] article. Maybe you can answer this question: Is there an explicit need there for the private constructor to avoid initialization? If we remove it completely, will .NET supply a default public parameterless constructor? Sammy "A good friend, is like a good book: the inside is better than the cover..."If you remove the private default constructor, yes, the compiler will provide one. Also, this isn't the best singleton pattern to use. The one I posted earlier was. It uses a double-check locking approach which eliminates a couple race conditions that may occur. This has been discussed in the past in this forum so if you want to know more, try searching for "singleton" or something for the C# forum.
Microsoft MVP, Visual C# My Articles
-
If you remove the private default constructor, yes, the compiler will provide one. Also, this isn't the best singleton pattern to use. The one I posted earlier was. It uses a double-check locking approach which eliminates a couple race conditions that may occur. This has been discussed in the past in this forum so if you want to know more, try searching for "singleton" or something for the C# forum.
Microsoft MVP, Visual C# My Articles
Well, what I'm doing right now is, I'm providing the binary deserialization mechanism in the static constructor, since I only need to load the settings from the file once in the lifetime of the program. Then, I'm providing a Save instance method so that I could save multiple times, which is needed whenever the settings dialog is opened and closed with Ok button. If there is nothing wrong with this in your opinion, then don't post an answer; otherwise, please comment. Thanks! Sammy "A good friend, is like a good book: the inside is better than the cover..."
-
The point of making a constructor private/protected is so that someone using the object via the API can't create an instance on their own. This is very handy if you want to make an object with singleton behavior. The only way you get the instance (the only instance) is using
GetInstance. Doing it this way, there is no other way create the object. If you leave a construtor publicly exposed then it cirumvents the code you put in place to enforce the singleton behavior.Thank you that was very clarifying. Sammy "A good friend, is like a good book: the inside is better than the cover..."
-
Well, what I'm doing right now is, I'm providing the binary deserialization mechanism in the static constructor, since I only need to load the settings from the file once in the lifetime of the program. Then, I'm providing a Save instance method so that I could save multiple times, which is needed whenever the settings dialog is opened and closed with Ok button. If there is nothing wrong with this in your opinion, then don't post an answer; otherwise, please comment. Thanks! Sammy "A good friend, is like a good book: the inside is better than the cover..."
There's nothing wrong with it, but what I was referring to in the previous post could result in your settings being loaded more than once. Now, this probably wouldn't be a problem, but locking your resources will gaurantee that it wouldn't. I'm not trying to down-play your approach, only present different ideas. It's you're implementation - do what you want. :) Typically in a singleton you provide static methods and properties and hide instance details from other classes. For instance, you could also have your
Savemethod as static and it gets the privateInstanceproperty (or uses yourGetInstancemethod) and saves the data. For the caller then, it's as simple as doingMySettings.Save. Again, just some things to think about. Your approach would work fine in most cases (only may become a problem with multiple AppDomains in a single process, which may not apply).Microsoft MVP, Visual C# My Articles